Home > IP Services > Basic NAT

Basic NAT

In this post I would like to demonstrate how NAT works on Cisco IOS router and more particularly what is the order of operation process when using Domain-based NAT vs. Nat Virtual Interface (NVI). As usual, to highlight the different configuration examples throughout this post I will use the following topology:

NatTopology

Scenario:

Let´s imagine that R1 is simulating a virtual PBX (also known as Hosted PBX.) located in the Voice provider network. This VPBX needs access to R5 (which is simulating a Lotus Notes server) in order to synchronize the different information for calendar, contacts, etc. Here are the following requirements from the customer:

  • The customer doesn´t want to run any dynamic routing protocols between its network and the Voice provider network
  • The customer wants the implementation of the solution to be as transparent as possible.
  • The voice provider must only have access to the lotus notes (represented by R5 in this scenario).
  • The voice provider must not be aware of any internal networks located at the customer site.
  • The Voice provider has installed a tiny software client on each PC located at the customer site on the 192.168.100.0/24 network in order to send information to the VPBX. This software should be able to reach the VPBX (simulated by R1 in this scenario) without having any routing information regarding the Voice provider network.

Solution:

 In order to meet the customer requirements let´s implement and configure NAT as follows:

1. When R1 (the VPBX) pings the virtual IP 10.10.10.254 located on R3 from its loopback (10.20.20.1) the following translation should occur:

    • Upon receiving traffic from R1 with source IP 10.20.20.1 and destination IP 10.10.10.254, R3 should translate the source IP to the virtual IP 192.168.100.254 and the destination IP to 192.168.200.5 (the Lotus Notes server).

 2.  When users located on the 192.168.100.0 /24 segment (simulated by R4)  ping the virtual IP 192.168.100.254 located on R3, the following should occur:

    • Upon receiving traffic from any users on the 192.168.100.0/24 segment with destination IP 192.168.100.254., R3 should translate the source IP to the virtual IP 10.10.10.253 and the destination IP to 10.20.20.1 (the VPBX)

NAT domain based Configuration

Let´s start by implementing the second part of the customer requirements. So let´s configure R3 as follows:

s1

In the output above we have defined the NAT inside and outside domain in order for NAT to be triggered when packets will flow from inside to outside NAT domain. We have defined a pool of address which represents the virtual IP source address the hosts located on the 192.168.100.0/24 will be translated to when sending traffic to 10.20.20.1 (VPBX-R5).

With the above configuration R3 will only translate the source IP address to 10.10.10.253 for packets having a source IP located on the 192.168.100.0/24 network. The “ip nat inside source route-map <route-map name> pool <nat pool name>” command just means that we want to translate the source IP address for networks located on the inside NAT domain defined in the route-map to the IP address defined in the NAT pool.

Let´s quickly test if the source address is correctly translated when pinging from R4 to 10.10.10.2 for example:

Side note: For this test, I have just made a default route on R4 pointing to R3. I will remove it after this test.

s2

s3

So what is happening here is quite interesting. On the NAT inside domain we can observe that packets are first routed. The router consults the routing table to find an outgoing interface for the traffic. In this case the router founds that F0/1 is the outgoing interface. Then, the packet is submitted for NAT translation. In this case as we only do source NAT, the source IP addressed is translated. We can also observe that the router is making an alias for the translated address (picked up from the NAT pool defined). The alias address is necessary so that R3 can reply to ARP request for this address when traffic is coming back. In this case, we are pinging R2 so R2 will ARP for 10.10.10.253 and R3 will reply with its own MAC address.

Now on the outside NAT domain the NAT order process is different and we can see from the output above that NAT translation occurs before routing. Only, once the translation is done the router routes the packet.

Perfect! The source address is translated without issue. But we could be more specific in the NAT access-list by defining also the destination address so the configuration will actually look like this:

s4

Basically we are only triggering the NAT process to this destination IP address which indeed meet the requirements. Now let´s remove the static route defined on R4 (see previous test example) and let´s ping from R4 to 192.168.100.254 which is the considered virtual IP address on R3:

