Purpose:

The purpose of this functional spec is to implement the firewall, port forwarding and static NAT functionality on  external firewall device  Juniper SRX.

Background:

Cloudstack Firewall and PortForwarding/StaticNAT  feature implementation in Virtual Router:

  1.       PortForwarding:  Port forward the public ports to private ports. Forward the traffic to the specified VM.
  2.       Static NAT:  Map the Public IP to VM IP.
  3.       Firewall:  Configuration allows CIDR, Port range from the Public.

The firewall, port forwarding and static NAT rules are added on public IP.

Configuration Parameters:

Static NAT Configuration:     public IP and private (VM) IP.

Port forwarding configuration:    Public IP, public port range, private port range and Private IP (VM) IP.

Firewall Configuration:     Source CIDR, destination port range, protocol, ICMP type/code

Note: If a VM is added in Static NAT configuration the same VM can't be used for the StaticNAT again.

PF, Static NAT and Firewall Design For Juniper SRX:

While adding the SRX device into cloudstack,  two zones are configured on the SRX.

  1. Public(untrust) Zone 
  2. Private(trust) Zone.

 The SRX device applies rules Zone to Zone

 For Ingress traffic, SRX processes PF/StaticNAT rules first, then security polices. Reference [1]

Firewall:

The firewall would behavior the same as VR. It would allow only traffic from <source cidr> to <acquired ip> on <specified port>.

The firewall would be hooked on public interface of SRX.

User need to add filter "untrust"(which is the public zone name) to the input filter hook of interface. e.g.:

set interface fe-0/0/2 unit <vlan> family inet filter input untrust;

And CloudStack would operate the "untrust" filter to perform all the firewall operations.

You also need to permit the return traffic of Source NAT / Static NAT in the firewall. Here is a example of allow established TCP traffic, and echo reply of ping, and DNS query traffic.

set firewall filter untrust term return-traffic-tcp from tcp-established
set firewall filter untrust term return-traffic-tcp then accept
set firewall filter untrust term return-traffic-ping from icmp-type 0
set firewall filter untrust term return-traffic-ping from icmp-code 0
set firewall filter untrust term return-traffic-ping then accept
set firewall filter untrust term return-traffic-dns from protocol udp
set firewall filter untrust term return-traffic-dns from port 53
set firewall filter untrust term return-traffic-dns then accept

In the example above, we didn't allow all the return traffic of UDP.

In order to allow return traffic of UDP for Source NAT vm, we can set:

set firewall filter untrust term return-traffic-sourcenat-udp from destination-address <source-nat-ip-address>
set firewall filter untrust term return-traffic-sourcenat-udp from protocol udp
set firewall filter untrust term return-traffic-sourcenat-udp then accept

For Static NAT enabled VM, user need to figure out what's the destination port of UDP, and add correlated rule to it.

PortForwarding: 

Configuring Port Forwarding rules with the external firewall device SRX, cloudstack  will configure the following rules on SRX:

  1. Program the  Destination NAT  rules  on the SRX [2].
  2. Program security policies for private ports and VM IP as destination IP.

Static NAT:

Enable static NAT rule:

To do static NAT to a public IP,  enable the static NAT and open firewall on the SRX.

Static NAT:

  1. Enable Static NAT on public IP, will map the one one to NAT of public IP and VM IP in DB, programming static nat rule on SRX.
  2. Program security policies to allow all the ports. (The firewall would open only allowed ports).

Disable Static NAT rule:

On disabling static NAT cloudstack will

  • Disable the static NAT  and delete the static NAT rules and secuity policy on the SRX.

UI Changes;

No needed.

  

Use Cases:

Should be exactly the same as VR.

Network Upgrade Scenario:

Upgrade from network using VR to or from network using SRX should remain the functionality exactly the same.

Known issue:

1. Once enable static nat for one VM, the VM cannot access outside. Only outside can access VM on specified ports/protocols.

The reason is, after enable static nat, static nat setting have higher priority than source nat, thus all the traffic going outside would with static nat IP. And in the firewall, we only enabled static nat ip with certain ports/protocols. That's the reason of VM would fail to reach outside in the most case.

VR is fine with it because VR's iptables is a stateful firewall, and it would know who initiate the connection thus permit the connections initiated by vm inside the network. But SRX's firewall is stateless, so it can only tell the state through protocol itself. In this case, TCP is fine, but UDP/ICMP would be blocked anyway.

2. IP based network usage is disabled by now, since we're using the same filter for Firewall. Need to cooperate with network usage later.

Appendix:

Appendix A:

[1] staticNAT Rule:

set security nat static rule-set untrust from zone untrust
set security nat static rule-set untrust rule 10-0-127-126 match destination-address 10.147.52.36/32
set security nat static rule-set untrust rule 10-0-127-126 then static-nat prefix 10.0.127.126/32

2] PF Rule:

set security nat destination rule-set untrust rule destnatrule-1885679882 match destination-address 10.147.52.102/32
set security nat destination rule-set untrust rule destnatrule-1885679882 match destination-port 22
set security nat destination rule-set untrust rule destnatrule-1885679882 then destination-nat pool 10-0-65-17-22
set security policies from-zone untrust to-zone trust policy destnat-untrust-trust-10-0-65-17 match source-address any
set security policies from-zone untrust to-zone trust policy destnat-untrust-trust-10-0-65-17 match destination-address 10-0-65-17
set security policies from-zone untrust to-zone trust policy destnat-untrust-trust-10-0-65-17 match application tcp-22-22
set security policies from-zone untrust to-zone trust policy destnat-untrust-trust-10-0-65-17 then permit
set security policies from-zone untrust to-zone trust policy destnat-untrust-trust-10-0-65-17 then count

