In this post I’m going to talk about Cisoc IOS 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:
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp key AREFPASS address 10.10.10.1
crypto ipsec transform-set AREFSET esp-3des esp-md5-hmac
crypto map AREFMAP 10 ipsec-isakmp
set peer 10.10.10.1
set transform-set AREFSET
match address 100
!
interface Loopback2
ip address 192.168.2.2 255.255.255.0
ip nat inside
interface FastEthernet0/0
ip address 10.10.10.2 255.255.255.0
ip nat outside
crypto map AREFMAP
!
ip route 192.168.1.0 255.255.255.0 10.10.10.1
ip nat inside source list 101 interface FastEthernet0/0 overload
!
access-list 100 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 101 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 101 permit ip 192.168.2.0 0.0.0.255 any
Configuration on Edge:
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp key AREFPASS address 10.10.10.2
crypto ipsec transform-set AREFSET esp-3des esp-md5-hmac
crypto map AREFMAP 10 ipsec-isakmp
set peer 10.10.10.2
set transform-set AREFSET
match address 100
!
interface Loopback1
ip address 172.16.1.1 255.255.0.0
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
ip nat enable
crypto map AREFMAP
interface FastEthernet0/1
ip address 192.168.1.1 255.255.255.0
ip nat enable
!
ip nat source list 101 interface FastEthernet0/0 overload
ip route 192.168.2.0 255.255.255.0 10.10.10.2
!
access-list 100 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
Let’s start by verifying the basic L3 connectivity between EDGE and R2:
EDGE#ping 10.10.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
EDGE#
R2#ping 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R2#
Now let’s enable some debug to verify how the L2L traffic reaches each end:
EDGE#deb ip nat
IP NAT debugging is on
EDGE#deb ip icmp
ICMP packet debugging is on
EDGE#
R2#
R2#deb ip nat
IP NAT debugging is on
R2#deb ip icmp
ICMP packet debugging is on
R2#
HOST-192.168.1.2#deb ip icmp
ICMP packet debugging is on
HOST-192.168.1.2#
Let’s ping again but from the local network of EDGE to the local network of R2:
HOST-192.168.1.2#ping 192.168.2.2 rep 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
..
Success rate is 0 percent (0/2)
HOST-192.168.1.2#
EDGE#
NAT*: s=192.168.1.2->10.10.10.1, d=192.168.2.2 [7]
EDGE#
NAT*: s=192.168.1.2->10.10.10.1, d=192.168.2.2 [8]
EDGE#
R2#
ICMP: echo reply sent, src 192.168.2.2, dst 10.10.10.1
NAT: s=192.168.2.2->10.10.10.2, d=10.10.10.1 [7]
R2#
ICMP: echo reply sent, src 192.168.2.2, dst 10.10.10.1
NAT: s=192.168.2.2->10.10.10.2, d=10.10.10.1 [8]
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:
access-list 102 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
Here I will create a loopback interface on EDGE:
int lo1
ip add 172.16.1.1 255.255.255.0
And here is the route map:
route-map BYPASSING-NAT permit 10
match ip address 102
set interface Loopback1
Now I will apply this route map on the interface f0/1 on EDGE where the network 192.168.1.0/24 is attached:
int f0/1
ip policy route-map BYPASSING-NAT
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:
HOST-192.168.1.2#ping 192.168.2.2 rep 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
.!
Success rate is 50 percent (1/2), round-trip min/avg/max = 4/4/4 ms
HOST-192.168.1.2#
ICMP: echo reply rcvd, src 192.168.2.2, dst 192.168.1.2
HOST-192.168.1.2#
EDGE#deb ip policy
Policy routing debugging is on
EDGE#
IP: s=192.168.1.2 (FastEthernet0/1), d=192.168.2.2, len 100, FIB policy match
IP: s=192.168.1.2 (FastEthernet0/1), d=192.168.2.2, len 100, PBR Counted
IP: s=192.168.1.2 (FastEthernet0/1), d=192.168.2.2, len 100, policy match
IP: route map BYPASSING-NAT, item 10, permit
IP: s=192.168.1.2 (FastEthernet0/1), d=192.168.2.2 (Loopback1), len 100, policy routed
R2#
ICMP: echo reply sent, src 192.168.2.2, dst 192.168.1.2
R2#
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.
Now I will issue another 5 pings and check the encrypted and decrypted packets again just to make sure everything is working properly:
HOST-192.168.1.2#ping 192.168.2.2 rep 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
HOST-192.168.1.2#
EDGE#sh crypto sess
Crypto session current status
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 10.10.10.2 port 500
IKEv1 SA: local 10.10.10.1/500 remote 10.10.10.2/500 Active
IPSEC FLOW: permit ip 192.168.1.0/255.255.255.0 192.168.2.0/255.255.255.0
Active SAs: 2, origin: crypto map
R2#sh cry sess
Crypto session current status
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 10.10.10.1 port 500
IKE SA: local 10.10.10.2/500 remote 10.10.10.1/500 Active
IPSEC FLOW: permit ip 192.168.2.0/255.255.255.0 192.168.1.0/255.255.255.0
Active SAs: 2, origin: crypto map
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!
