This is an illustrated guide that shows how to configure the various types of Network Address Translation (NAT) on the Juniper SRX series. Each example lists the configuration on the SRX, as well as what the client and server on either side of the SRX doing the NATing see and experience through working examples.
The first thing we'll use NAT for is to behave like a typical home router connected to an ISP through DSL or DOCSIS and only give a single IP address from the provider. We'll use the IP assigned to the external interface to NAT everything and perform Port Address Transtlation (PAT) or overloading so we can have all the IPs on the client side share the same reflexivie IP.
The SRX config is fairly simple. We define a source NAT rule-set which matches traffic going from the UNTRUST zone to the TRUST zone. Then we devine a rule that matches all traffic possible, and NATs it using the interface.
[edit security nat] juniper@SRX# show source { rule-set SOURCE-NAT { from zone UNTRUST; to zone TRUST; rule SOURCE-NAT { match { source-address 0.0.0.0/0; destination-address 0.0.0.0/0; } then { source-nat { interface; } } } } } [edit security nat] juniper@SRX#
We start nat-test_overload_multipleIP.sh
on the client, and then look at the session table on the SRX:
[edit security nat] juniper@SRX# run show security flow session Session ID: 1139, Policy name: ACCEPT-LOG/4, Timeout: 12, Valid In: 192.168.200.88/55498 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 4, Bytes: 240 Out: 10.80.80.80/80 --> 10.80.80.1/9882;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0 Session ID: 1140, Policy name: ACCEPT-LOG/4, Timeout: 12, Valid In: 192.168.200.89/33924 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 4, Bytes: 240 Out: 10.80.80.80/80 --> 10.80.80.1/7786;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0 Session ID: 1141, Policy name: ACCEPT-LOG/4, Timeout: 12, Valid In: 192.168.200.86/36944 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 4, Bytes: 240 Out: 10.80.80.80/80 --> 10.80.80.1/13007;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0 Session ID: 1142, Policy name: ACCEPT-LOG/4, Timeout: 12, Valid In: 192.168.200.85/39288 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 4, Bytes: 240 Out: 10.80.80.80/80 --> 10.80.80.1/14036;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0 Session ID: 1143, Policy name: ACCEPT-LOG/4, Timeout: 12, Valid In: 192.168.200.84/51924 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 4, Bytes: 240 Out: 10.80.80.80/80 --> 10.80.80.1/22729;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0 Session ID: 1144, Policy name: ACCEPT-LOG/4, Timeout: 12, Valid In: 192.168.200.83/46301 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 4, Bytes: 240 Out: 10.80.80.80/80 --> 10.80.80.1/21929;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0 Session ID: 1145, Policy name: ACCEPT-LOG/4, Timeout: 12, Valid In: 192.168.200.82/59466 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 4, Bytes: 240 Out: 10.80.80.80/80 --> 10.80.80.1/31677;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0 Session ID: 1146, Policy name: ACCEPT-LOG/4, Timeout: 12, Valid In: 192.168.200.81/50154 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 4, Bytes: 240 Out: 10.80.80.80/80 --> 10.80.80.1/10634;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0 Session ID: 1147, Policy name: ACCEPT-LOG/4, Timeout: 12, Valid In: 192.168.200.87/45347 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 4, Bytes: 240 Out: 10.80.80.80/80 --> 10.80.80.1/8141;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0 Total sessions: 9 [edit security nat] juniper@SRX#
The first thing we can see is that the traffic is being subjected to NAT. The "In" IP addresses in use, do not match the "Out" IP addresses.
Also notice that all of the sessions share the same reflexive IP address 10.80.80.1, although the port used varies. The reflexive transport address is the IP address and port assigned to a NAT session after it has been translated. I'll refer to the post-NAT IP address as the reflexive IP address, and the post-NAT port as the reflexive port. Notice also, that the port the client opens up, is not the same as the port the server will see as what it should write information back to the client with -- the reflexive port is not the same as the port the client openedup.
We can run the STUN client on on the client and see what it reports:
juniper@client:~$ stun 10.80.80.80 STUN client version 0.96 Primary: Dependent Mapping, random port, no hairpin Return value is 0x000018 juniper@client:~$
To interpret the output of the STUN client, we'll refer to RFC 4787., "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP". From Section 4, we can see that the client sees the connection through the SRX as using Address-Dependent mapping. This means that the NAT reuses the port port mapping for subsequent packets sent from the same internal IP address and port to the same external IP address and port, regardless of the external port. This makes sense, as we only have one IP address that will ever be used as the reflexivie IP address with interface NAT and the SRX creates a single session for every flow, not a session for each packet. The STUN client is detecting as well that the NAT process is assiging any port as the reflexive port. Hairpinning allows two hosts behind the same NAT device to exchange traffic using their reflexive IP addresses. Interface NAT is not supporting this behavior.