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.
We'll start assigining addresses from a pool. We'll use a rather small pool of only four IP addresses so we can easily overload it, but not be overwhelmed by the number of sessions we have to create (or parse through the output of a show command). We'll use addresses 10.80.80.200 through 10.80.80.204 for our pool. The config on the SRX is modified to look like the following:
SRX Source NAT with Address Pool Configuration
[edit security nat]
juniper@SRX# show
source {
pool SOURCE-NAT-POOL {
address {
10.80.80.200/30;
}
}
rule-set SOURCE-NAT {
from zone UNTRUST;
to zone TRUST;
rule SOURCE-NAT-POOL {
match {
source-address 0.0.0.0/0;
destination-address 0.0.0.0/0;
}
then {
source-nat {
pool {
SOURCE-NAT-POOL;
}
}
}
}
}
}
[edit security nat]
juniper@SRX#
Next we'll run nat-test_overload_multipleIP.sh on the client and examine the session table:
SRX source NAT sessions with address pool
[edit security nat]
juniper@SRX# run show security flow session
Session ID: 1180, Policy name: ACCEPT-LOG/4, Timeout: 2, Valid
In: 192.168.200.88/60422 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 5, Bytes: 300
Out: 10.80.80.80/80 --> 10.80.80.200/16628;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0
Session ID: 1181, Policy name: ACCEPT-LOG/4, Timeout: 2, Valid
In: 192.168.200.89/48662 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 5, Bytes: 300
Out: 10.80.80.80/80 --> 10.80.80.201/13395;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0
Session ID: 1182, Policy name: ACCEPT-LOG/4, Timeout: 2, Valid
In: 192.168.200.86/47043 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 5, Bytes: 300
Out: 10.80.80.80/80 --> 10.80.80.202/10838;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0
Session ID: 1183, Policy name: ACCEPT-LOG/4, Timeout: 2, Valid
In: 192.168.200.85/46636 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 5, Bytes: 300
Out: 10.80.80.80/80 --> 10.80.80.203/27984;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0
Session ID: 1184, Policy name: ACCEPT-LOG/4, Timeout: 2, Valid
In: 192.168.200.84/38808 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 5, Bytes: 300
Out: 10.80.80.80/80 --> 10.80.80.200/16007;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0
Session ID: 1185, Policy name: ACCEPT-LOG/4, Timeout: 2, Valid
In: 192.168.200.83/51655 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 5, Bytes: 300
Out: 10.80.80.80/80 --> 10.80.80.201/28068;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0
Session ID: 1186, Policy name: ACCEPT-LOG/4, Timeout: 2, Valid
In: 192.168.200.82/44906 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 5, Bytes: 300
Out: 10.80.80.80/80 --> 10.80.80.202/29302;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0
Session ID: 1187, Policy name: ACCEPT-LOG/4, Timeout: 2, Valid
In: 192.168.200.87/53304 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 5, Bytes: 300
Out: 10.80.80.80/80 --> 10.80.80.203/9797;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0
Session ID: 1188, Policy name: ACCEPT-LOG/4, Timeout: 2, Valid
In: 192.168.200.81/45885 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 5, Bytes: 300
Out: 10.80.80.80/80 --> 10.80.80.200/9818;tcp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0
Total sessions: 9
[edit security nat]
juniper@SRX#
Note that we have a total of nine sessions, and all four address from our pool are being used. There isn't an exclusive mapping between the source IP address and a reflexive IP address ( no 1:1 mapping). Session 1180 is mapping 192.168.200.88 to 10.80.80.200, and session 1184 is mapping 192.168.200.84 to the same reflexive IP address. The source ports and their reflexive counterparts are not being preserved either.
Also notice, that the sessions are all fully setup, but there is no return traffic at this point. We can examine this from the perspective of both the server and the client. On the server, we see that it's recieved all of the SYN packets as indicated by SYN_RECV, but it hasn't progressed any further down it's TCP handshake. The next logical step, would be to send a SYN-ACK back to the client, but we don't see any SYN_SENTs ever show up in the state collumn of our netstat output no matter how long we wait.
Half open sessions on the server
juniper@server:~$ netstat -tn Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 10.80.80.80:80 10.80.80.200:11971 SYN_RECV tcp 0 0 10.80.80.80:80 10.80.80.202:15452 SYN_RECV tcp 0 0 10.80.80.80:80 10.80.80.203:11865 SYN_RECV tcp 0 0 10.80.80.80:80 10.80.80.201:24615 SYN_RECV tcp 0 0 10.80.80.80:80 10.80.80.202:1995 SYN_RECV tcp 0 0 10.80.80.80:80 10.80.80.201:30734 SYN_RECV tcp 0 0 10.80.80.80:80 10.80.80.203:8920 SYN_RECV tcp 0 0 10.80.80.80:80 10.80.80.200:17943 SYN_RECV tcp 0 0 10.80.80.80:80 10.80.80.200:7953 SYN_RECV tcp 0 0 127.0.0.1:389 127.0.0.1:58686 ESTABLISHED tcp 0 0 127.0.0.1:58686 127.0.0.1:389 ESTABLISHED juniper@server:~$
If we do a tcpdump to examine the incoming packets, we notice a lot of SYNs coming in from the NAT'ed IP addresses, but the only thing the server is sending is ARP requests for the NAT'ed IPs. There don't seem to be an ARP responses ever coming back.
tcpdump debugging of half open TCP sessions on server
juniper@server:~$ sudo tcpdump -nvi eth1
[sudo] password for juniper:
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
11:12:51.546721 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.203 tell 10.80.80.80, length 28
11:12:54.567390 IP (tos 0x0, ttl 63, id 30228, offset 0, flags [DF], proto TCP (6), length 60)
10.80.80.202.3957 > 10.80.80.80.80: Flags [S], cksum 0xb61f (correct), seq 195903850, win 14600, options [mss 1460,sackOK,TS val 1918504 ecr 0,nop,wscale 4], length 0
11:12:54.567472 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.202 tell 10.80.80.80, length 28
11:12:54.567900 IP (tos 0x0, ttl 63, id 31504, offset 0, flags [DF], proto TCP (6), length 60)
10.80.80.201.2329 > 10.80.80.80.80: Flags [S], cksum 0x6bb1 (correct), seq 1366051958, win 14600, options [mss 1460,sackOK,TS val 1918504 ecr 0,nop,wscale 4], length 0
11:12:54.567931 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.201 tell 10.80.80.80, length 28
11:12:54.568310 IP (tos 0x0, ttl 63, id 24609, offset 0, flags [DF], proto TCP (6), length 60)
10.80.80.203.23613 > 10.80.80.80.80: Flags [S], cksum 0xc810 (correct), seq 2532661095, win 14600, options [mss 1460,sackOK,TS val 1918504 ecr 0,nop,wscale 4], length 0
11:12:54.568341 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.203 tell 10.80.80.80, length 28
11:12:54.568392 IP (tos 0x0, ttl 63, id 40660, offset 0, flags [DF], proto TCP (6), length 60)
10.80.80.203.2061 > 10.80.80.80.80: Flags [S], cksum 0x4220 (correct), seq 517188010, win 14600, options [mss 1460,sackOK,TS val 1918504 ecr 0,nop,wscale 4], length 0
11:12:54.568412 IP (tos 0x0, ttl 63, id 53222, offset 0, flags [DF], proto TCP (6), length 60)
10.80.80.200.3256 > 10.80.80.80.80: Flags [S], cksum 0x206a (correct), seq 3975346328, win 14600, options [mss 1460,sackOK,TS val 1918504 ecr 0,nop,wscale 4], length 0
11:12:54.568431 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.200 tell 10.80.80.80, length 28
11:12:54.568440 IP (tos 0x0, ttl 63, id 17737, offset 0, flags [DF], proto TCP (6), length 60)
10.80.80.200.9941 > 10.80.80.80.80: Flags [S], cksum 0xf4ee (correct), seq 2225762879, win 14600, options [mss 1460,sackOK,TS val 1918504 ecr 0,nop,wscale 4], length 0
11:12:54.568455 IP (tos 0x0, ttl 63, id 16066, offset 0, flags [DF], proto TCP (6), length 60)
10.80.80.201.16374 > 10.80.80.80.80: Flags [S], cksum 0x92dc (correct), seq 907413956, win 14600, options [mss 1460,sackOK,TS val 1918504 ecr 0,nop,wscale 4], length 0
11:12:54.568471 IP (tos 0x0, ttl 63, id 9382, offset 0, flags [DF], proto TCP (6), length 60)
10.80.80.202.10405 > 10.80.80.80.80: Flags [S], cksum 0xadc5 (correct), seq 677975000, win 14600, options [mss 1460,sackOK,TS val 1918504 ecr 0,nop,wscale 4], length 0
11:12:54.568486 IP (tos 0x0, ttl 63, id 46443, offset 0, flags [DF], proto TCP (6), length 60)
10.80.80.202.5630 > 10.80.80.80.80: Flags [S], cksum 0xcb17 (correct), seq 2943910429, win 14600, options [mss 1460,sackOK,TS val 1918504 ecr 0,nop,wscale 4], length 0
11:12:55.566677 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.202 tell 10.80.80.80, length 28
11:12:55.566823 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.201 tell 10.80.80.80, length 28
11:12:55.566833 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.203 tell 10.80.80.80, length 28
11:12:55.566840 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.200 tell 10.80.80.80, length 28
11:12:56.566724 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.202 tell 10.80.80.80, length 28
11:12:56.566829 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.201 tell 10.80.80.80, length 28
11:12:56.566838 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.203 tell 10.80.80.80, length 28
11:12:56.566845 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.200 tell 10.80.80.80, length 28
11:12:57.566833 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.202 tell 10.80.80.80, length 28
11:12:57.566940 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.200 tell 10.80.80.80, length 28
11:12:57.566952 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.201 tell 10.80.80.80, length 28
11:12:58.566719 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.202 tell 10.80.80.80, length 28
11:12:58.566815 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.200 tell 10.80.80.80, length 28
11:12:58.566821 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.201 tell 10.80.80.80, length 28
11:12:59.566711 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.202 tell 10.80.80.80, length 28
11:12:59.566811 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.200 tell 10.80.80.80, length 28
11:12:59.566817 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.80.80.201 tell 10.80.80.80, length 28
^C
31 packets captured
31 packets received by filter
0 packets dropped by kernel
juniper@server:~$
We can confirm the ARP problem by looking at the arp table on the server.
arp problems on server
juniper@server:~$ arp -an ? (10.80.80.200) aton eth1 ? (10.80.80.202) at on eth1 ? (10.80.80.1) at ac:de:48:00:11:03 [ether] on eth1 ? (10.80.80.201) at on eth1 ? (10.80.80.203) at on eth1 juniper@server:~$
To fix this we need to configure proxy-arp on the SRX so it will respond with it's own MAC address for all of the reflexive IPs.
proxy-arp configuration on the SRX
[edit security nat proxy-arp]
juniper@SRX# show
interface ge-0/0/3.0 {
address {
10.80.80.200/30;
}
}
[edit security nat proxy-arp]
juniper@SRX# commit
commit complete
[edit security nat proxy-arp]
juniper@SRX#
With proxy-arp enabled, we have bidirectional traffic.
Bidirectional sessions on SRX
[edit security nat]
juniper@SRX# run show security flow session
Session ID: 5276, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
In: 192.168.200.84/33256 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 97, Bytes: 5199
Out: 10.80.80.80/80 --> 10.80.80.201/26502;tcp, If: ge-0/0/3.0, Pkts: 312, Bytes: 440496
Session ID: 5277, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
In: 192.168.200.83/40978 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 128, Bytes: 6815
Out: 10.80.80.80/80 --> 10.80.80.202/2286;tcp, If: ge-0/0/3.0, Pkts: 403, Bytes: 579300
Session ID: 5278, Policy name: ACCEPT-LOG/4, Timeout: 298, Valid
In: 192.168.200.89/54562 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 128, Bytes: 6815
Out: 10.80.80.80/80 --> 10.80.80.203/1582;tcp, If: ge-0/0/3.0, Pkts: 402, Bytes: 578400
Session ID: 5279, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
In: 192.168.200.86/54290 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 124, Bytes: 6607
Out: 10.80.80.80/80 --> 10.80.80.200/26351;tcp, If: ge-0/0/3.0, Pkts: 389, Bytes: 551660
Session ID: 5280, Policy name: ACCEPT-LOG/4, Timeout: 298, Valid
In: 192.168.200.88/35144 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 113, Bytes: 6035
Out: 10.80.80.80/80 --> 10.80.80.201/9200;tcp, If: ge-0/0/3.0, Pkts: 383, Bytes: 549900
Session ID: 5281, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
In: 192.168.200.81/36927 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 114, Bytes: 6055
Out: 10.80.80.80/80 --> 10.80.80.202/8224;tcp, If: ge-0/0/3.0, Pkts: 392, Bytes: 559048
Session ID: 5282, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
In: 192.168.200.82/33609 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 136, Bytes: 7199
Out: 10.80.80.80/80 --> 10.80.80.203/15755;tcp, If: ge-0/0/3.0, Pkts: 466, Bytes: 659912
Session ID: 5283, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
In: 192.168.200.85/57698 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 116, Bytes: 6171
Out: 10.80.80.80/80 --> 10.80.80.200/29723;tcp, If: ge-0/0/3.0, Pkts: 383, Bytes: 552788
Session ID: 5284, Policy name: ACCEPT-LOG/4, Timeout: 298, Valid
In: 192.168.200.87/36104 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0, Pkts: 100, Bytes: 5339
Out: 10.80.80.80/80 --> 10.80.80.201/10176;tcp, If: ge-0/0/3.0, Pkts: 324, Bytes: 468632
Total sessions: 9
[edit security nat]
juniper@SRX#
And on the server we now have completed entries in our arp table, with MAC address mappings for all of the IPs in our address pool that are the same as the mac on the SRX TRUST inteface (ge-0/0/3).
full arp resolution on server
juniper@server:~$ arp -an ? (10.80.80.200) at ac:de:48:00:11:03 [ether] on eth1 ? (10.80.80.202) at ac:de:48:00:11:03 [ether] on eth1 ? (10.80.80.1) at ac:de:48:00:11:03 [ether] on eth1 ? (10.80.80.201) at ac:de:48:00:11:03 [ether] on eth1 ? (10.80.80.203) at ac:de:48:00:11:03 [ether] on eth1 juniper@server:~$
On the client, the STUN client reports essentially no change from our first scenario.
stun client with ip address pool
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:~$