Network Address Translation (NAT) Trick

Hi all,

This is my first blog, I hope readers will find of value in it. I’m going to be concise and focus on the topic without overwhelming you with lots of explanations, hopefully it will light and welcoming to read.

 

Today I’m going to talk about NAT exemption. As we know NAT plays a very important role in our networks today. And there are different of types and a bunch of tricks that we can use as a workarounds in different scenarios. And even with all the benefits of NAT, we do still need to bypass it sometimes in specific scenarios, like for VPN tunnel traffic between two remote end points.

 

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.

 

Topology:

 

VIP_Aref_Blog_1.jpg

 

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

 

 

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.

 

Just to double check, here we can see that we already have some packets encrypted and decrypted:

 

VIP_Aref_Blog_2.jpg

 

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#

 

VIP_Aref_Blog_3.jpg

 

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.

 

Furthermore:

 

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 this information is helpful and I am happy to be posting my first blog as VIP.

Thanks to everyone for reading | Aref.