NAT (Network Address Translation) is most commonly used to let users on our LAN access the Internet using a single public IP address but it can be used for some more interesting scenarios. Recently I encountered an interesting CCIE R&S task that had the following requirement:
"Make sure that whenever R2 responds to a traceroute it replies with the IP address on the loopback 0 interface"
This sounds easy enough but there’s no such thing as a “traceroute source loopback 0″ command or anything alike. To make this work we have to configure the NAT on a stick feature. In this tutorial I’ll show you this is done. First of all, this is the topology that we will use:
There are only two routers that are directly connected to each other. R2 has a loopback 0 interface with IP address 2.2.2.0 /24. Let’s configure these IP addresses first:
R1(config)#interface fa0/0
R1(config-if)#no shutdown
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R2(config)#interface fa0/0
R2(config-if)#no shutdown
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config-if)#interface loopback0
R2(config-if)#ip address 2.2.2.2 255.255.255.0
Before we dive into the NAT configuration let’s do a trace and look at the output:
R1#traceroute 192.168.12.2
Type escape sequence to abort.
Tracing the route to 192.168.12.2
1 192.168.12.2 0 msec 4 msec *
As expected R2 responds with the IP address on its FastEthernet interface. The task requires this output to show the 2.2.2.2 address from the loopback interface. To achieve this we’ll configure NAT on R2:
R2(config)#access-list 100 permit icmp any any time-exceeded
R2(config)#access-list 100 permit icmp any any port-unreachable
R2(config)#ip nat inside source list 100 interface loopback0 overload
R2(config)#interface fastethernet 0/0
R2(config-if)#ip nat inside
R2(config)#interface loopback 0
R2(config-if)#ip nat outside
The configuration above defines the FastEthernet interface as NAT inside and the loopback interface as NAT outside. An access-list is used to permit the ICMP time-exceeded and port-unreachable packets that are used as a response to a traceroute. The NAT configuration itself is complete but we still have a problem with this setup, take a look at the following picture:
If you look closely at the image above you can see that whenever R1 does a trace, R2 will reply with its FastEthernet 0/0 interface. In order for NAT to work traffic has to
flow from the inside interface to the outside interface. To fix this we can configure policy based routing on R2 to forward traffic to the loopback 0 interface:
R2(config)#route-map FORWARD_TO_L0
R2(config-route-map)#match ip address 100
R2(config-route-map)#set interface loopback0
R2(config)#ip local policy route-map FORWARD_TO_L0
This route-map matches on the interface that we created before and forwards the traffic towards the loopback 0 interface. We also require the ip local policy command to apply the route-map to self-generated traffic. Let’s enable a debug on R2 and try that traceroute again from R1:
R2#debug ip policy
Policy routing debugging is on
R2#debug ip nat
IP NAT debugging is on
Time to trace!
R1#traceroute 192.168.12.2
Type escape sequence to abort.
Tracing the route to 192.168.12.2
1 2.2.2.2 0 msec 4 msec *
Excellent, we now see IP address 2.2.2.2 from R2 in our traceroute. Let’s take a look at the debug on R2:
R2#
IP: s=192.168.12.2 (local), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L0, item 10, permit
IP: s=192.168.12.2 (local), d=192.168.12.1 (Loopback0), len 56, policy routed
IP: local to Loopback0 192.168.12.1
NAT: s=192.168.12.2->2.2.2.2, d=192.168.12.1 [17]
The first line is the ICMP packet from R2 towards R1 that it wants to send as a reply to the traceroute. It matches the route-map so it is being policy based routed towards the loopback 0 interface. Since the loopback 0 interface is configured for NAT outside, IP address 192.168.12.2 is translated to 2.2.2.2 and then routed towards R1. Basically it looks like this:
Great! it’s working as it should…what if we make this scenario a little bit more interesting by changing the task as following:
"Make sure that whenever R2 responds to a traceroute it replies with the IP address on the loopback 0 interface, you are not allowed to configure NAT on the FastEthernet interface but you may configure an additional interface and IP address."
No problem! We can still make this work but we’ll have to use another interface that is configured with the “IP NAT inside” command. Traffic still has to flow from a NAT inside interface to a NAT outside interface in order to be translated. To accomplish this we will create a new loopback interface that has the “IP NAT inside” command. We will send traffic from the FastEthernet interface to the new loopback and then forward it to the first loopback interface. I know this sounds funky so let me help you visualize it:
Just follow the arrows starting at R1. This is what we have to configure:
- Configure policy based routing so that the ICMP replies are forwarded from the FastEthernet interface to the new loopback 1 (NAT inside) interface.
- Configure policy based routing so that the ICMP replies are forwarded from the loopback 1 interface to the loopback 0 (NAT outside) interface.
First we’ll remove the NAT configuration from the FastEthernet interface and I’ll also get rid of the policy based routing configuration:
R2(config)#interface fa0/0
R2(config-if)#no ip nat inside
R2(config)#no ip local policy route-map FORWARD_TO_L0
Let’s create a new loopback interface. I just made up an IP address, it really doesn’t matter what we configure here as long as there’s something. Don’t forget to add IP NAT inside:
R2(config)#interface loopback 1
R2(config-if)#ip address 22.22.22.22 255.255.255.0
R2(config-if)#ip nat inside
We will create a new route-map that forwards ICMP traffic to the loopback 1 interface:
R2(config)#ip local policy route-map FORWARD_TO_L1
R2(config)#route-map FORWARD_TO_L1
R2(config-route-map)#match ip address 100
R2(config-route-map)#set interface loopback 1
The route-map that we created before can now be applied to the loopback 1 interface. This ensures that traffic is forwarded to the loopback 0 interface:
R2(config)#interface loopback1
R2(config-if)#ip policy route-map FORWARD_TO_L0
That should do it. Let’s try our trace again:
R1#traceroute 192.168.12.2
Type escape sequence to abort.
Tracing the route to 192.168.12.2
1 2.2.2.2 4 msec 4 msec *
Excellent, it’s working! What does the debug look like now?
R2#
IP: s=192.168.12.2 (local), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L1, item 10, permit
IP: s=192.168.12.2 (local), d=192.168.12.1 (Loopback1), len 56, policy routed
IP: local to Loopback1 192.168.12.1
IP: s=192.168.12.2 (Loopback1), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L0, item 10, permit
IP: s=192.168.12.2 (Loopback1), d=192.168.12.1 (Loopback0), len 56, policy routed
IP: Loopback1 to Loopback0 192.168.12.1
NAT: s=192.168.12.2->2.2.2.2, d=192.168.12.1 [21]
Look closely at the debug and you can see that the ICMP traffic is forwarded to the loopback 1 interface, then to the loopback 0 interface and because it flowed from a NAT inside to a NAT outside interface it can now be translated.
That’s all I have for you now, hopefully you enjoyed this tutorial! If you have any questions feel free to leave a comment.
Read more: http://networklessons.com/network-services/cisco-ios-nat-stick-configuration-example/#ixzz2r0GlbUxU