s5

So R4 is sending an ARP request for 192.168.100.254 and it gets no answer! Nobody knows on this segment who is 192.168.100.254. So what we could do to solve this issue is to use proxy-arp on R3. Proxy-arp is enabled by default so we just need to make sure that R3 knows about this host IP address. To do that, we create a static route on R3 for 192.168.100.254 pointing to R2. In this way R3 will proxy-arp for 192.168.100.254 by replying with its own mac address for ARP request to 192.168.100.254.

s6

Side note: Actually by doing this we also solve another issue which is the NAT order of process. We saw before that on the inside NAT domain, the routing process is triggered before NAT which means that in order to trigger the NAT process the routing process must be successful which means that in our case the routing process must route from inside to outside interface in order for NAT to be triggered. By pointing the host IP 192.168.100.254 towards the outside NAT domain, the NAT process will be successfully triggered.

Perfect! Let´s ping again from R4 towards 192.168.100.254:

s7

So R3 is replying with its own mac-address for 192.168.100.254.

Let´s see know how the routing process and the NAT process are triggered once R4 has made an ARP entry for 192.168.100.254 and send the ICMP packet to R3 with destination 192.168.100.254:

s8

Obviously, R2 doesn´t know about 192.168.100.254 so when it receives the ICMP packet it will send an ICMP unreachable towards R3 which will be NAT back towards R4:

s9

Side note: when R4 is sending an ICMP packet with source IP of 192.168.100.4 and destination IP of 192.168.100.254, R3 will create the following entry in its NAT table to allow for return traffic:

s10

AS we are only translating the source IP here (for now), there is no difference between the Outside local and outside global IP. However as we are translating the source IP, the Inside local represents the source IP before NAT translation and the Inside global represents the source IP after translation. This NAT entry is bidirectional so when 192.168.100.254 sends traffic back to destination IP 10.10.10.253, 10.10.10.253 gets translated back to the original Inside IP 192.168.100.4, effectively allowing traffic to flow in both direction. However this NAT entry is called “extendable”, that means that reverse connection to inside hosts using temporary global IP address mappings are not possible with default route-map configuration which adds security. “Extendable” NAT entries associate local/global IP addresses and port numbers which allows for NAT multi-homing since a particular inside local source IP is not bound to just one inside global IP address.

Good! Now we need to fix the issue with the destination IP as the customer requirements say that the Voice provider and the customer should not know about each other networks. The requirements say that the destination IP should appear to the voice provider as the VPBX IP (R1 – 10.20.20.1). So let´s configure the following on R3:

s11

The above configuration should be seen from an outside NAT domain point of view that is to say, we are translating the source IP address for packets flowing from the outside NAT domain to the inside NAT domain. From an inside NAT domain perspective we are talking about the outside local and the outside global IP address:

s12

So that means that we are translating the outside local IP (destination IP address before translation) to the outside global IP address (destination IP address after translation). This NAT entry is a static entry allowing bidirectional traffic initiation that is why the entry is already present in the NAT table. As opposed to the dynamic NAT we have created before to allow the source IP address to be translated, the static NAT entry we always be present in the NAT table. However with dynamic NAT when traffic coming from the inside NAT domain match the route-map, the NAT process will create a NAT entry in the NAT table making this process dynamic. Also note that dynamic NAT does not allow bidirectional traffic initiation when no entry is already present in the NAT table.

