Cisco IOS NAT on a Stick Configuration Example


Brilliant article. Network Lessons is another great work done by you !!!

Continue this way you are great !!!

Dear Rene,
Very Thankful for your Post and all of them are very good for me.
Happy New Year !!! RENE

Interesting and epic work, seems to me like one of the funky CCIE scenarios…

Glad to hear you like it. It’s something I encountered during my CCIE studies.

Thanks Klaus! Glad you like it!

hi rene
i access a server That server not have GW behind a router how to config this nat ((plz describe DNAT and Full NAT in serprate article))


Hi Mostafa,

Take a look at this example:

You can use the same example if you want 1:1 NAT without specifying specific port numbers.



Great article! thanks for sharing.

I am wondering if there is a real world scenario where you would need to apply Nat on a Stick, specially the second exercise…



Hi Jose,

It’s unlikely to see this particular scenario…with the loopbacks, PBR and NAT it’s all a bit too much :slight_smile:

On the ASA it is common though. Sometimes you might encounter “hairpinning” (inside-to-inside NAT). The configuration is a bit more straight-forward. Take a look at this example:

ASA Hairpinning internal webserver


1 Like


Great!! explanation. :slight_smile:
You are awesome.

Thanks again bhargavi for your words. You message has been forwarded to Rene.

Good learning.

Very interesting ; but, I have some questions.

* Question-1

I do not see the signification of “PBR” in the lesson ?

* Question-2

In the first scenario, the answer is return back by a “Reply” arrow. But, in second and third scenarios, the answer is returned by a “NAT” arrow. What is the difference between “Reply” and “NAT” answers ?

Hello Maodo

If you notice after the second diagram, it states that any traceroute initiated from R1 to R2 will cause FastEthernet 0/0 to respond rather than going all the way to the loopback interface and back triggering a NAT translation. This is remedied by using PBR.

The difference is that in the first case, no NAT translations take place. After PBR is implemented, NAT translations take place, packets reach the loopback interface and are returned back to R1 having already gone through a NAT translation.

I hope this has been helpful!


Awesome article Rene! Thanks for putting it together. How about if we switch the INSIDE and OUTSIDE NAT interfaces? and configure the NAT translation instead. That way, there won’t be a need to configure a local policy.

[R1]--------------(NAT OUTSIDE) [R2] ---- loopback0 (NAT INSIDE)

ip nat inside source list 100 interface Loopback0 overload


 R1#traceroute numeric
 Type escape sequence to abort.
 Tracing the route to 
 VRF info: (vrf in name/id, vrf out name/id)
 1 3 msec *  2 msec

Hello Haseeb

Your scenario does indeed fulfill the requirement of having the loopback respond in the traceroute. Thanks for sharing that!

One of the restrictions that was mentioned in the lesson is that we require traffic to flow from the inside interface to the outside interface such that the sender of the ICMP packets is on the inside of the network.

It’s always interesting to see multiple scenarios and thanks once again for sharing!


Hey Rene and Laz,

It seems to work for me in a lab only when the NAT router is also the destination, but when my NAT router is in between the source and the destination then it will reply with its physical interface’s source IP rather than using the loopback’s IP.

Hello Nitay

What you describe is normal behaviour. If you have an arrangement where the NAT router is in between the source and destination, then the physical interface will indeed reply. This is because, in such a situation, you have two hops, whereas, in the lesson, the traceroute response is only a single hop.

What the lesson is asking for is that the loopback IP address respond for the router for traceroute instead of the physical address. The loopback address is on the same router, so it doesn’t count as another hop.

I hope this has been helpful!


Hey :slight_smile:
Is the policy route-map will overload the CPU?
Every packet to the outside have to go through the policy…

Hello Adi

Policy route maps will indeed use some CPU resources in order to function. Will they overload the CPU? Well, that depends on a lot of things, such as the CPU capacity, the platform being used, the amount of memory available, as well as the expected traffic, and the complexity and number of policy route maps being applied.

For the most part, routers are designed to be able to handle large amounts of data and to process them via route maps. As you design such route maps, just be aware of the possibility of overloading the CPU, so that if it does occur, you can be ready for it and act accordingly.

Ultimately, you’ll have to experiment with the implementation, keeping an eye on the CPU usage. CPU usage will go up well before there is any failure, so you can monitor it and avoid any catastrophic failures well before they occur.

I hope this has been helpful!


Thanks a lot laz :pray:t2:


1 Like