The symptoms of most of these problems are similar, meaning that the devices, whose IP addresses are NATed, are unable to access the public network as they are supposed to. Most of these issues can be diagnosed by understanding what goal NAT is being implemented to achieve and then looking at the configuration to see if one of the following mistakes is the source of the problem:
- Access lists blocking NATed or non-NATed traffic- It is important to keep in mind NAT's operation in relation to the access control lists. Opening an access list for non-NATed traffic, when in reality the traffic hitting it is NATed traffic, causes traffic to be dropped. For instance, ACLs on the interface that has ip nat inside configured on it should use the non-NATed addressing for traffic entering it from the private netwok, and ACLs on the interface that has ip nat outside configured on it should use NATed addressing for traffic entering it from the public side.
- NAT access list is missing networks to be NATed- The access list that is used to define interesting traffic for the NAT operation must define all the network ranges that need to be NATed. Missing an address or a number of addresses from this access list keeps NAT from occurring for the traffic coming from these addresses.
- Missing the overload keyword in the NAT statement- If only a limited number of globally routable addresses are available to do NAT, Port Address Translation (PAT) or Overload NAT must be used to allow all the hosts on the RFC 1918 addressed network to reach the public network. To set up PAT, the keyword overload must be used at the end of the NAT configuration command. Omitting this command causes PAT not to be turned on, resulting in only a limited number of hosts being able to access the public network or the Internet. Here is an example of using the overload keyword: ip nat inside source access list 1 interface Ethernet0/0 overload
- Asymmetric routing causes NAT to fail- NAT occurs when a packet enters an interface configured with the ip nat inside command and leaves via an interface configured with the ip nat outside command. On a router with multiple interfaces, you must make sure that all interfaces on which traffic, that needs to be NATed, enters the router, and all interfaces from which this traffic exits, are configured with the ip nat inside and ip nat outside commands, respectively. Failure to do so causes NAT not to occur for traffic passing through the interface that does not have the appropriate NAT command configured on it.
- Overlapping addresses in the NAT pool and static NAT entries- It is important to make sure that the IP addresses in the NAT pool are not also being used for a static NAT translation. This can cause NAT to fail intermittently.
- Using extended access lists to define interesting traffic for NAT- By default, the translations that NAT creates contain only entries for the inside global and inside local address unless PAT is being used. This is done because this is all the information that is needed for simple NAT of inside local addresses to inside global addresses and to de-NAT the return traffic. However, this remains true even when extended access lists are used to define the interesting traffic.
