Content

| 6.4 |  | Troubleshooting Complex Network Systems |
| 6.4.4 |  | Dynamic NAT and extended ACLs |

The interaction of Dynamic NAT and extended access lists can generate complex network problems, particularly regarding the use of addressing and ports.

Addressing considerations
Recall that the order of processing inbound traffic on a router is that the inbound traffic is processed by the inbound access list before being processed by outside-to-inside NAT. When designing access lists for implementation on NAT routers, remember that the destination address of inbound traffic will be the IP address used by the outbound NAT translation.

Dynamic NAT timeouts
When configuring dynamic NAT, different timeout values can be configured for different types of traffic. Figure shows the commands used to change these values for translations built with and without overloading.

As discussed in previous content, highly tuned translation timeouts combined with network congestion can be the cause of intermittent problems in network communications. Different transport layer protocols also have different timeout values by default and can be configured individually. This can mislead network engineers when troubleshooting, as discussed below.

Misconfiguration example
Figure shows a router with multiple configuration errors. The symptom presented is that neither Host A, nor Host B can establish a reliable connection to download files from Server D using TFTP.

Following the traffic flow, the network engineer checks the local network segment and finds nothing wrong. The access lists filtering outbound traffic are examined and no faults are found. The NAT process on the router is also building the appropriate translation for the outbound traffic and the access list filtering inbound traffic has an entry to permit traffic from UDP port 69 on the TFTP server to any UDP port on the private IP addresses allocated to Hosts A and B. The engineer can ping Server D from both Hosts A and B and from Router C.

At this stage, the network engineer configures the deny ip any any log command to find out if the traffic is returning from the TFTP server, but is being blocked by the access list. The logged messages indicate that TFTP traffic from Server D is getting back to the router, but is addressed to the IP address of the router serial interface being used as the NAT overload outside address. The network engineer corrects the problems with the ACL and tries another TFTP download.

Host A can now establish a connection with Server D, but loses connection when doing a large file transfer. There is not any pattern as to the point during the transfer at which the connection is lost. The network engineer suspects that this may be a problem with UDP packets being lost in transit, but uses a protocol analyzer on the WAN link to make sure (installing the WAN protocol analyzer interrupts network communications, so the engineer waits until everyone has gone out to lunch).

Results from the protocol analyzer show that the router is receiving more TFTP packets than it should. This means that there is a problem with the router. Examining the router system log in greater detail, the network engineer finds some error messages stating that router has ‘…received packets for which no translation exists…’. The network engineer examines the configuration of the router and notices the following block in the configuration script:

> ip nat translation udp-timeout 18
> ip nat translation dns-timeout 120
> ip nat translation tcp-timeout 3600

Assuming the first statement is an error, the network engineer replaces it with ip nat translation udp-timeout 180 and tests the file transfer again. The large file is transferred successfully and the problem is considered resolved. After updating the appropriate documentation, the network engineer removes the unnecessary additions to the network configuration, such as the WAN protocol analyzer and the deny ip any any log statement in the inbound ACL.