[3] Firewall:

set interfaces fe-0/0/2 vlan-tagging
set interfaces fe-0/0/2 unit 1610 vlan-id 1610
set interfaces fe-0/0/2 unit 1610 family inet filter input untrust
set interfaces fe-0/0/2 unit 1610 family inet address 10.223.161.18/26
set firewall filter untrust term sourcenat from destination-address <ipaddress>
set firewall filter untrust term sourcenat then accept
set firewall filter untrust term 10-223-161-29-0-0-0-0-0-tcp-22-22 from source-address 0.0.0.0/0
set firewall filter untrust term 10-223-161-29-0-0-0-0-0-tcp-22-22 from destination-address 10.223.161.29/32
set firewall filter untrust term 10-223-161-29-0-0-0-0-0-tcp-22-22 from protocol tcp
set firewall filter untrust term 10-223-161-29-0-0-0-0-0-tcp-22-22 from destination-port 22-22
set firewall filter untrust term 10-223-161-29-0-0-0-0-0-tcp-22-22 then count 10.223.161.29
set firewall filter untrust term 10-223-161-29-0-0-0-0-0-tcp-22-22 then accept

References:

[1]

https://docs.google.com/viewer?a=v&q=cache:xaUPg9YadB0J:jnpr.net/us/en/local/pdf/app-notes/3500151-en.pdf+srx+packet+flow+diagram&hl=en&gl=us&pid=bl&srcid=ADGEEShZajbbnGb8NqKP71wh_DNFkh-xJGZryQeN5u3vM0Xk1Gj68th3E1m1g2abj4L1NWY4PMJ9MdrkHDLWBh3eVQJNR8YRMG7hmJIj5dtqPfewUXrXG_nVQ6XxbWT-Vcw6iYovCb1b&sig=AHIEtbTF3BOveu7ZPJAMzO2adtQs7t_Qmw 

  • No labels

4 Comments

  1. Alena Prokharchyk

    Couple of comments.

    1) "In SRX same VM can't be configured for the both PF and Static NAT"

    Is this limitation recent? If so, make sure this limitation doesn't block existing customer setup. What if customer already has StaticNat and PF configured for the same vm in SRX setup? If you are going to block it, it's bad.

    How did you implement it? We should neither hardcode it in the SRX code, or on the API layer. My suggestion would be: introduce additional capability to PF/StaticNat services that would tell the enableStaticNat/createPF APIs if StaticNat and PF services can be configured for the same VM. If not, the call should fail in the NetworkManager.

    2) "2. Upgrade from SRX to VR.

    Firewall rules for PF have to be created."

    We shouldn't create anything automatically. User should add it himself. Therefore it should be documented (if not already).

    3) Make sure ICMP protocol can't be passed to createFirewallRule API when it's called bypassing the UI. ICMP shouldn't be in the list of FirewallService capabilities for the SRX device.

    1. Jayapal

      1) When same VM is used for both Static NAT and PF, then Static NAT public IP will access the services of PF.
      This issue should be there from the past.
      We have two options:
      a. Let this issue continue now inview of existing setups.
      OR
      b. Do not allow Same VM to configure for both PF and Static NAT

      2) Upgrade from SRX to VR.

      If firewall rules are not applied automatically then
      I have the below scenario.
      1. Enable static NAT
      2. Add firewall rules
      3. Disable static NAT. The firewall rules present in DB.
      4. Configure the PF.
      5. Now upgrade from SRX to VR.
      6. In VR PF is configured but the Firewall rules are in DB but not applied on VR.

      3) I can't add it in FirewallService capabilities for the SRX because for Egress it support the ICMP.

  2. Sangeetha Hariharan

    1) "Case 4:
    Firewall rule is not deleted when disable the Static NAT.
    1. Acquire Ip P4.
    2. Create Firewall for port 22.
    3. Enable static NAT on P2 for VM2.
    4. Disable static NAT.
    5. Enable static NAT
    7.PublicNetwork# ssh <P4> (ssh to VM1 should success)"

    In this case, step 3 , i assume should be P4 (typo?)

    After Step4 , In the SRX side , we will see both the firewall rule and static NAT being deleted. But in cloud DB we will still have the firewall rules present. Is this correct?

    After Step5 , In the SRX side , we will see both the firewall rule and static NAT being created back in SRX side. Is this correct?

    2) What will the behavior in the following use case where user deletes a firewall that was created for a Static NAT rule ?

    1. Acquire Ip address.
    2. Create an Static NAT rule.
    3. Create Firewall rules for port 22.
    4. Create Firewall rule for port 80.
    5. Delete firewall rule for port 22.
    6. Delete firewall rule for port 80.
    7. Add firewall rule for port 22.

    After Step 5 ,
    In SRX , we expect the firewall rule for port 22 to be deleted.

    After Step 6 ,

    In SRX , Do we expect the firewall rule for port 80 and Static NAT rule to be deleted ?

    After Step 7 ,

    In SRX , Do we expect the firewall rule for port 22 and Static NAT rule to be created ?

    3) In UI Changes section:

    "The following changes are needed for the networks page for the external device SRX network.

    1. Network ->Guest Network ->View IP Addresses -> <IP Address> -> Configuration

    a. Hide the Firewall when Port forwarding is configured on IP Address."

    >> How do we prevent the case when the user creates a firewall first and then he tries to create a PF/LB rule ? In this case what should be the expected behavior? Do we actually configure the user created firewall , PF rule and also create firewalls for the PF rule (if the port used in the create firewall is different from that provided in the PF rule) ?

    1. Jayapal

      1. Corrected it to P4.
      2. The firewall rule 22 and Static NAT rule will be created on SRX.
      3. Disable the Firewall once the PF is enabled.