In this post I’m going to talk about NAT exemption. As we know NAT plays a very important role in our networks today, however, with all the benefits we get from NAT’ing, sometimes we don’t need it, or more specifically we need to bypass it. A common case scenario would be for VPN traffic where we don’t want to translate the original IP addresses. In this post I’m going to show you how to exempt NAT by applying a tricky configuration on IOS without having to go through the common way of doing it.
The common way we do that is to add a deny statement at the top of the NAT (PAT) access list so the traffic going from site A (EDGE in our topology) to site B (R2 in our topology) will not be subject to NAT; so far so good. But here I will show you how to do that without relying on the NAT (PAT) access list, instead using route maps, and instructing the traffic to go through a specific path and bypass the NAT. The reason I want to talk about this other way to exempt NAT is because by doing so we will learn a very important thing about NATing, which we have to keep in mind always when we implement it. I will tell you about it at the end of this blog so that it will be clearer after we go through the lab below.
The topology on which we will work is very simple, two sites configured with L2L IPsec VPN on Cisco IOS, on both sites NAT (PAT) is applied, but NAT exemption is applied only on R2. Let’s get started.
Configuration on R2:
Configuration on Edge:
Let’s start by verifying the basic L3 connectivity between EDGE and R2:
Now let’s enable some debug to verify how the L2L traffic reaches each end:
Let’s ping again but from the local network of EDGE to the local network of R2:
As you can see, the ping is not successful. This is because when host 192.168.1.2 sent the traffic to the host 192.168.2.2, EDGE has applied NATing (PAT) to that traffic, so it arrived at host 192.168.2.2 sourcing from 10.10.10.1. And when host 192.168.2.2 replies back, R2 also applied NATing (PAT) to the return traffic from host 192.168.2.2 towards 10.10.10.1, so it arrived at EDGE sourcing from 10.10.10.2 destined to itself, so it terminates there. We can see that the NAT exemption applied on R2 to the traffic from network 192.168.2.0/24 towards 192.168.1.0/24 did not kick in here because the destination address in the reply traffic is 10.10.10.1. That is a normal behavior considering the current configuration, because as you can see, I did not apply yet any NAT exemption on EDGE.
Now in order to have full connectivity between the remote networks, I’m going to apply NAT exemption on EDGE with a route map that will match the traffic going from 192.168.1.0/24 towards 192.168.2.0/24 and re-route it to a loopback interface on EDGE where no NAT command (ip nat inside/outside or ip nat enable) is configured. And then, from that interface the traffic will be re-routed again to the final destination, let’s verify it together. First I will create the access list that defines the traffic from EDGE’s network to R2’s one:
Here I will create a loopback interface on EDGE:
And here is the route map:
Now I will apply this route map on the interface f0/1 on EDGE where the network 192.168.1.0/24 is attached:
Now let’s enable another debug on EDGE which is deb ip policy and issue some ICMP traffic again from host 192.168.1.2 towards 192.168.2.2:
As we can see, now the traffic is flowing correctly between the two networks and it is not being subjected to NATing. Both the source and the destination addresses are preserved to the original private ones.
Just to double check, here we can see that we already have some packets encrypted and decrypted:
Now I will issue another 5 pings and check the encrypted and decrypted packets again just to make sure everything is working properly:
As you can see, we now have 16 packets either for the encrypted or decrypted ones. That means the traffic is flowing correctly and it is being passed through the tunnel as expected.
Ok, so what is the point here?! Well, the very important thing to keep in mind when it comes to NAT is the traffic flow. As we can see, if the incoming traffic does not go directly from an ingress interface (f0/1 in our topology) to an egress interface (f0/0 in out topology) NAT will not be triggered. Please remember that Loopback1 interface on EDGE has no NAT command applied. So NAT will only work if that traffic flows from the ingress interface to the egress one directly.
In our example the f0/1 on EDGE is the inside interface and the f0/0 is the outside one. This happens whether we use the “legacy” NAT configuration (ip nat inside/outside) or the new one with NVI (ip nat enable). With the legacy one, we have to manually define the inside interface and the outside one, but with NVI the device will automatically find it.
I hope you enjoyed reading this post, and as always, I would love to hear your feedback. Thanks for reading.