In order to translate the destination IP we need to use a static NAT in order for the NAT entry to be already present in the NAT table. If we were to use dynamic NAT to translate the destination IP, it wouldn´t have worked unless an entry was already present in the NAT table (for example if R1 had initiated some traffic flow towards the inside NAT domain.

Let´s now test and see what happen with the NAT and the routing process on R3:

s13

In the output above we can see that when R4 is pinging, routing is occurring first in order to find an outgoing interface and then NAT process is occurring after. This time the destination address is also translated thanks to the static NAT statement previously configured. Once the source and the destination have been translated routing occurs again in order to find an outgoing interface for the newly translated destination IP address.

In the opposite direction when R1 replies back we can see in the output above that the NAT process occurs first and then the routing process occurs after. Let ´s have a look at the NAT table after the translations have occurred:

s14

We have 2 entries, one static entry and one dynamic entry. The dynamic entry allows the source IP address to be translated when traffic flows from inside to outside and the destination IP address when traffic flows from outside to inside. The static entry allows the destination IP address to be translated when traffic flows from inside to outside and the source IP address when traffic flows from outside to inside.

Perfect! We have met the requirements for the second part. Now let´s configure the networks to meet the requirements for the first part:

1. When R1 (the VPBX) pings the virtual IP 10.10.10.254 located on R3 from its loopback (10.20.20.1) the following translation should occur:

    • Upon receiving traffic from R1 with source IP 10.20.20.1 and destination IP 10.10.10.254, R3 should translate the source IP to the virtual IP 192.168.100.254 and the destination IP to 192.168.200.5 (the Lotus Notes server).

To meet this requirement we simply configure the following on R3:

s15

So we do a one-to-one translation saying that from an outside NAT domain perspective the destination address will be translated from 10.10.10.254 to 192.168.200.5. Let´s test:

s16

From the outputs above we can see that all the customer requirements are met.

Perfect! Let´s try now to meet the same requirements by using NAT Virtual Interface (NVI).

NAT Virtual Interface (NVI) configuration

As we saw until now, when using NAT based domain, depending on the direction of the traffic, NAT occurs before or after the routing process which means that you need to take care of routing when using this type of NAT. With NVI, all NAT traffic pass through a new virtual interface called NVI, in a symmetric manner eliminating the need to specify inside and outside domains. So let´s reconfigure R3 with NVI to meet the requirements of the second part:

2.  When users located on the 192.168.100.0 /24 segment (simulated by R4)  ping the virtual IP 192.168.100.254 located on R3, the following should occur:

  • Upon receiving traffic from any users on the 192.168.100.0/24 segment with destination IP 192.168.100.254., R3 should translate the source IP to the virtual IP 10.10.10.253 and the destination IP to 10.20.20.1 (the VPBX)

s17

So the difference from the previous configuration with NAT based domain is that we have replaced “ip nat inside” and “ip nat outside” with “ip nat enable” on both interfaces. Moreover the static route to 192.168.100.254/32 has been removed. This static route was necessary with NAT domain based in order for NAT to be triggered as with NAT domain based, routing occurs before NAT on the inside domain. There is no more keywords like “inside” or “outside” when configuring NVI, instead we use “ip nat source

Let´s test now:

s18

So from the outputs above we can see that with NVI routing occurs twice, first to route the packet to the NVI and then to route the translated packet to the destination. This allows to get rid of the static route we used in our previously example with NAT based domain. With NVI the NAT table is used to take a routing decision to send the matching traffic to the Nat Virtual Interface (NVI) first.

Let´s have a look at the NAT table now:

s19

So with NVI there is no more concepts of inside local, inside global, etc.

Finally, let´s meet the requirement of the first part:

1. When R1 (the VPBX) pings the virtual IP 10.10.10.254 located on R3 from its loopback (10.20.20.1) the following translation should occur:

    • Upon receiving traffic from R1 with source IP 10.20.20.1 and destination IP 10.10.10.254, R3 should translate the source IP to the virtual IP 192.168.100.254 and the destination IP to 192.168.200.5 (the Lotus Notes server).

To do that we just need to add the following configuration on R3 as we did before:

s20

Perfect so we met all the requirements using both “legacy” NAT and NVI.

Thanks for reading!

/Laurent

Advertisements
  1. Pablo Lucena
    January 19, 2013 at 18:59

    Hello Laurent,

    I’ve enjoyed reading your articles. I like the way you go into detail on the technologies you cover. Would it be possible for you to do one regarding WCCPv2? This would be hard to test due to the lack of cache server, but I think it would be interesting. Maybe explain some of the filtering techniques or interactions with NAT, etc.

    Once again, thank you for your work.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: