JNCIP-SEC [ 3 – Advanced NAT ]

In this post I would like to do some experiment in Advanced NAT topics according to detailed exam guide here are the details:

1) Given a scenario, describe and implement static, source, destination, and dual NAT
2) Describe and implement variations of persistent NAT
3) Given a scenario, describe the interaction between NAT and security policy
Here is my test topology: JunOS release is 10.4R6.5


1) SOURCE,DESTINATION,STATIC and DUAL(double) NAT
a) SOURCE NAT
a.1) Interface Source NAT of PC1
First define criteria of NAT paramaters. The commands below will source nat IP address 10.1.1.100 to interface address of the exit interface if the packet is coming from zone trust and destined to any IP in zone wan

Once the above NAT rule is accompanied by a security policy like below, traffic should flow if zone configuration is also correct:

a.2) Source NAT of PC1 by using pool:
If you want to set a pool of IP addresses here is a snippet;

If the security policy is in place and you try to reach an outside address from PC1, you will
see that there is no connectivity but why? it is because for the pool address we defined srx2 doesn’t send any arp-reply because they aren’t configured in any interface. That is why we must specifically set proxy arp for this range. Here is the configlet;

When you commit this change, you will see the following populated arp table in SRX1
You see all the IP addresses in this range are now available.

When I activated this pool based NAT, I wanted to see how the flow session looks like;

During this test I started an ubuntu linux ISO download from ubuntu.com and some other traffic. Can you see how many different IP addresses I am using from a single PC? This may be something not desired depending on the requirements. You may want to have persistence so that one source IP will stick to a single outside IP address. If you set this like below;
root@srx2#set security nat source address-persistent
Your flow sessions will be something like this;

Do you see the difference? We stick to one address by using persistent address feature.

b) Destination NAT
According to our diagram we have a web server behind srx2 . What we want to do is to NAT packets sent to 172.16.1.30 IP address and port 80 to the internal IP address 10.1.1.101 of web server. Let’s do it:

This destination nat rule says: If any packet comes from zone wan with any source address for destination 172.16.1.30 and port 80, translate destination IP address to the address in the web-server pool but this configlet isn’t sufficient for DNAT to work. We should also add 172.16.1.30 into proxy-arp settings, because srx1 doesn’t reply to arp-requests for this IP address.

This is still not sufficient. We should also add policy to allow this particular traffic:

Now everything should be ok lets try to telnet to 172.16.1.30 port 80 from srx1

Now everything seems to work…
c) STATIC NAT
As the name implies, we statically map addresses from one zone to another. If we take FTP server in our diagram, we would like to translate all requests to 172.16.1.31 to inside address 10.1.1.102 without any port consideration. Here is how to do it:
First static nat configuration:

Second security policy for this traffic:

Proxy arp setting for 172.16.1.31:
#set security nat proxy-arp interface ge-0/0/0.0 address 172.16.1.31/32
Address book entry for new FTP server:

Let’s try from srx2 an ftp connection:

Wovv, it works!

3 thoughts on “JNCIP-SEC [ 3 – Advanced NAT ]

  1. Jacky

    Hello, thanks for your share and the detail analyze.
    I am working on the SRX210 with dual WAN and HA. I found that the static-nat will got problem when outgoing. The packet will go though by the FW untrust IP either than the static-nat IP. It so trouble, I need to add the destination-nat to fix this problem. Do you have same experience?

    Reply
  2. rtoodtoo Post author

    Hello Jacky,
    I haven’t experienced such a problem but if you send me a sample config and scenario along with which junos version you use, I can look into it as soon as I have time.
    Regards

    Reply
  3. dmac

    Wayy too late to be helpful, but posting in case anyone is ever reading this- this can be done with VRF’s. Once you bind ISP1’s link to an interface on VRF1 and bind ISP2’s link to an interface belonging to VRF2, only the policies that would possibly match traffic traversing these zones will be enacted.

    Reply

You have a feedback?