Address translation (NAT) is one of the big topics on the JNCIE-SEC exam. Generally the NAT area is overall very broad covering source NAT and destination NAT with or without port translation, static NAT, address persistency, etc. This text presents only a specific part of this area - namely an option how to use the OSPF protocol for advertising networks used for translation. This example does not cover the overall device configuration – such as interfaces, zones, security policies, etc.
The topology depicted below was used for this example.
The SRX1 and SRX2 have interfaces connected to networks with overlapping addresses (10.10.10/24). Static NAT is configured to provide reachability between hosts from these overlapping ranges. The configuration is shown below. SRX1 uses the 30.30.30/24 prefix for translation and the SRX2 uses the 20.20.20/24 prefix.
OSPF is enabled on the ge-0/0/1.0 and ge-0/0/3.0 interfaces. Where adjacency is formed with the neighbor over the ge-0/0/1.0 interface and the interface ge-0/0/3.0 is in passive mode. Passive mode means the OSPF will advertise only the network but not form any adjacencies on that interface.
Currently following active routes from OSPF are in the routing table.
The goal is to create static routes that represent the NAT networks. These static routes will then be placed in the routing table. The export of these static routes into OSPF will be done through routing policy. And then the OSPF will take care of propagating the information further through the network.
The created static routes will have “reject” as the action defined. Other values for the action could also work (such as “next-hop”, “next-interface”, etc.) but the “reject” option specifically results in dropping the traffic if the packets are not translated. This is due the fact that the destination NAT translation takes place before the route lookup. I.e. for the translated packets the device uses the new changed (post-NAT) address for lookup and for not translated packets the original address from the packet.
Next thing is to configure routing policy. Remember to pay a great deal of attention when defining the criteria and be as precise as possible to avoid matching other routes.
The last step is to define the newly created routing policy in the OSPF protocol as the export policy.
After committing the configuration the OSPF protocols starts to advertise the new routes that match the routing policy. This can be verified by looking at the OSPF routes in the routing table.
The session table can be used to examine whether correct address translation takes place. The sessions below are the result for the ping initiated from 10.10.10.1 on SRX2 and destined to the 30.30.30.1 IP address.
Also the flow traceoptions entries from SRX1 confirm the address translation has been performed:
The traceoptions entries below from SRX1 illustrate the processing for a packet destined to the 30.30.30.1 IP address that has not being translated.
The approach described above show how the OSPF protocol can be used to distribute the reachability information for the networks used for address translation. It is based on static routes and routing policies. More information about general or advanced NAT topics can be found in the iNET ZERO’s JNCIE-SEC workbook.
