Defining the Need for NAT Exemption

It recently occurred to me that we have often discussed various configurations of NAT exemption. However, we have never really discussed the typical need or use case for requiring this type of configuration. This article is meant as a general discussion about what NAT exemption is and when it is required. Although the example uses an IOS based router for the demonstration, the concepts around NAT exemptions are universal. We will look at the configuration requirements for exempting NAT on the ASA and basic PAT (NAT Overload) exemption in IOS. In a follow-up article, we will address issues that are specific to exempting static NAT and PAT in IOS based routers. Fortunately, those unique challenges do not exist in ASAs due to the order of the logic and configuration constructs.

Let’s first take a look at example

 

In this example, we find a single IOS Based router named “FW”. This router is performing both Network Address Translation (PAT or NAT Overload in this example) and VPN termination. The protected networks on either end of the tunnel are part of the RFC1918 private address space. Therefore NAT must not occur for proper communication to happen between the IPSec Protected networks. However, NAT must occur for “InsideHost” to access other destinations on the Internet. This is a typical scenario that requires NAT Exemption. Let’s start out with a base configuration. Then we will layer on the NAT and VPN configuration independently to better understand the behavior if we fail to properly implement NAT Exemption.

Base Configurations

InsideHost Base Configuration

hostname InsideHost
!
no ip routing
!
interface FastEthernet0/0
 ip address 192.168.1.2 255.255.255.0
!
ip default-gateway 192.168.1.1
!
line vty 0 15
 exec-timeout 0 0
 privilege level 15
 password cisco
 logging synchronous
 login

FW Base Configuration

hostname FW
!
interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
!
interface Serial0/0
 ip address 9.9.9.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 9.9.9.1

Outside Base Configuration

hostname Outside
!
interface Serial0/0
 ip address 9.9.9.1 255.255.255.0
!
interface Loopback1
 ip address 192.168.100.1 255.255.255.0
!
interface Loopback2
 ip address 5.5.5.5 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 9.9.9.2

Now let’s go ahead and configure the basic NAT Overload (aka PAT).

FW NAT Configuration

interface FastEthernet0/0
 ip nat inside
!
interface Serial0/0
 ip nat outside
!
access-list 1 permit 192.168.1.0 0.0.0.255
!
ip nat inside source list 1 interface serial 0/0 overload

Now, we can test and verify our NAT configuration

FW Debug Configuration

FW#debug ip nat
IP NAT debugging is on

InsideHost Ping Test

InsideHost#ping 5.5.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/219/1008 ms

Debug Output on FW

FW#
*Mar  1 00:12:04.367: NAT*: s=192.168.1.2->9.9.9.2, d=5.5.5.5 [0]
*Mar  1 00:12:04.403: NAT*: s=5.5.5.5, d=9.9.9.2->192.168.1.2 [0]
*Mar  1 00:12:04.423: NAT*: s=192.168.1.2->9.9.9.2, d=5.5.5.5 [1]
*Mar  1 00:12:04.431: NAT*: s=5.5.5.5, d=9.9.9.2->192.168.1.2 [1]
*Mar  1 00:12:04.439: NAT*: s=192.168.1.2->9.9.9.2, d=5.5.5.5 [2]
*Mar  1 00:12:04.443: NAT*: s=5.5.5.5, d=9.9.9.2->192.168.1.2 [2]
*Mar  1 00:12:04.463: NAT*: s=192.168.1.2->9.9.9.2, d=5.5.5.5 [3]
*Mar  1 00:12:04.467: NAT*: s=5.5.5.5, d=9.9.9.2->192.168.1.2 [3]
*Mar  1 00:12:04.483: NAT*: s=192.168.1.2->9.9.9.2, d=5.5.5.5 [4]
*Mar  1 00:12:04.491: NAT*: s=5.5.5.5, d=9.9.9.2->192.168.1.2 [4]

Now, let’s forget about NAT exemption for a moment and build the crypto parts of the VPN Configuration between “FW” and “Outside”.

FW VPN Configuration

access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255
!
crypto isakmp policy 10
 encr 3des
 authentication pre-share
!
crypto isakmp key cisco address 9.9.9.1
!
crypto ipsec transform-set MYSET esp-3des esp-sha-hmac
!
crypto map MYMAP 10 ipsec-isakmp
 set peer 9.9.9.1
 set transform-set MYSET
 match address 101
!
interface serial 0/0
 crypto map MYMAP

Outside VPN Configuration

access-list 101 permit ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255
!
crypto isakmp policy 10
 encr 3des
 authentication pre-share
!
crypto isakmp key cisco address 9.9.9.2
!
crypto ipsec transform-set MYSET esp-3des esp-sha-hmac
!
crypto map MYMAP 10 ipsec-isakmp
 set peer 9.9.9.2
 set transform-set MYSET
 match address 101
!
interface serial 0/0
 crypto map MYMAP

Now let’s test this from “Loopback 1” on “Outside”.

Outside#ping 192.168.1.2 source loopback 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/10/24 ms
Outside#

Well it seemed to work. Let’s see if we can telnet from “loopback 1”.

Outside#telnet 192.168.1.2 /source-interface loopback 1
Trying 192.168.1.2 ...
% Connection timed out; remote host not responding

That didn’t work so we obviously have a problem. Let’s try the ping again from “Outside”. This time we’ll look at the source of the echo replies returned to “Outside”.

