NAT Virtual Interface

The most common method to configure NAT on Cisco IOS routers is what we call “domain based NAT”. Each interface on the router has to be configured as “inside” or “outside”. This method of configuring NAT is considered the legacy method. The new way of configuring NAT is by using the NAT virtual interface.

The most common method to configure NAT on Cisco IOS routers is what we call "domain based NAT". Each interface on the router has to be configured as "inside" or "outside". This method of configuring NAT is considered the legacy method. The new way of configuring NAT is by using the NAT virtual inte


Before I show you the configuration of the NAT virtual interface, let’s look at the differences between legacy NAT and the NAT virtual interface.

When we use the inside and outside domains then the “order of operations” of the router looks like this:

Cisco NAT Inside Outside Operations

When an IP packet is received on the inside interface, then the router will first do a looking in the routing table and then it will perform NAT translation. When we receive IP packets on the outside interface, then it’s the other way around:

Cisco NAT Outside Inside operations

IP packets will first be NAT translated and then routed. Now you might be wondering, why should I care about this? To answer that question, we’ll have to do a little experiment. Here are three routers that we will use:

R1 R2 R3 NAT Virtual Interface

R1 on the left side is on our LAN, the “inside” of our network. R3 is on the “outside” and R2 will be configured for NAT.

Configurations

Want to try this example yourself? Here you will find the startup configuration of each device.

R1

hostname R1
!
no ip routing
!
no ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.12.1 255.255.255.0
!
end

R2

hostname R2
!
ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 192.168.23.2 255.255.255.0
!
end

R3

hostname R3
!
no ip routing
!
no ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.23.3 255.255.255.0
!
end

Let’s start by defining the inside and outside interfaces and we’ll add a simple static NAT rule:

R2(config)#interface GigabitEthernet 0/1
R2(config-if)#ip nat inside

R2(config)#interface GigabitEthernet 0/2
R2(config-if)#ip nat outside

R2(config)#ip nat inside source static 192.168.12.1 192.168.23.1

The NAT rule above will translate source IP address 192.168.12.1 (R1) to 192.168.23.1. We’ll see if it works by sending a ping from R1 to R3. Before we do this, we’ll have to add a default route on R1 so that it knows how to reach 192.168.23.3 (R3):

R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2

We want to see the routing and NAT actions of R2 so let’s enable some debugs:

R2#debug ip packet detail 
IP packet debugging is on (detailed)

R2#debug ip nat detailed 
IP NAT detailed debugging is on

If we want to see all debug info, then we should disable route caching on R2 so that packets are handled by the CPU:

R2(config)#interface GigabitEthernet 0/1
R2(config-if)#no ip route-cache 

R2(config)#interface GigabitEthernet 0/2
R2(config-if)#no ip route-cache 

Now let’s send that ping from R1 to R3:

R1#ping 192.168.23.3 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 42/42/42 ms

The ping is successful. Let’s take a closer look at R2:

R2#
IP: tableid=0, s=192.168.12.1 (GigabitEthernet0/1), d=192.168.23.3 (GigabitEthernet0/2), routed via FIB
NAT: i: icmp (192.168.12.1, 2) -> (192.168.23.3, 2) [6]     
NAT: s=192.168.12.1->192.168.23.1, d=192.168.23.3 [6]
IP: s=192.168.23.1 (GigabitEthernet0/1), d=192.168.23.3 (GigabitEthernet0/2), g=192.168.23.3, len 100, forward
    ICMP type=8, code=0

What we see above is that the IP packet from 192.168.12.1 to 192.168.23.3 is routed first and then translated by NAT. What about the return traffic?

R2#
NAT*: o: icmp (192.168.23.3, 2) -> (192.168.23.1, 2) [6]
NAT*: s=192.168.23.3, d=192.168.23.1->192.168.12.1 [6]
IP: tableid=0, s=192.168.23.3 (GigabitEthernet0/2), d=192.168.12.1 (GigabitEthernet0/1), routed via FIB
IP: s=192.168.23.3 (GigabitEthernet0/2), d=192.168.12.1 (GigabitEthernet0/1), g=192.168.12.1, len 100, forward
    ICMP type=0, code=0

The return traffic is the opposite. First, it is translated by NAT and then we forward it. So far, so good.

Let’s try something else. We want our network to be as transparent as possible. R1 is currently using a default route to reach 192.168.23.3.

Let’s change this; we’ll add another NAT rule:

R2(config)#ip nat outside source static 192.168.23.3 192.168.12.3

The rule above will translate 192.168.23.3 to 192.168.12.3. R1 should now be able to send a ping to 192.168.12.3 instead of 192.168.23.3. Since 192.168.12.3 is on the local subnet of R1, we won’t need its default route anymore:

R1(config)#no ip route 0.0.0.0 0.0.0.0 192.168.12.2

