Troubleshooting NAT and PAT: Address Translation Challenges

NAT and PAT seem deceptively simple until you're standing in front of a production outage where half your users can't reach the internet and the other half are getting intermittent drops. Address translation sits at the boundary between your internal addressing scheme and the outside world, which means a misconfiguration here can manifest as symptoms that look like routing problems, firewall issues, or even application failures. This post focuses on systematic NAT PAT troubleshooting methodology, the translation errors that catch experienced engineers off guard, and the connectivity issues that require more than a quick show ip nat translations to resolve.

Understanding the NAT Translation Table First

Before you can troubleshoot effectively, you need to read the translation table correctly. The output of show ip nat translations is your primary diagnostic surface.

Router# show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
tcp 203.0.113.10:1024  192.168.1.100:1024 8.8.8.8:53        8.8.8.8:53
tcp 203.0.113.10:1025  192.168.1.101:1025 8.8.8.8:443       8.8.8.8:443
---  203.0.113.10       192.168.1.50      ---                ---

The four-column structure is critical. Inside local is the pre-translation source. Inside global is the post-translation source as seen from the outside. For standard PAT, multiple inside local addresses map to one inside global with unique port numbers. If you see entries without port numbers (like the last line above), that is a static NAT entry. Mixing static and dynamic entries in the same pool without careful planning is one of the most common sources of NAT problems in enterprise environments.

Also run show ip nat statistics to get hit counts, miss counts, and pool exhaustion indicators:

Router# show ip nat statistics
Total active translations: 847 (2 static, 845 dynamic; 845 extended)
Peak translations: 1203, occurred 00:14:32 ago
Outside interfaces: GigabitEthernet0/0
Inside interfaces: GigabitEthernet0/1
Hits: 54321  Misses: 142
Expired translations: 12400
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 10 pool OUTSIDE_POOL refcount 845
 pool OUTSIDE_POOL: netmask 255.255.255.248
        start 203.0.113.10 end 203.0.113.17
        type generic, total addresses 8, allocated 8 (100%), misses 14

That last line tells the full story in a pool exhaustion scenario: 100% allocation and 14 misses. Users are being denied translation because no ports or addresses remain.

Common NAT Problems and Their Root Causes

Asymmetric Routing Breaking Stateful Translation

NAT is stateful. The router that creates the translation entry must also process the return traffic. In dual-WAN or ECMP environments, outbound traffic may leave through one path while return traffic arrives on a different interface. The router receiving the return packet has no corresponding translation entry and drops the traffic silently. From the user's perspective this looks like a one-way connectivity issue.

Verify with show ip nat translations verbose to see which interface created the entry and confirm your routing policy routes return traffic through the same device. If you're using multiple border routers, ensure sessions are pinned per flow, typically through PBR or stateful NAT synchronization if your platform supports it.

ACL Misconfiguration Preventing Translation

Dynamic NAT and PAT use an ACL to define which traffic qualifies for translation. A common translation error occurs when the ACL is too restrictive or references the wrong direction. Remember: the ACL for NAT matches on the inside local address, not the destination. Engineers coming from firewall backgrounds sometimes configure the ACL with both source and destination criteria, causing the miss counter to increment while users experience connectivity issues.

! Correct: Match only the source (inside local) subnet
ip access-list standard NAT_TRAFFIC
 permit 192.168.0.0 0.0.255.255

! Incorrect: Extended ACL that over-restricts NAT eligibility
ip access-list extended NAT_TRAFFIC_WRONG
 permit ip 192.168.0.0 0.0.255.255 host 8.8.8.8
 ! This only NATs traffic destined for 8.8.8.8 - everything else misses

Use debug ip nat carefully in production (filter with an ACL to limit output volume) to see real-time translation decisions:

Router# debug ip nat 192.168.1.100

NAT: s=192.168.1.100->203.0.113.10, d=8.8.8.8 [id]
NAT*: s=8.8.8.8, d=203.0.113.10->192.168.1.100 [id]

If you see the outbound translation but not the return translation, routing or interface assignment is the problem. If you see nothing, the ACL is not matching.

Interface Designation Errors

NAT requires explicit ip nat inside and ip nat outside assignment on interfaces. Missing or swapped assignments are a frequent source of NAT problems, especially after interface reconfigurations or when adding subinterfaces. A packet entering an interface without a NAT designation will not trigger translation, even if a valid rule exists.

! Verify interface designations
Router# show ip interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  NAT: enabled, Inside

Pay particular attention to subinterfaces in 802.1Q trunking scenarios. Each subinterface needs its own NAT designation. The parent interface designation does not propagate to subinterfaces.

PAT Port Exhaustion at Scale

PAT on a single outside IP supports approximately 64,000 simultaneous translations per destination IP/port combination. In practice, applications like video conferencing and trading platforms that maintain large numbers of persistent TCP sessions can exhaust this faster than expected. The symptom is intermittent connectivity for new sessions while existing sessions remain stable.

Mitigation options include adding additional outside IP addresses to the pool with the overload keyword, or configuring NAT with multiple outside addresses using address rotation:

ip nat pool LARGE_POOL 203.0.113.10 203.0.113.14 netmask 255.255.255.248
ip nat inside source list NAT_TRAFFIC pool LARGE_POOL overload

Clearing and Resetting Translations

Stale translation entries can block new sessions, particularly after a failover event or IP address reconfiguration. Use targeted clears rather than wiping the entire table in production:

! Clear a specific translation
clear ip nat translation inside 192.168.1.100 outside 8.8.8.8

! Clear all dynamic translations (use with caution during business hours)
clear ip nat translation *

Static translations are not cleared by clear ip nat translation *. They persist until you remove the configuration with no ip nat inside source static.

Verifying End-to-End Connectivity After Changes

After resolving the identified issue, validate with a structured test sequence: confirm translation entry creation with show ip nat translations, verify the miss counter stops incrementing with show ip nat statistics, and test actual application-layer connectivity rather than just ICMP. Many applications use specific destination ports that may still be blocked downstream even after NAT is working correctly.

For complex environments, Embedded Packet Capture (EPC) on the outside interface lets you confirm that translated packets are actually leaving the router with the correct source IP, which rules out any remaining translation errors at the hardware forwarding layer.

What's Next

With address translation troubleshooting covered, the next logical focus is first-hop redundancy protocols: HSRP, VRRP, and GLBP. Understanding how these protocols interact with NAT gateway configurations, particularly in active/standby failover scenarios where the inside gateway IP changes, rounds out your IP Services knowledge for the ENCOR exam and for production environments where both features coexist.

Tools and resources for this topic

• CCNP ENCOR 350-401 Official Cert Guide — The definitive ENCOR study resource by Brad Edgeworth. Covers enterprise infrastructure, virtualisation, and automation.