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.
Sticking some static routes in an upstream device and redistributing them out from there is less than an ideal way of advertising the NAT'd space out to the rest of the network. If the NAT device has more than one link to the rest of the network this will result in inefficiencies, suboptimal routing, possible asymetirc routing (which with statful devices is really less than ideal), and the other problems that normally come with static routes. We'll explore a couple of ways in which to make this situation more adaptable by making the NAT device responsible for advertising the NAT'd IP space.
One way that works well, especially in environments where the duplicate IP space is being transitioned new address space, is to simply use the new address space as the NAT'ed IP space. Simply add the new IP space to the existing interfaces as an additional IP, then advertise the address space out through the appropriate routing protocol. Once all of the hosts have been transitioned, the NAT ruleset can be deleted.
We'll demonstrate this by first dropping the static routes on our upstream routing device, SRX-12. SRX-12 will no longer advertise these out.
Deactivating static routes on SRX-12
[edit routing-options] juniper@SRX-12# deactivate static [edit routing-options] juniper@SRX-12# commit commit complete [edit routing-options] juniper@SRX-12#
Next we add the NAT'ed address space to the interfaces on SRX-11 and SRX-13 that share a common subnet with the client and server respectively. As we're planning on transtioning to the NAT'ed space, we mark the address used as the NAT space as the preferred address so all traffic generated from the router is source from that IP by default.
NAT'ed IP space on client interface on SRX-11
[edit interfaces ge-0/0/4]
juniper@SRX-11# show
description "Connection to Client";
unit 0 {
family inet {
address 192.168.1.1/24;
address 192.168.81.1/24 {
preferred;
}
}
}
[edit interfaces ge-0/0/4]
juniper@SRX-11#
NAT'ed IP space on server interface on SRX-13
[edit interfaces ge-0/0/3]
juniper@SRX13# show description "Connection to Server"; unit 0 {
family inet {
address 192.168.1.1/24;
address 192.168.80.1/24 {
preferred;
}
}
}
[edit interfaces ge-0/0/3] juniper@SRX13#
Next we advertise these direct routes out to the network with our IGP. As much as I hate to to redistribute connected routes and to create external routes in an IGP, this is actually one place where it is needed. We need to make sure that we do not advertise our overlapping IP space out to the rest of the network, but only our transtioning space. We need to write a very specific export policy to control this.
Export policy for SRX-11 and SRX-13 NAT'ed IP space (note regular expression for hostname)
[edit policy-options]
juniper@SRX-{11,13}# show
policy-statement MIGRATE {
from {
protocol direct;
route-filter 192.168.80.0/23 orlonger;
}
then accept;
}
[edit policy-options]
juniper@SRX-{11,13}#
To make this take effect, we apply it as an export policy in IS-IS on both SRX-11 and SRX-13.
Setting export policy on SRX-11
[edit] juniper@SRX-11# set protocols isis export MIGRATE [edit] juniper@SRX-11# commit commit complete [edit] juniper@SRX-11#
Next we check the routing tables to make sure our policy is working as intended. We can look at the routing table on SRX-12 instead of parsing through the IS-IS database for easy readability.
NAT'ed routes in routing table
juniper@SRX-12> show route
inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.99.0/24 *[Direct/0] 04:21:42
> via ge-0/0/0.0
10.0.99.12/32 *[Local/0] 04:21:44
Local via ge-0/0/0.0
172.18.1.0/24 *[Direct/0] 04:21:42
> via ge-0/0/4.0
172.18.1.12/32 *[Local/0] 04:21:44
Local via ge-0/0/4.0
172.18.2.0/24 *[Direct/0] 04:21:42
> via ge-0/0/5.0
172.18.2.224/32 *[Local/0] 04:21:44
Local via ge-0/0/5.0
192.168.11.11/32 *[IS-IS/15] 04:21:26, metric 10
> to 172.18.1.11 via ge-0/0/4.0
192.168.13.13/32 *[IS-IS/15] 04:21:01, metric 10
> to 172.18.2.13 via ge-0/0/5.0
192.168.80.0/24 *[IS-IS/160] 00:07:18, metric 20
> to 172.18.2.13 via ge-0/0/5.0
192.168.81.0/24 *[IS-IS/160] 00:07:46, metric 20
> to 172.18.1.11 via ge-0/0/4.0
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
49.0000.0000.0000.0012/72
*[Direct/0] 04:21:53
> via lo0.0
juniper@SRX-12>
Next we test in both directions to make sure our routing is working as intended.
Test from client to server
juniper@client:~$ ping -c 5 192.168.80.80 PING 192.168.80.80 (192.168.80.80) 56(84) bytes of data. 64 bytes from 192.168.80.80: icmp_req=1 ttl=61 time=5.05 ms 64 bytes from 192.168.80.80: icmp_req=2 ttl=61 time=5.01 ms 64 bytes from 192.168.80.80: icmp_req=3 ttl=61 time=11.2 ms 64 bytes from 192.168.80.80: icmp_req=4 ttl=61 time=5.76 ms 64 bytes from 192.168.80.80: icmp_req=5 ttl=61 time=5.12 ms --- 192.168.80.80 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 5.010/6.432/11.213/2.407 ms juniper@client:~$ traceroute -n 192.168.80.80 traceroute to 192.168.80.80 (192.168.80.80), 30 hops max, 60 byte packets 1 192.168.1.1 6.035 ms 5.987 ms 5.989 ms 2 172.18.1.12 12.277 ms 12.247 ms 12.263 ms 3 172.18.2.13 13.791 ms 13.788 ms 13.773 ms 4 192.168.80.80 14.929 ms 13.745 ms 13.743 ms juniper@client:~$
Test from server to client
juniper@server:~$ ping -c 5 192.168.81.81 PING 192.168.81.81 (192.168.81.81) 56(84) bytes of data. 64 bytes from 192.168.81.81: icmp_req=1 ttl=61 time=4.62 ms 64 bytes from 192.168.81.81: icmp_req=2 ttl=61 time=5.71 ms 64 bytes from 192.168.81.81: icmp_req=3 ttl=61 time=5.65 ms 64 bytes from 192.168.81.81: icmp_req=4 ttl=61 time=6.60 ms 64 bytes from 192.168.81.81: icmp_req=5 ttl=61 time=8.01 ms --- 192.168.81.81 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4007ms rtt min/avg/max/mdev = 4.620/6.118/8.010/1.137 ms juniper@server:~$ traceroute -n 192.168.81.81 traceroute to 192.168.81.81 (192.168.81.81), 30 hops max, 60 byte packets 1 192.168.1.1 2.108 ms 1.962 ms 1.894 ms 2 172.18.2.224 9.293 ms 11.294 ms 8.086 ms 3 172.18.1.11 11.068 ms 10.728 ms 10.664 ms 4 192.168.81.81 10.643 ms 10.625 ms 11.949 ms juniper@server:~$
With the above working configuration, the hosts on both sides of the network using the 192.168.1.0/24 address space can transition onto their unique address space on both sides at their own pace. Once a site completes the transition, the 192.168.1.0/24 address can be deleted form the interface on the SRX, the interface added to be advertised via the IGP natively, and then both the export policy and NAT rule can be deleted to complete the transition.