Let’s send another ping:

R1#ping 192.168.12.3 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.12.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 48/48/48 ms

Our ping is successful but something funny is going on. Take a look at the debug of R2:

R2#
IP: tableid=0, s=192.168.12.1 (GigabitEthernet0/1), d=192.168.12.3 (GigabitEthernet0/1), routed via RIB
IP: s=192.168.12.1 (GigabitEthernet0/1), d=192.168.12.3 (GigabitEthernet0/1), len 100, rcvd 3
    ICMP type=8, code=0
IP: tableid=0, s=192.168.12.3 (local), d=192.168.12.1 (GigabitEthernet0/1), routed via FIB
IP: s=192.168.12.3 (local), d=192.168.12.1 (GigabitEthernet0/1), len 100, sending
    ICMP type=0, code=0

Above you can see that R2 is receiving the packet from 192.168.12.1 to 192.168.12.3 and replying with an IP packet from 192.168.12.3 to 192.168.12.1. There are no NAT entries at all. What is going on?

Once we configured the second NAT rule, R2 will respond to packets that are destined for 192.168.12.3. Since our traffic is going from the inside to the outside, we do routing first and NAT second.

R2 receives the packet from R1, checks its routing table and routes the packet out of the same interface. No NAT translation will occur since our traffic is not routing out of the outside interface. Here you can see the entry that R2 is “listening” for the 192.168.12.3 address:

R2#show ip cef 192.168.12.3
192.168.12.3/32, version 15, epoch 0, receive

Let’s try something else. We will send a ping from R3 to R1:

R3#ping 192.168.23.1 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.23.1, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)

This ping is failing. Why? Let’s check R2:

R2#    
NAT*: o: icmp (192.168.23.3, 4) -> (192.168.23.1, 4) [4]
NAT*: s=192.168.23.3->192.168.12.3, d=192.168.23.1 [4]
IP: tableid=0, s=192.168.12.3 (GigabitEthernet0/2), d=192.168.12.1 (GigabitEthernet0/1), routed via FIB
IP: s=192.168.12.3 (GigabitEthernet0/2), d=192.168.12.1 (GigabitEthernet0/1), g=192.168.12.1, len 100, forward
    ICMP type=8, code=0

Above we see that R2 receives the IP packet from 192.168.23.3 destined to 192.168.23.1. Since this IP packet is received on the outside interface, we do NAT first and routing second. You can see that source address 192.168.23.3 is translated to 192.168.12.3.

R2 will then do a routing table lookup for the destination (192.168.12.1) and forwards it towards R1. When R1 receives this packet, it will reply and here’s what R2 will do with it:

R2#
IP: tableid=0, s=192.168.12.1 (GigabitEthernet0/1), d=192.168.12.3 (GigabitEthernet0/1), routed via RIB
IP: s=192.168.12.1 (GigabitEthernet0/1), d=192.168.12.3 (GigabitEthernet0/1), len 100, rcvd 3
    ICMP type=0, code=0

R2 receives the packet from 192.168.12.1 with destination 192.168.12.3. It does a lookup in the routing table, finds a matching entry for its GigabitEthernet0/1 interface and sends it out of the interface. This packet is never translated and will never make it to R3.

So how do we solve this problem with “legacy” NAT?

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 660 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

510 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , ,


Forum Replies

  1. Hello Rene,
    Great video. I have a suggestion please. Can you start doing like a CCIE video series, many people understand better with videos and the way you explain topics is very great and straight forward, i hope you can implement this idea which will be so great. thanks

    Ammar,

  2. Hi Rakesh,

    PAT means port address translation, this doesn’t mean that the source port is always changed though. Take a look at this example:

    How to configure PAT on Cisco IOS Router

    Look for the show ip nat translations command in that lesson. You can see the source ports remain the same, the router will only change these if two hosts happen to pick the same source port number.

    CGNAT stands for Carrier Grade NAT. Some ISPs don’t give their customers public IP addresses anymore but private IP addresses. The ISP will use NAT/PAT to put many customers behind a single public IP address.

    Rene

  3. Hi, and thank you for the reply. I was talking about dynamic NAT, or Static NAT, where you would have a pool of Public IP addresses and a pool of private addresses. In order to use one of the public IP addresses as your new source address, it has to be configured on the router, right? Or can you just have your ISP route you the subnet and they will see the source ip as it get’s NAT’d and know what to do with it.

    I hope this makes more sense, I am not talking about PAT (layer 4) at all.

    Thanks

  4. Please explain what is a bidirectional NAT

  5. Hi Pavan,

    In most NAT/PAT examples, we only translate the source IP address.

    With bi-directional NAT, you can translate both the source and destination IP address at the same time.

    Rene

12 more replies! Ask a question or join the discussion by visiting our Community Forum