NAT caveats in IOS release 12.4T
From CT3
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:
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
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:
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
BlogMarks
del.icio.us
digg
Facebook
LinkedIn
Newsvine
reddit
Slashdot