Outside#debug ip icmp
ICMP packet debugging is on

Outside#ping 192.168.1.2 source loopback 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Outside#
*Mar  1 00:26:35.767: ICMP: echo reply rcvd, src 9.9.9.2, dst 192.168.100.1
*Mar  1 00:26:35.771: ICMP: echo reply rcvd, src 9.9.9.2, dst 192.168.100.1
*Mar  1 00:26:35.771: ICMP: echo reply rcvd, src 9.9.9.2, dst 192.168.100.1
*Mar  1 00:26:35.775: ICMP: echo reply rcvd, src 9.9.9.2, dst 192.168.100.1
*Mar  1 00:26:35.775: ICMP: echo reply rcvd, src 9.9.9.2, dst 192.168.100.1

Notice that we sent ICMP Echo Requests are sent to 192.168.1.2, but we are getting echo replies from 9.9.9.2. If we had the real internet between these two hosts, this would have completely failed. Due to the fact that “FW” and “Outside” point toward each other as the default gateway, it allowed the echo replies to make it to “Outside”. However, the NAT translated the source. Let’s do a NAT debug on FW again and try both the ping and telnet tests once again.

FW#debug ip nat
IP NAT debugging is on

Ping Test

Outside#ping 192.168.1.2 source loopback 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Telnet Test

Outside#telnet 192.168.1.2 /source-interface loopback 1
Trying 192.168.1.2 ...
% Connection timed out; remote host not responding

Now Let’s look at the output from “debug ip nat” on FW.

//output from ICMP traffic
FW(config)#
*Mar  1 00:31:32.655: NAT: s=192.168.1.2->9.9.9.2, d=192.168.100.1 [10]
*Mar  1 00:31:32.663: NAT: s=192.168.1.2->9.9.9.2, d=192.168.100.1 [11]
*Mar  1 00:31:32.663: NAT: s=192.168.1.2->9.9.9.2, d=192.168.100.1 [12]
*Mar  1 00:31:32.667: NAT: s=192.168.1.2->9.9.9.2, d=192.168.100.1 [13]
*Mar  1 00:31:32.667: NAT: s=192.168.1.2->9.9.9.2, d=192.168.100.1 [14]

//output from telnet attempt
FW(config)#
*Mar  1 00:31:45.631: NAT: TCP s=23->2, d=22928
*Mar  1 00:31:45.631: NAT: s=192.168.1.2->9.9.9.2, d=192.168.100.1 [17101]
*Mar  1 00:31:45.631: NAT*: TCP s=22928, d=2->23
*Mar  1 00:31:45.631: NAT*: s=192.168.100.1, d=9.9.9.2->192.168.1.2 [58178]

//note--this repeats several times (for the TCP retry attempts)

As you see traffic from the inside is being translated as it goes to the outside. This is true even for the VPN traffic that should not be translated. While ICMP is still showing a “success”, telnet isn’t working. This makes sense if we think about the fact that TCP is a must more sophisticated protocol and even performs a 3-way handshake prior to allowing the upper layer communication to happen. This mangling of the source address is preventing the three way handshake from successfully completing. Since this is an IOS device and only has a very simple PAT configuration, exempting the VPN traffic from the NAT process is quite straightforward.

FW Configuration

//remove the current nat statement
no ip nat inside source list 1 interface Serial0/0 overload

//build an acl that denies the vpn traffic and permits all else
//this will be used to trigger the nat process
ip access-list extended NAT
 deny   ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255
 permit ip 192.168.1.0 0.0.0.255 any

//Associate the ACL with the nat process
ip nat inside source list NAT interface serial 0/0 overload

Now let’s try our Telnet test again.

Outside#telnet 192.168.1.2 /source-interface loop1
Trying 192.168.1.2 ... Open

User Access Verification

Password:
InsideHost#exit

[Connection to 192.168.1.2 closed by foreign host]

So that is the solution to this particular problem when using an IOS based device. There are more challenges if the IOS device also has static NAT entries. We’ll cover two methods for exempting static NAT entries in a future article. If you are fortunate enough to be using an ASA for VPN termination and address translation, I find the solution simpler. The other nice thing about NAT exemption on the ASA is that it effectively exempts the static translations as well.

ASA NAT Exemption–

8.2 and earlier

nat (inside) 0 access-list nat_exemption
access-list nat_exemption extended permit ip 192.168.1.0 255.255.255.0 192.168.100.0 255.255.255.0

8.3 and newer

object network obj-192.168.1.0
  subnet 192.168.1.0 255.255.255.0
object network obj-192.168.100.0
  subnet 192.168.100.0 255.255.255.0

nat (inside,any) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-192.168.100.0 obj-192.168.100.0 no-proxy-arp

NAT Exemption is a configuration option that we need to understand when and why we need it. The most common configuration that requires NAT Exemption is when we have NAT on a firewall or router that is also terminating a VPN tunnel. This article demonstrated the specific challenges and solutions when simple NAT overload is combined with VPN configuration on the same device.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Design. Bookmark the permalink.

4 Responses to Defining the Need for NAT Exemption

  1. Pingback: Exempting Static Translations in IOS NAT | PacketU

  2. Jason CCIE #29363 says:

    great article. keep up the good work

  3. Alex says:

    This is awesome I will try giving these recommendations a shot!

  4. Bilal says:

    Excellent. It just helped me resolve an issue. Thanks much.

Comments are closed.