NAT (Network Address Translation) is widely used technology which solves many problems like enabling internal hosts(private IP address range) to communicate with outer world, adding an extra security layer by hiding internal IP address etc.

In this blog post I am going to discuss a small but widely common NAT issue. Please see the following :

Issue :The end to end connectivity dropped after applying NAT on R1 in the given scenario…

R1(config)#ip nat outside source static 192.168.20.2 60.60.60.1

With this NAT statement we want to translate the source of the packet(coming from 192.168.20.2) hitting NAT outside interface of the router to 60.60.60.1. This is one to one static translation(192.168.20.2—>60.60.60.1). However as soon as we have applied this configuration the end to end connectivity broke. Following is the complete configuration on the NAT router(R1).

interface FastEthernet0/0
 ip address 192.168.10.1 255.255.255.0
 ip nat inside
!
interface FastEthernet1/0
 ip address 192.168.20.1 255.255.255.0
 ip nat outside
!

ip nat outside source static 192.168.20.2 60.60.60.1

With this configuration we see that HOST1 is able to ping HOST 2 however HOST 2 is not able to ping HOST 1.

HOST1#ping 192.168.20.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/406/1072 ms

HOST2#ping 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

To look into more details we will take packet captures. Below is the capture taken between R1 and HOST2:

Here we clearly see that we are not receiving ICMP responses. which means several things , few are below:

• HOST1 is not responding
• HOST1 is responding but R1 is dropping the response
• R1 is not forwarding the request to HOST1

To rule out the our doubts we need another packet capture between R1 and HOST 1. Following is the packet capture between R1 and HOST1:

Packet capture between HOST 1 and R1 reveals that R1 is forwarding the ICMP requests to HOST 1. HOST 1 is responding with ICMP response. Which means the echo responses are dropped on R1.

Looking at the packet capture in detail we also see that R1 is not silently dropping the ICMP echo response. It sends a Destination host Unreachable message back to HOST 1 to inform that the destination in the packet (60.60.60.1) is not reachable from the R1. We can check R1’s routing table to confirm the same.

R1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 192.168.10.0/24 is directly connected, FastEthernet0/0
C 192.168.20.0/24 is directly connected, FastEthernet1/0

Aright !! now we know that drops are seen due to the fact that we do not have route for 60.60.60.1 which is the destination for the icmp responses. But shouldn’t NAT be translating the destination back to 192.168.20.2 and then routing should take care of forwarding the packet out of interface fa 1/0 ?

The answer of this question lies in a very basic concept ” order of operation”. So here we know that the packet is dropped due to inappropriate routing and we know that NAT should take care of translating the destination of response packet back to 192.168.20.2 but it looks like this is not happening. Which means the packet is getting routed before the translation table lookup. And indeed this is the case…following is the general rule.

• Routing triggers before NAT if packet hits the NAT inside interface.
• NAT triggers before the routing if packet hits the outside NAT interface.

Now since we know that we have route issues in out network. We have two options to fix this.

1. Configuring a static route for 60.60.60.0 network towards Fa1/0
2. Or leveraging “add-route” feature of NAT .

We will opt the second option and lets modify the NAT rule on the router :

R1(config)#no ip nat outside source static 192.168.20.2 60.60.60.1
R1(config)#ip nat outside source static 192.168.20.2 60.60.60.1 add-route
R1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 192.168.10.0/24 is directly connected, FastEthernet0/0
C 192.168.20.0/24 is directly connected, FastEthernet1/0
 60.0.0.0/32 is subnetted, 1 subnets
S 60.60.60.1 [1/0] via 192.168.20.2

Now lets check if connectivity is stored :

HOST2#ping 192.168.10.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/85/108 ms

And it worked like a charm!! Thank you.

Stay tuned for more on NAT.