NAT Virtual Interface

Hello Juan

From my understanding, this is your topology (correct me if I’m wrong:


You are translating:

  • on the WAN interface to
  • on the WAN interface to

So, you are able to remote into Device 1 from Device 2 ONLY when you connect via the address and you cannot connect when you attempt to connect directly to Correct?

If this is the case, then the NAT configuration has nothing to do with the problem. Any communication between Device 1 and Device 2 using the IP addresses will be directly between them. So the only thing I can suggest is that there is an access list or a firewall rule on device 1 blocking any connectivity to it from a source address of

Take a look at any such configuration and let us know your progress…

I hope this has been helpful!


Thanks Laz for the quick response. Great diagram depicts exactly what I was labbing. Its strange that it doesn’t work i did this in a lab enviroment with very basic configs. I Just ip’d the interfaces and setup up nat. The strange part is that it works perfectly fine using domian nat defining inside and outside interfaces. But once i remove those commands and add ip nat enable on the interfaces unless i define the mapped ip in this case port 80 i cant remote into the device anymore using its real IP which is why i thought it was an NAT VI limitation.

Thanks Rene… that was lucid and laid threadbare… commendable effort mate.

I have a general question. For this demo you had turned off Fast Switching by no ip route-cache and your debugs show routed via RIB .

Is it safe to say… all NAT traffic will be punted to CPU, as IP addresses on the NAT devices are involved?


Hello Ayyappan

The quick answer is “it depends.” Really it depends on the platform. For the Catalyst 6500 switches with 720 supervisors, for example, NAT is handled in hardware while with Supervisor 1 and 2, NAT is software switched.

According to the following Cisco documentation,

“Cisco IOS NAT supports Cisco Express Forwarding switching, fast switching, and process switching.”

Regardless, the fact that the no ip route-cache command has been applied does indeed mean that all packets entering the layer-3 interface will be process switched by the CPU instead of hardware, whether NATed or not.

I hope this has been helpful!



Hi Team,
Can you please explain more about Match-in-VRF Support for NAT. Cisco documentation on this topic is hard to digest :slight_smile: It would be great if you can elaborate using below example

ip nat inside source static vrf vrf1 match-in-vrf

Hello Aniket

First of all, it is important here to clarify what kind of scenario we are talking about when we speak about VRFs. This is described as follows in Cisco documentation:

Virtual Private Networks (VPNs) provide a secure way for customers to share bandwidth over an ISP backbone network. A VPN is a collection of sites sharing a common routing table. A customer site is connected to the service provider network by one or more interfaces, and the service provider associates each interface with a VPN routing table. A VPN routing table is called a VPN routing/forwarding (VRF) table.

When you have multiple VRFs, there is the possibility of having the same address space connected to multiple VPNs of a router. So you may have the address exist in one network, which is routed using the routing table of VRF1, and you may have the same address in another network, which is also routed by this router, but in VRF2. That’s fine and it should work well.

But what if you want this same router to perform NAT on these particular IP addresses? They are both the same, so if you simply use the following command:

ip nat inside source static

…then both hosts with this IP address will be translated to the same outside address. This however will not work.

You can enable VRF awareness onNAT by adding the VRF to which each translation should be mapped. This way, internally identical IP addresses on different VRFs, when NATted, will obtain unique global addresses.

But, what happens when you want these two hosts connected to two different VPNs, with identical IP addresses, to communicate directly with each other? Or to communicate with a subnet on another VPN that may have the same IP address range? This is where the match-in-vrf keyword comes in. It extends the VRF awareness of NAT such that inter-VPN communication can take place. In other words, communication from one VPN to another VPN on the same router can take place, using NAT.

What the keyword does specifically is, for inter-VPN traffic, it allows the translation of to the required address in the other VPN while keeping track of which VRF it originally came from. Otherwise, inter VPN communication would not function, because belongs to multiple VPNs.

I hope this has been helpful!



Thanks for an explanation Laz,

Still having doubt about the last section which you have explained. You said that match-in-vrf comes in picture where communication from one VPN to another VPN on the same router takes place, using NAT.Above that line you mentioned “intra-VPN” communication keyword. I believe you wanted to say “inter-VPN” communication ?

Hello Aniket

Yes you are correct, my apologies. It should be inter-VPN. I have fixed it in my post.

Thanks again!


Hello Rene,
Thanks for the lesson,
in the first example below:

R2(config)#ip nat inside source static

my question is: why the global IP address is not
Thanks in advance

Hello Wisam

It is possible to create a NAT rule that will translate using the actual assigned IP address of the outside interface of the NAT router, or, you can use an IP address that is not actually assigned to the outside interface, but is routed to that interface from the WAN network. In this case, the outside IP address being used is not the same as that of the outside interface. This will function correctly, as long as the WAN “knows” about this address and will route this address correctly to the appropriate router.

This is also the case when you have a pool of external IP addresses that are NAT’ed to internal addresses. They need not be assigned to the actual outside interface.

I hope this has been helpful!



Hi Rene & Co,
Thanks for the great content and I hope that all you are safe during this pandemic time.
Just to let you know that it can be very valuable if during your various demo you provide bit of informations about your environment like (IOS/IOS-XE/IOS-XR) version.
It’s little difficult when practice and don’t have the same result because IOS version are different for example.
I’m using IOS 15.7(3)M3 for this lesson and the debug output are very different with new terms like: FIBipv4-packet-proc, FIBfwd-proc… etc…
Best Regards

1 Like

Hi Rene & NL Team,
Please, I want to know if it’s possible to disable ip route-cache in “Cisco IOS XE Software, Version 03.16.09.S - Extended Support Release”…
I have the following message when I try to run no IP route-cache on an interface for debugging purposes. “Platform cannot disable ip route-cache on Port-channel interface”

1 Like

Hello Thierry

Disabling route caching on an interface will also disable CEF. On some platform/operating system versions it is not possible to disable CEF, such as is the case with your situation. In this case, in order to see the debug take place, you can do one of two things:

  1. You can create an access list with a single permit any statement and include the “log” keyword. This will result in all packets being examined, and logged, and thus CPU switched. Such traffic will show up in the debugs. For example:

    ip access-list extended MY_TEST
      permit ip any any log
  1. You can use Embedded Packet Capture (EPC) to capture the packets you want and to examine them accordingly. You can find out more about this at the following lesson:

Concerning your suggestion about specifying the IOS that Rene uses in his lessons, I will relay the information to him and let him know.

I hope this has been helpful! Stay healthy and safe!



Thanks Laz,
EPC is great on IOS-XE platform, a bit complex on IOS.
But I found that we lack of some informations on packet capture. for example, when logging IP NAT, you can clearly observe when IP @ have been translated. I will try the ACL Log method to see.

1 Like

Hello Thierry,

I’m doing good here, we are safe. I hope you as well?

I agree this is a good idea. I think I’ll include it in every configuration now. Throughout the years, it happened multiple times that something worked on version X, but didn’t work or had different behavior on version Y.


1 Like

Hi I have a question, in the NAT virtual interface, almost at the end of the video, if you are sending a ping from R3 to, why the ping goes til R1 ? if the ping was meant to, I think my question is why it the debugs we see that the ping goes till R1 if R1 is suppossed to be out of the picture, thank you in advance

Hello Armando

Remember that in that particular configuration, the address (R1) is being translated to (global address of R1) and visa versa. So when R3 pings, it reaches R2, and the NAT config translates it to which is R1.

The purpose of the lab was to reach R1 from R3 using the address. The process reaches R1 because of the NAT translation.

I hope this has been helpful!


1 Like

Can I do Virtual NAT over port channel? specifically on Catalyst 9500?
According to the Cisco documentations they’re saying I can’t do NAT, they haven’t mentioned virtual nat!

I was trying to NAT my uplink to the ISP

so I just found that we have two ASRs 1001-x instock, now I have a different question, the throughput on these routers are determined based on the license you buy? and since the ASR 1k doesn’t support nVR clustering how should I make my uplink port channel-ed across the chassis(for redundancy)?

Hello Erik

Looking at the documentation you linked to, I don’t see where it says that you can’t do NAT. Actually, I see that you can do NAT. Concerning virtual NAT, I haven’t attempted it on the specific platform, but I have the impression that it is not supported. Looking at this Command Reference for the Catalyst 9500 I was unable to find the command ip nat enable which seems to indicate that it is not supported.

Virtual NAT is a feature that you would use more often on an edge router rather than a switch like the 9500 so it makes sense that you won’t find it on such a switch model.

Yes, by default, the available system bandwidth is at 2.5Gbps and is upgradable to 5 Gbps with a software-activated upgrade license.

Depending on what your routers are connecting to on the ISP side of the link, you have several options including dual-homed BGP connections, using a gateway redundancy protocol, or simply employing dynamic routing that can employ equal or unequal cost load balancing. There is no way to implement a port-channel-like implementation with the specific devices.

I hope this has been helpful!


1 Like

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)