SRX

Does the SRX evaluate the source and destination address of a packet against the security policy before or after address translation?

The reason I ask is because when I create Policy Elements for devices that are in my DMZ and use their public address, while placing them in the Untrust zone, they don't show up in the destination address window of the policy creation.

So, for instance, with an smtp mail server having a public address of 150.23.4.1 and a private (DMZ) address of 192.168.1.1, you would expect the security policy to be something like, source address=any, destination address=150.23.4.1.  But on the SRX (JUNOS) it appears as though you have to use the mail server's DMZ address as the destination address.

Am I supposed to create the policy element for the server using it's public address and place it in the DMZ zone so that it will appear in the destination address window?  This seems counter to the way that ScreenOS worked, where the destination address was the Mapped IP (MIP), or public address for inbound connections.

I am going to scan the SRX configuration examples for clues, but if anybody has an example of how this is supposed to work, I'd be grateful.

Regards,

Hi,

destination NAT is applied before policy checking, source NAT is applied after policy check.

With dest-NAT one has to configure the real destination in policy rule, because policy check

is done against the NATed object, yout object in DMZ or trusted zone.

Regards,

Klaus

Klaus,

Thank you for your reply.  I am trying to configure servers within my DMZ and on my Internal network to accept connections from the Internet.  I will have web servers, FTP servers, and SMTP servers in the DMZ that will be accessed from the Internet.  And I will have servers on my Internal network that will also have connections from the Internet.  I also need to do at least one static mapping for the mail server on my Internal network so that reverse DNS lookups will work when I send mail out to the Internet.

In ScreenOS this was easy: create a MIP that will do bi-directional NAT and then create Untrust-to-Trust policies, using  the MIP as the destination address for incoming packets, and assign protocols as needed.

This logic seems different for the SRX.  In the SRX policy definition, I would think that the source address would be "any", since it's coming from the Internet, and the destination address would be the server's public address, since that is the address the user is targeting.

Following that logic, I am using the J-Web GUI to create Policy Elements in the Untrust zone and assigning them the public addresses of the servers.  But then I can't use these elements in my policies, because they show up in the source address window, not the destination address window.  The logic seems backward.

I have read some of the documentation, but I'm still not certain.

Regards,

Dan

Hi Dan,

You will need to configure a static nat for your mail server in [edit security nat]

static {
  rule-set nat-dmz {
    from interface ge-0/0/5.0;
    rule mailserver {
      match {
        destination-address 200.200.200.25/32
      }
      then {
        static-nat prefix 10.0.0.25/32
      }
    }
  }
}

To get the same proxy arp functionality as ScreenOS provides with a MIP add something like below as well.

proxy-arp {
  interface ge-0/0/5.0 {
    address {
      200.200.200.25
    }
  }
}

The firewall policy is completely separated from your nat policies and contains the natted address as a destination.

policy smtp-inbound {
    match {
        source-address any;
        destination-address Address_10_0_0_25;
        application junos-smtp;
    }
    then {
        permit
        }
    }
}

When your mail server needs to reach the outside you need it to configure this way.

policy smtp-outbound {
    match {
        source-address Address_10_0_0_25;
        destination-address any;
        application junos-smtp;
    }
    then {
        permit
        }
    }
}

Thank you.  I already configured the static NAT configuration part, but I am hung up on the policy definition.  It appears from your example, which is similar to the examples in the SRX documentation, that you use the server's private address (i.e. 10.0.0.25 in your example) as the destination address, even though the Internet client is trying to connect to the server's public address (200.200.200.25).  It appears as though the translation happens prior to the policy evaluation.

Do you really have to create an outbound policy?  Isn't outbound traffic allowed by default?  And won't the static NAT configuration automatically translate the address outbound?

I assume that the proxy ARP will take care of the Reverse DNS Lookup problem?

Regards,

SRX NAT does differ in one particular way from ScreenOS in that NAT rules are decoupled from security policies. This allows for much greater flexibility overall. Because NAT is decoupled from policy the order of events that happens also differs from ScreenOS. ScreenOS more or less applies NAT after policy lookup. Hence the policy must have MIP address object to match the policy.

Since SRX decouples NAT from policies, SRX will perform any destination NAT first, then policy lookup, then apply any source NAT if needed. Static NAT is basically combination of source and destination NAT depending on direction packet is traversing. So if coming from Internet to DMZ that would be destination NAT. If going from DMZ to Internet that would be source NAT. So based on that destination NAT will happen first before policy lookup hence reason security policy must reference DMZ IP address of server.

Have a look at some of these application notes.

http://www.juniper.net/us/en/products-services/security/srx-series/#literature

In particular, the ones titled "SRX Series and J Series Network Address Translation" and "Juniper Networks SRX Series and J Series NAT for ScreenOS Users"

And regarding requiring security policy for outbound traffic, If traffic initiates from outside to inside, then you do not need a policy to permit return traffic as long as it matches the existing session. However, yes you do need to explicitly permit traffic if it initiates from inside to outside. This is true also for ScreenOS. However for static NAT rule, that is in fact bi-directional so you do not need to also configure a source-nat rule for that traffic.

-Richard

Thank you, Richard.  That clears up alot of questions for me.  I have worked with many firewalls, most notably Cisco PIX and ASA, and ScreenOS, but have not worked nearly as much with the security/firewall policies and NAT in JUNOS.

I will have a look at the document link you sent me, but it sounds like, if necessary, I can either do a global ploicy to allow all traffic from my DMZ to the Internet, or create policies for those devices that need Internet access.  This is similar to outbound policies in ScreenOS.  And once I configure a static NAT policy in JUNOS, it will do bi-directional NAT.

Thanks again,

Dan