Old School Method of IOS Static NAT Exemption

Last week, I wrote an article that demonstrated the challenges of static NAT when combined with VPNs using RFC1918 address space. We created exemptions using route-maps within the static nat statements. Cisco didn’t introduce route-maps for static translations until 12.2(4)T. However, we’ve had VPNs and NAT for much longer than that. So what did we do before then?

The answer to this requires a more thorough understanding of IOS. Particularly, packets are not checked against the NAT table and configuration unless those packets pass between interfaces with NAT enabled. Additionally when using a traditional NAT configuration, one must be tagged as “ip nat inside” and the other as “ip nat outside”.

For this article, we need to decide how we can allow “Outside” to telnet to 9.9.9.2 from 5.5.5.5 and to 192.168.1.2 from 192.168.100.1. Let’s pretend we are on pre-12.2(4)T and therefore cannot use route-maps with our static nat statements. Let’s look at a diagram of our network once again.

Base Configurations

Inside Host Base Configuration

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

FW Configuration

hostname FW
!
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 FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!
interface Serial0/0
 ip address 9.9.9.2 255.255.255.0
 ip nat outside
 crypto map MYMAP
!
ip route 0.0.0.0 0.0.0.0 9.9.9.1
!
ip nat inside source list NAT interface Serial0/0 overload
!
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
!
access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255
!

Outside Configuration

hostname Outside
!
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 Loopback1
 ip address 192.168.100.1 255.255.255.0
!
interface Loopback2
 ip address 5.5.5.5 255.255.255.0
!
interface Serial0/0
 ip address 9.9.9.1 255.255.255.0
 crypto map MYMAP
!
ip route 192.168.1.0 255.255.255.0 9.9.9.2
!
access-list 101 permit ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255

Let’s go ahead and add our static pat statement without a route-map.

FW(config)#
FW(config)#ip nat inside source static tcp 192.168.1.2 23 9.9.9.2 23
FW(config)#

Now let’s see what works and what doesn’t.

Test to/from Public address (success)

Outside#telnet 9.9.9.2 /source-interface loopback 2
Trying 9.9.9.2 ... Open

User Access Verification

Password:
InsideHost#exit

[Connection to 9.9.9.2 closed by foreign host]
Outside#

Test to/from RFC1918 addresses through VPN (fail)

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

Outside#

So the translated address (9.9.9.2:23) works, but the traffic through the VPN fails. This is, as illustrated last week, due to the return packets flowing through the nat process and being translated. So how do we fix this WITHOUT using a route-map on our “ip nat inside source static” statement?

The answer lies into a statement I made earlier. Packets will not be checked against the NAT table or configuration if it is not passed between two opposing NAT enabled interfaces. For example, “ip nat inside” and “ip nat outside”. Now that seems to be a challenge since we want the return traffic to go from the inside interface to the outside interface. There is a often overlooked trick that is the key to making this work.

We can policy route traffic that is coming into the inside interface over to a loopback. The loopback having no real next hop, will route the packet using the routing table. The packets are flowing from an interface that is configured as “ip nat inside” to an interface without NAT (the loopback), then from the loopback to an interface configured as “ip nat outside”. This keeps them from being subjected to the static NAT configuration.

//create a loopback interface with an unused address space
FW(config)#interface loopback 10
FW(config-if)#ip address 192.168.200.1 255.255.255.0

//create an acl that permits any traffic that should be exempted
FW(config-if)#ip access-list ext NATEXEMPT
FW(config-ext-nacl)#permit ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255
FW(config-ext-nacl)#exit

//create a route-map that sets a next hop of an address on the loopback for
//outbound traffic destined to the remote VPN
FW(config)#route-map NATEXEMPT permit 10
FW(config-route-map)#match ip address NATEXEMPT
FW(config-route-map)#set ip next-hop 192.168.200.2

//note that 192.168.200.2 would be on the loopback 10 interface

//now we need to attach the route-map to the INSIDE interface
FW(config)#int fa0/0
FW(config-if)#ip policy route-map NATEXEMPT
FW(config-if)#exit

Next, let’s test to see if our requirements are met.

Telnet using the public address

Outside#telnet 9.9.9.2 /source-interface loopback 2
Trying 9.9.9.2 ... Open

User Access Verification

Password:
InsideHost#exit

[Connection to 192.168.1.2 closed by foreign host]
Outside#

Telnet through the VPN

Outside#telnet 192.168.1.2 /source-interface loopback 1
Trying 192.168.1.2 ... Open

User Access Verification

Password:
InsideHost#exit

[Connection to 192.168.1.2 closed by foreign host]
Outside#

Well this all works and would have worked with pre-12.2.4(T) code. Now I hope not to many of my readers are still using such an obsolete code version. What I like about this example is that it really helps you understand some of the inner workings of IOS as it pertains to routing and NAT. When possible, I recommend using the more current configuration using route-maps attached directly to the nat statements.

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 How-To. Bookmark the permalink.

One Response to Old School Method of IOS Static NAT Exemption

Comments are closed.