NAT - add-route keyword

When configuring Network Address Translation (NAT) there are some issues that may come up concerning the translation of both outside and inside addresses due to the default order of operation when this feature is applied.

This order of operations may cause a failure in either routing or translation during the traversal of the NAT device. For example, consider the following topology:

nat-add-route-keyword.png

R2 is configured as the NAT route with Gi0/1 as the inside interface and Gi0/2 as the outside interface.

Now consider the following NAT translation rules configured in R2:

R2(config)#ip nat inside source static 192.168.12.1 192.168.23.1
R2(config)#ip nat outside source static 192.168.23.3 192.168.12.3

In the above scenario, we are translating both inside and outside addresses. Specifically:

  • The Gi0/1 interface of R1 with an inside IP address of 192.168.12.1 is being translated to the outside address of 192.168.23.1 on the WAN.
  • The Gi0/1 interface of R3 with an outside IP address of 192.168.23.3 is being translated to the inside address of 192.168.12.3.

In such a scenario, R3 should be able to ping the 192.168.23.1 address which should result in an echo request sent to R1 and an echo reply sent back to R3.

However, due to the order of operations in R2, this will fail. Why? Let's take a look:

R3 sends a ping to R1 with a destination address of 192.168.23.1. This echo request packet reaches R2 with a source IP address of 192.168.23.3 and a destination address of 192.168.23.1. Based on the order of operation, when the packet is received on the outside interface, NAT translations must be performed first, and then routing. So the source address of 192.168.23.3 is translated to 192.168.12.3 and the destination address is translated from 192.168.23.1 to 192.168.12.1.

R2 will then do a routing table lookup for the destination (192.168.12.1) and forwards it towards R1. R1 responds with an echo reply with a destination IP address of 192.168.12.3, which is R3's inside address.

When R2 receives this packet, based on order of operations for inside interfaces, it performs routing first. R2 does a lookup in the routing table for the destination of 192.168.12.1, finds a matching entry for its GigabitEthernet0/1 interface and sends it out of the interface. This packet is never translated and will never make it to R3.

To resolve this issue, we use the add-route keyword on the ip nat outside command like so:

R2(config)#ip nat outside source static 192.168.23.3 192.168.12.3 add-route

This will add a static route for the outside local address, thus resolving the issue.

The above solution is used in IOS versions before version 15.X because in these versions of IOS, host routes are created in the Routing Table that overrule the static route. For versions 15.X and higher, instead of using the add-route” parameter, you can also use a static route like so:

ip route 192.168.12.3 255.255.255.255 192.168.23.3

The above solution is considered a solution for "legacy NAT." For more modern implementations, a preferred solution is the use of a NAT virtual interface.

Links:

https://forum.networklessons.com/t/nat-virtual-interface/1337/47?u=lagapides

https://networklessons.com/cisco/ccie-routing-switching/nat-virtual-interface

Links to this page: