NAT caveats in IOS release 12.4T

From CT3

Jump to: navigation, search

By Ivan Pepelnjak

The Network Address Translation (NAT) in IOS release 12.4T works significantly differently from the previous implementations (including mainstream IOS release 12.4). This document documents some of the unexpected behaviors encountered when using NAT with older configurations in IOS release 12.4T.

The NAT router running IOS release 12.4(15)T5 is connected to an inside and an outside LAN as shown in the following diagram:

Image:NAT_TestBed_Diagram.png

Contents

Locally generated packets are translated into NAT pool

The test router uses the following configuration (which works correctly with IOS release 12.4(19)):

interface FastEthernet0/0
 description Outside
 ip address 192.168.0.1 255.255.255.0
 ip nat outside
!
interface FastEthernet0/1
 description Inside
 ip address 10.0.0.1 255.255.255.0
 ip nat inside
!
ip nat pool Outside 192.168.0.10 192.168.0.20 netmask 255.255.255.0
ip nat inside source list Inside pool Outside
!
ip access-list standard Inside
 permit any

NAT translation is applied to router-generated packets exiting the NAT outside interface. Test case: pinging a host directly connected to the NAT outside interface generates NAT translation entries even though the source IP address in the ICMP packet is the IP address of the outside interface (Fast Ethernet 0/0):

NAT#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/16 ms
NAT#show ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
icmp 192.168.0.10:1    192.168.0.1:1      192.168.0.2:1      192.168.0.2:1
--- 192.168.0.10       192.168.0.1        ---                ---

The NAT router does not use the overload pool, thus the ping generates two NAT translation entries: a generic one for the IP address and a session-specific one for ICMP packets. Likewise, a telnet session opened from NAT to the Server router (192.168.0.1 to 192.168.0.2) generates a NAT translation:

NAT#telnet 192.168.0.2
Trying 192.168.0.2 ... Open

Server#exit

[Connection to 192.168.0.2 closed by foreign host]
NAT#show ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
tcp 192.168.0.10:51449 192.168.0.1:51449  192.168.0.2:23     192.168.0.2:23
--- 192.168.0.10       192.168.0.1        ---                ---

To fix these issues, you have to change the IP access-list used with the ip nat inside source list command; the IP access-list should match only private IP addresses that need to be translated, not the router’s public IP addresses.

ip nat pool Outside 192.168.0.10 192.168.0.20 netmask 255.255.255.0
ip nat inside source list Inside pool Outside
!
ip access-list standard Inside
 permit 10.0.0.0 0.255.255.255
NAT implementation in IOS release 12.4 translates packets traversing from inside to outside interface. The IP access list Inside can thus match any IP address.

Outbound connections from the router do not work with NAT overload

If you use the NAT overload functionality on NAT outside interface in combination with a very permissive IP access-list, you can no longer open outbound sessions from the router itself. For example, a NAT router running IOS release 12.4(15)T5 configured with the following configuration can no longer establish telnet sessions to outside hosts.

interface FastEthernet0/0
 description Outside
 ip address 192.168.0.1 255.255.255.0
 ip nat outside
!         
interface FastEthernet0/1
 description Inside
 ip address 10.0.0.1 255.255.255.0
 ip nat inside
!         
ip nat inside source list Inside interface FastEthernet0/0 overload
!         
ip access-list standard Inside
 permit any

When trying to establish telnet session to the IP host 192.168.0.2, the session times out and the NAT translation table contains two entries entries:

NAT#telnet 192.168.0.2
Trying 192.168.0.2 ... 
% Connection timed out; remote host not responding

NAT#show ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global
tcp 192.168.0.1:1025   192.168.0.1:1024   192.168.0.2:23     192.168.0.2:23
tcp 192.168.0.1:1024   192.168.0.1:55971  192.168.0.2:23     192.168.0.2:23

As before, you can fix this issue by using a more restrictive IP access list in combination with the ip nat inside source configuration command:

ip nat inside source list Inside interface FastEthernet0/0 overload
!
ip access-list standard Inside
 permit 10.0.0.0 0.255.255.255

Packets rejected by inbound ACL generate NAT translations

Network address translation is obviously executed before the access-list checks in the inbound path of the packet forwarding code. When the NAT is configured with an access-list permitting outside-to-outside packets, the packets that are rejected by inbound ACL configured on the NAT outside interface create NAT translation entries before they are dropped. Furthermore, the return ICMP packets contain wrong TCP port numbers, resulting in the inability of the outside device to detect rejected TCP session.

The following configuration was used on the NAT router to perform this test:

hostname NAT
!
ip inspect name FW tcp router-traffic
ip inspect name FW udp router-traffic
ip inspect name FW icmp router-traffic
!
interface FastEthernet0/0
 description Outside
 ip address 192.168.0.1 255.255.255.0
 ip access-group FW in
 ip nat outside
 ip inspect FW out
!
interface FastEthernet0/1
 description Inside
 ip address 10.0.0.1 255.255.255.0
 ip nat inside
!
ip nat inside source list Inside interface FastEthernet0/0 overload
!
ip access-list standard Inside
 permit any
!
ip access-list extended FW
 deny   tcp any any log
 deny   ip any any log

When an outside host tries to connect to the router's own IP address, the TCP SYN packet is rejected, but the router still creates a NAT translation entry, as indicated by the following printout taken on the NAT router:

%SEC-6-IPACCESSLOGP: list FW denied tcp 192.168.0.2(63319) -> 192.168.0.1(23), 1 packet 
NAT#show ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global
tcp 192.168.0.1:3      192.168.0.1:23     192.168.0.2:63319  192.168.0.2:63319

The translated TCP port numbers are used in return ICMP packets, causing the initiating host to timeout the TCP session:

Server#telnet 192.168.0.1
Trying 192.168.0.1 ... 
% Connection timed out; remote host not responding

Packet analysis of the captured packets clearly shows the invalid TCP port number used in the ICMP destination unreachable reply:

Original TCP packet (from port 63319 to port 23)
Invalid ICMP reply (from port 63319 to port 3)

If the Inside access list is changed to match the inside IP addresses ...

ip access-list standard Inside
 permit 10.0.0.0 0.0.0.255

… the telnet session is properly rejected and the inbound packets dropped by the ACL no longer create bogus NAT translations:

Server#telnet 192.168.0.1
Trying 192.168.0.1 ... 
% Destination unreachable; gateway or host down

Related information

Additional Resources  

Implementing Secure Converged Wide Area Networks (ISCW):

Other learning solutions

Other links

Personal tools

CT3

Main menu