Troubleshooting NAT/PAT Issues

NAT and PAT failures are among the most deceptive faults in Cisco IOS networking — the router accepts every configuration command without complaint, yet traffic silently fails to reach the internet. The root causes almost always fall into one of four categories: interfaces not labelled inside or outside, an ACL that does not match the real traffic, a pool that is exhausted or misconfigured, or a routing gap that prevents translated packets from reaching their destination. This lab builds a structured diagnostic workflow using show ip nat translations, show ip nat statistics, and debug ip nat to pinpoint each failure category quickly.

Before starting, ensure you are familiar with how NAT works end-to-end. Review Static NAT Configuration for one-to-one address mapping, Dynamic NAT & PAT Configuration for pool-based and overload translation, and NAT Overview for the underlying theory. For ACL fundamentals referenced throughout this lab, see Standard ACL Configuration and ACL Overview. For wildcard mask syntax used in NAT ACLs, see Wildcard Masks. For default routes referenced in routing gap scenarios, see Default Routes.

1. NAT/PAT Failure Categories — Overview

How the Router Processes a NAT Packet

Understanding the exact processing order is essential for systematic troubleshooting. Every packet that should be translated passes through this sequence — a failure at any step produces silence with no error message:

Packet arrives on inside interface (Gi0/1) Step 1 Is the interface marked "ip nat inside"? NO → routed normally, NAT never invoked · Diagnose: show ip interface Gi0/1 | include NAT Step 2 Does the ACL bound to the NAT rule permit this source IP? NO → not translated, forwarded with private source IP — internet drops it · Diagnose: show ip nat statistics Step 3 Is a translation pool available? (dynamic NAT only) NO → packet dropped, "nat: address allocation failed" in debug ip nat · Check show ip nat statistics misses Step 4 Is the egress interface marked "ip nat outside"? NO → translation entry created but packet not re-written on egress · Diagnose: show ip interface Gi0/0 | include NAT Step 5 Is there a route to forward the translated packet? NO → router drops packet, "no route to host" · Diagnose: show ip route 0.0.0.0 or show ip route [dest] Translation succeeds — packet exits with public source IP NetsTuts

The Four NAT Failure Categories

# Category Root Cause Symptom Primary Diagnostic
1 Interface assignment ip nat inside / ip nat outside missing or swapped No translations appear — show ip nat translations is empty show ip interface [int]
2 ACL mismatch ACL does not match the actual source subnet; wrong wildcard; wrong ACL number bound to NAT rule Translations missing for specific hosts; others work; debug shows no match show ip nat statistics, debug ip nat
3 Pool exhaustion Dynamic NAT pool has no free addresses; overload not configured; pool range too small Some hosts translate, others do not; "misses" counter increments show ip nat statistics, show ip nat translations
4 Routing gap No default route or specific route to reach the public destination after translation Translations appear correctly but traffic still fails end-to-end show ip route, ping from inside address

NAT Address Terminology

Term Definition Example
Inside local The private IP address of the internal host — as seen from inside the network 192.168.10.10
Inside global The public IP address assigned to the internal host after translation — as seen from outside 203.0.113.5
Outside global The public IP address of the remote server — as seen from outside 8.8.8.8
Outside local The address of the remote server as seen from inside — usually the same as outside global unless NAT is applied in both directions 8.8.8.8

2. Lab Topology & Broken Scenarios

All four failure categories are reproduced using a single topology. Each scenario introduces one deliberate misconfiguration — the goal is to identify the fault and correct it using the diagnostic workflow:

Inside — 192.168.10.0/24 PC1: 192.168.10.10 PC2: 192.168.10.11 Gi0/1 ip nat inside 192.168.10.1 NetsTuts_R1 ip nat inside source list 1 interface Gi0/0 overload access-list 1 permit 192.168.10.0 0.0.0.255 NAT pool INET-POOL 203.0.113.10–203.0.113.20 Gi0/0 ip nat outside 203.0.113.2/30 ISP 203.0.113.1 8.8.8.8 (Google DNS — test destination) Four Fault Scenarios A Interface labels missing/swapped show ip nat translations is empty B ACL permits wrong subnet 192.168.20.0 instead of 192.168.10.0 C Pool exhausted — no overload PC1 uses the 1 address, PC2 fails D No default route after translation Entries in table but traffic still fails Primary diagnostics show ip nat translations show ip nat statistics debug ip nat NAT address terms Inside local: 192.168.10.10 (private host) Inside global: 203.0.113.5 (translated public) Outside global: 8.8.8.8 (remote server) NetsTuts

3. Step 1 — Establish the Correct Baseline Configuration

Before introducing faults, configure a fully working PAT setup. All troubleshooting in subsequent steps diagnoses deviations from this known-good state: 

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Interface labels ──────────────────────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#ip address 192.168.10.1 255.255.255.0
NetsTuts_R1(config-if)#ip nat inside
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#ip address 203.0.113.2 255.255.255.252
NetsTuts_R1(config-if)#ip nat outside
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

! ── ACL permitting inside subnet ──────────────────────────
NetsTuts_R1(config)#access-list 1 permit 192.168.10.0 0.0.0.255

! ── PAT using outside interface address (overload) ────────
NetsTuts_R1(config)#ip nat inside source list 1 interface GigabitEthernet0/0 overload

! ── Default route to ISP ──────────────────────────────────
NetsTuts_R1(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.1

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
Every NAT configuration requires exactly these four components to work: inside interface label, outside interface label, an ACL defining which traffic to translate, and a NAT/PAT rule binding the ACL to the translation method. A missing default route is a fifth failure point that operates independently of NAT — traffic can translate successfully but still have nowhere to go. Verify the full configuration with show running-config and save with write memory.

4. Step 2 — Primary Diagnostic Commands

show ip nat translations

NetsTuts_R1#show ip nat translations
Pro  Inside global       Inside local        Outside local       Outside global
tcp  203.0.113.2:49152   192.168.10.10:49152 8.8.8.8:53          8.8.8.8:53
tcp  203.0.113.2:49153   192.168.10.11:49153 8.8.8.8:80          8.8.8.8:80
icmp 203.0.113.2:1       192.168.10.10:1     8.8.8.8:1           8.8.8.8:1
Each row is one active translation. The Inside local column shows the original private IP — this is the source address of packets arriving from inside. The Inside global column shows the translated public IP and port assigned by PAT. Outside local and Outside global are both 8.8.8.8 here — they differ only when NAT is applied in both directions. An empty translation table when traffic should be flowing is the strongest indicator of a Category 1 (interface label) or Category 2 (ACL) fault.

show ip nat translations verbose

NetsTuts_R1#show ip nat translations verbose
Pro  Inside global       Inside local        Outside local       Outside global
tcp  203.0.113.2:49152   192.168.10.10:49152 8.8.8.8:53          8.8.8.8:53
    create 00:00:12, use 00:00:12, timeout:00:01:00, left 00:00:48,
    Map-Id(In): 1, portlist used: 49152, flags: extended

icmp 203.0.113.2:1       192.168.10.10:1     8.8.8.8:1           8.8.8.8:1
    create 00:00:05, use 00:00:05, timeout:00:01:00, left 00:00:55,
    Map-Id(In): 1, flags: extended
The verbose keyword adds the creation time, last-use time, remaining timeout, and the NAT map ID. The timeout shows how long before an idle entry is removed — PAT entries default to 1 minute for ICMP and DNS, 24 hours for TCP established sessions. If entries disappear faster than expected, confirm the timeout with show ip nat translations verbose and adjust with ip nat translation timeout [seconds].

show ip nat statistics

NetsTuts_R1#show ip nat statistics
Total active translations: 3 (0 static, 3 dynamic; 3 extended)
Peak translations: 5, occurred 00:02:14 ago
Outside interfaces:
  GigabitEthernet0/0
Inside interfaces:
  GigabitEthernet0/1
Hits:          47    Misses:         0
CEF Translated packets:  47, CEF Punted packets:  0
Expired translations:    12
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 1 interface GigabitEthernet0/0 refcount 3
This output is the fastest single-command health check for NAT. Key fields: Outside/Inside interfaces confirm which interfaces are labelled correctly. Hits is the count of packets that matched an existing or new translation. Misses is the count of packets that should have been translated but were not — a non-zero misses counter means something is preventing translation (ACL mismatch, pool exhaustion). Dynamic mappings shows the ACL and interface/pool bound to each NAT rule.

debug ip nat

! ── CAUTION: limit output with an ACL on busy routers ────
NetsTuts_R1(config)#access-list 100 permit ip host 192.168.10.10 any
NetsTuts_R1(config)#end

NetsTuts_R1#debug ip nat 100
IP NAT debugging is on for access list 100

! ── Sample output when NAT is working ────────────────────
NAT*: s=192.168.10.10->203.0.113.2, d=8.8.8.8 [13524]
NAT*: s=8.8.8.8, d=203.0.113.2->192.168.10.10 [13524]

! ── Sample output when NAT is NOT translating ─────────── 
! (silence — no NAT debug lines appear at all)

NetsTuts_R1#undebug all
Each debug line shows the translation event in real time. The format s=192.168.10.10->203.0.113.2 confirms the source address was rewritten — private to public. The return path line shows the destination being rewritten back. The asterisk (NAT*) indicates the translation was performed by CEF (fast path) rather than the process-switched slow path. Complete silence when traffic is flowing means NAT is not being invoked at all — the most likely cause is missing ip nat inside on the ingress interface. Always disable debug immediately after capture: undebug all.

Diagnostic Command Summary

Command What It Shows Best Used For
show ip nat translations Active translation table — inside local/global, outside local/global, protocol, port First check — is translation happening at all? Are specific hosts missing?
show ip nat translations verbose All above plus creation time, timeout, map ID Entry lifetime analysis — why are entries expiring too fast or not at all?
show ip nat statistics Interface labels, hits/misses counters, dynamic mapping ACL+pool binding Quick health check — confirm interfaces are labelled, check for misses
debug ip nat [acl] Real-time per-packet translation events — shows address rewriting or absence of it Confirm translation is happening packet-by-packet; silence confirms NAT not invoked
show ip interface brief All interface IPs and line/protocol status Confirm interfaces are up before troubleshooting NAT logic
show ip route Routing table — default route, specific routes Verify a path exists after translation (Category 4 — routing gap)
clear ip nat translation * Clears all dynamic NAT/PAT translation entries Reset the translation table before re-testing after a config fix

5. Scenario A — Missing or Swapped Inside/Outside Labels

The most common NAT misconfiguration. The router will not invoke NAT on a packet unless it arrives on an ip nat inside interface. If the labels are missing or reversed, every other part of the NAT configuration is irrelevant — translation never happens.

Introducing the Fault

! ── Remove inside label from Gi0/1 ──────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#no ip nat inside
NetsTuts_R1(config-if)#exit

Symptom — show ip nat statistics

NetsTuts_R1#show ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Peak translations: 0
Outside interfaces:
  GigabitEthernet0/0
Inside interfaces:
  (none configured)
Hits:    0    Misses:    0
The critical indicator is "Inside interfaces: (none configured)". Both Hits and Misses are zero — the NAT process is not even being invoked because no interface is designated as inside. Packets arrive on Gi0/1 and are routed normally without NAT. Notice the misses counter is also zero — misses only increment when NAT is invoked but fails to find a translation. No inside label means NAT is never invoked in the first place.

Symptom — debug ip nat

NetsTuts_R1#debug ip nat 100
IP NAT debugging is on for access list 100

! ── PC1 pings 8.8.8.8 — complete silence in debug ───────
! (no NAT debug lines appear despite active traffic)

NetsTuts_R1#undebug all

Diagnosis — show ip interface

NetsTuts_R1#show ip interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet address is 192.168.10.1/24
  Inbound  access list is not set
  Outgoing access list is not set
  IP NAT: outside  ← WRONG — should be "inside"
  ...

NetsTuts_R1#show ip interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet address is 203.0.113.2/30
  IP NAT: outside  ← correct
  ...
The show ip interface output explicitly states "IP NAT: outside" or "IP NAT: inside" for each interface. If neither label appears, NAT is not configured on that interface. If the labels are swapped (inside applied to the WAN, outside applied to the LAN), the router tries to translate packets arriving from the internet and re-write them toward the LAN — the exact opposite of the intended behaviour.

Fix

NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#ip nat inside
NetsTuts_R1(config-if)#exit

! ── Clear stale entries and re-test ──────────────────────
NetsTuts_R1#clear ip nat translation *

6. Scenario B — ACL Does Not Match the Traffic

The NAT rule references an ACL to determine which source addresses should be translated. If the ACL is misconfigured — wrong subnet, wrong wildcard, wrong ACL number in the NAT rule — matching packets are not translated. Non-matching packets are forwarded with their original private source IP, which the internet drops.

Introducing the Fault — Wrong Subnet in ACL

! ── ACL permits 192.168.20.0 but inside network is 192.168.10.0 ──
NetsTuts_R1(config)#no access-list 1
NetsTuts_R1(config)#access-list 1 permit 192.168.20.0 0.0.0.255

Symptom — show ip nat statistics

NetsTuts_R1#show ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Peak translations: 3, occurred 00:05:10 ago
Outside interfaces:
  GigabitEthernet0/0
Inside interfaces:
  GigabitEthernet0/1
Hits:    0    Misses:    14
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 1 interface GigabitEthernet0/0 refcount 0
The inside and outside interfaces are correctly labelled — but the Misses counter is 14 and climbing. This is the signature of a Category 2 fault: NAT is being invoked (interfaces are labelled), but the ACL is rejecting every packet (no hits, only misses). The translation table is empty — no successful translations have occurred. The peak translations of 3 from earlier confirm the configuration worked before the ACL was changed.

Symptom — debug ip nat

NetsTuts_R1#debug ip nat 100
IP NAT debugging is on for access list 100

! ── PC1 pings 8.8.8.8 — still silence ───────────────────
! NAT is invoked but immediately rejects the packet due to ACL miss
! No translation event fires — packet forwarded un-translated

NetsTuts_R1#undebug all
Even with debug enabled, there is silence — but the cause is different from Scenario A. Here NAT is invoked (the interface labels are correct), but the ACL denies the packet before a translation entry is created, so no debug line is generated. The distinguishing factor between Scenario A and B is the Misses counter: zero in Scenario A (NAT not invoked), non-zero in Scenario B (NAT invoked but ACL denies).

Diagnosis — Verify the ACL

NetsTuts_R1#show ip nat statistics
! ── Misses counter confirms ACL is rejecting packets ─────

NetsTuts_R1#show access-lists 1
Standard IP access list 1
    10 permit 192.168.20.0, wildcard bits 0.0.0.255 (0 matches)

! ── Zero matches confirm no inside traffic is matching ACL 1 ──
! ── Inside network is 192.168.10.0 — ACL permits wrong subnet ─

Fix

NetsTuts_R1(config)#no access-list 1
NetsTuts_R1(config)#access-list 1 permit 192.168.10.0 0.0.0.255

NetsTuts_R1#clear ip nat translation *
ACL bound to wrong NAT rule: A second variant of this fault is when the correct ACL exists but the NAT rule references a different ACL number. For example, ACL 1 permits the correct subnet but the NAT rule says ip nat inside source list 2 ... and ACL 2 does not exist or permits a different range. Check the "Dynamic mappings" section of show ip nat statistics — it shows exactly which ACL is bound to each NAT rule.

7. Scenario C — Pool Exhaustion (Dynamic NAT Without Overload)

Dynamic NAT (without overload) maps each inside host to one dedicated public IP address from a pool. When the pool runs out of free addresses, new translation requests are silently dropped. This is the classic scenario where PC1 can reach the internet but PC2 cannot — because PC1 holds the only pool address.

Introducing the Fault — Single-Address Pool Without Overload

! ── Remove PAT overload, configure dynamic NAT with tiny pool ──
NetsTuts_R1(config)#no ip nat inside source list 1 interface GigabitEthernet0/0 overload

NetsTuts_R1(config)#ip nat pool INET-POOL 203.0.113.10 203.0.113.10 netmask 255.255.255.0
NetsTuts_R1(config)#ip nat inside source list 1 pool INET-POOL
The pool INET-POOL contains only one address (203.0.113.10 to 203.0.113.10). Without overload, each inside host requires one dedicated pool address. The first host to generate traffic claims 203.0.113.10 — the second host finds the pool empty and its packets are dropped without any notification.

Symptom — show ip nat translations

NetsTuts_R1#show ip nat translations
Pro  Inside global     Inside local        Outside local    Outside global
---  203.0.113.10      192.168.10.10       ---              ---
PC1 (192.168.10.10) has claimed 203.0.113.10. Notice there are no port numbers in this entry — this is a dynamic NAT entry (no overload), not PAT. The --- in the protocol and outside columns indicates a static-style mapping with no specific connection tracking. PC2 (192.168.10.11) has no entry — its traffic is being dropped silently.

Symptom — show ip nat statistics

NetsTuts_R1#show ip nat statistics
Total active translations: 1 (0 static, 1 dynamic; 0 extended)
Peak translations: 1
Outside interfaces:
  GigabitEthernet0/0
Inside interfaces:
  GigabitEthernet0/1
Hits:    22    Misses:    18
Dynamic mappings:
-- Inside Source
[Id: 2] access-list 1 pool INET-POOL refcount 1
 pool INET-POOL: id 1, netmask 255.255.255.0
       start 203.0.113.10 end 203.0.113.10
       type generic, total addresses 1, allocated 1 (100%), misses 18
The pool statistics are the definitive indicator of exhaustion: total addresses 1, allocated 1 (100%), misses 18. Every new translation request since the pool was exhausted increments the misses counter. The 100% allocation confirms there are no free addresses remaining. In a real environment with a larger pool, partial exhaustion would show 80–90% allocation with a growing misses count during peak hours.

Fix — Add Overload (PAT)

! ── Option 1: Add overload to the existing pool rule ─────
NetsTuts_R1(config)#no ip nat inside source list 1 pool INET-POOL
NetsTuts_R1(config)#ip nat inside source list 1 pool INET-POOL overload

! ── Option 2: Switch to interface-based PAT (simpler) ────
NetsTuts_R1(config)#no ip nat inside source list 1 pool INET-POOL
NetsTuts_R1(config)#ip nat inside source list 1 interface GigabitEthernet0/0 overload

NetsTuts_R1#clear ip nat translation *
Adding overload converts dynamic NAT to PAT — multiple inside hosts share the single pool address (or the interface address) differentiated by port number. This resolves pool exhaustion completely: PAT supports up to approximately 65,535 concurrent translations per public IP address. Option 2 (interface-based PAT) is the most common real-world configuration because it automatically uses whatever IP address is assigned to the outside interface, even if it changes via DHCP from the ISP.

Fix — Expand the Pool

! ── If PAT is not desired — expand the pool range ────────
NetsTuts_R1(config)#no ip nat pool INET-POOL
NetsTuts_R1(config)#ip nat pool INET-POOL 203.0.113.10 203.0.113.20 netmask 255.255.255.0
! ── Pool now has 11 addresses (10 through 20) ────────────

8. Scenario D — Routing Gap After Translation

NAT only rewrites addresses — it does not create routes. If no route exists to forward the translated packet toward the internet, the router drops it after translation. This is a uniquely deceptive fault because show ip nat translations looks perfectly healthy — entries are being created — yet traffic still fails end-to-end.

Introducing the Fault — Remove the Default Route

! ── Remove default route ─────────────────────────────────
NetsTuts_R1(config)#no ip route 0.0.0.0 0.0.0.0 203.0.113.1

Symptom — show ip nat translations

NetsTuts_R1#show ip nat translations
Pro  Inside global       Inside local        Outside local    Outside global
icmp 203.0.113.2:1       192.168.10.10:1     8.8.8.8:1        8.8.8.8:1
The translation entry exists and looks correct — 192.168.10.10 has been translated to 203.0.113.2. But the ping still fails. This is what makes the routing gap fault the hardest to diagnose: every NAT command shows green. The fault lies entirely outside the NAT subsystem.

Symptom — show ip nat statistics

NetsTuts_R1#show ip nat statistics
Total active translations: 1 (0 static, 1 dynamic; 1 extended)
Hits:    4    Misses:    0
Hits are incrementing, misses are zero — NAT is translating every packet successfully. The fault is not in NAT at all. This is the critical distinction: in all other scenarios either the translation table is empty or misses are non-zero. Here everything in NAT is working perfectly.

Diagnosis — show ip route

NetsTuts_R1#show ip route
Codes: C - connected, S - static, ...

      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.10.0/24 is directly connected, GigabitEthernet0/1
L        192.168.10.1/32 is directly connected, GigabitEthernet0/1
      203.0.113.0/30 is variably subnetted, 2 subnets, 2 masks
C        203.0.113.0/30 is directly connected, GigabitEthernet0/0
L        203.0.113.2/32 is directly connected, GigabitEthernet0/0

! ── No S*  0.0.0.0/0 entry — default route is missing ────
The absence of S* 0.0.0.0/0 confirms the routing gap. After translating 192.168.10.10 to 203.0.113.2, the router looks up the destination 8.8.8.8 in the routing table and finds no match. The packet is dropped with an ICMP unreachable message back to the inside host — which never reaches the internet. Always check show ip route when NAT looks correct but end-to-end connectivity fails. For general Layer 3 routing troubleshooting see Troubleshooting Layer 3 Routing.

Fix

NetsTuts_R1(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.1

NetsTuts_R1#show ip route | include 0.0.0.0
S*    0.0.0.0/0 [1/0] via 203.0.113.1

9. Additional NAT/PAT Issues

Static NAT — Translation in Wrong Direction

! ── Static NAT maps inside host to public IP ─────────────
! ── Correct direction: ip nat inside source static [inside-local] [inside-global]
NetsTuts_R1(config)#ip nat inside source static 192.168.10.10 203.0.113.5

! ── WRONG — this translates OUTSIDE-to-INSIDE (destination NAT) ──
! NetsTuts_R1(config)#ip nat outside source static 203.0.113.5 192.168.10.10
ip nat inside source translates the source address of packets arriving from inside — the typical outbound NAT direction. ip nat outside source translates the source address of packets arriving from outside — used for very specific inbound translation scenarios. Confusing these two commands produces translations in the wrong direction — inside hosts cannot reach the internet and/or inbound connections behave unexpectedly. Always verify direction with show ip nat statistics and confirm the Dynamic mappings section shows "Inside Source."

Clearing the Translation Table

! ── Clear all dynamic translations ───────────────────────
NetsTuts_R1#clear ip nat translation *

! ── Clear only translations for one inside host ──────────
NetsTuts_R1#clear ip nat translation inside 192.168.10.10

! ── Clear only TCP translations to a specific destination ─
NetsTuts_R1#clear ip nat translation tcp inside 192.168.10.10 49152 outside 8.8.8.8 80

! ── Static translations are NOT cleared by "clear ip nat translation *"
! ── Remove and re-add the static command to reset static entries
Always clear the translation table after changing NAT configuration — stale entries from the old configuration will continue to be used until they time out naturally (up to 24 hours for established TCP). clear ip nat translation * removes all dynamic entries instantly. Note it does not remove static entries — those are only removed by deleting the ip nat inside source static command. If a fix does not seem to take effect, stale translations are often the reason.

NAT Pool Subnet Mismatch

! ── WRONG: pool netmask does not match the pool address range ──
NetsTuts_R1(config)#ip nat pool BAD-POOL 203.0.113.10 203.0.113.20 netmask 255.255.255.252

! ── The /30 netmask covers only 203.0.113.8 – 203.0.113.11 ──────
! ── Addresses 203.0.113.12 – 203.0.113.20 are outside the subnet ─
! ── IOS will reject or silently truncate the pool ────────────────

! ── CORRECT: use a netmask that covers the entire pool range ──
NetsTuts_R1(config)#ip nat pool GOOD-POOL 203.0.113.10 203.0.113.20 netmask 255.255.255.0
The netmask in an ip nat pool command must cover the entire address range from start to end. If the netmask is too narrow, IOS either rejects the command or silently limits the pool to the addresses that fit within the subnet boundary. Verify pool size in show ip nat statistics — "total addresses" should match the expected count. A /24 covering 203.0.113.0–255 contains 11 usable addresses from .10 to .20.

PAT Port Block Exhaustion (High-Volume)

NetsTuts_R1#show ip nat translations total
Total number of translations: 64521

! ── Approaching the 65535 port limit per public IP ───────────
! ── Add a second public IP or pool to expand PAT capacity ────
NetsTuts_R1(config)#ip nat pool EXTRA-POOL 203.0.113.3 203.0.113.4 netmask 255.255.255.252
NetsTuts_R1(config)#ip nat inside source list 1 pool EXTRA-POOL overload
PAT supports approximately 65,535 simultaneous port translations per public IP address. In high-density environments (schools, enterprises, ISPs), a single IP can become saturated. When the port table is full, new connections are dropped silently. Monitor with show ip nat translations total — if the count approaches 64,000 consistently, add additional public IP addresses to the PAT pool. Each additional IP multiplies the available port space.

10. Structured Troubleshooting Workflow

Step Command What to Look For If Found
1 show ip nat statistics Inside/outside interfaces listed? Hits/misses ratio? No inside interface → Scenario A (add ip nat inside). Misses only → Scenario B (fix ACL). Misses + pool 100% → Scenario C (add overload or expand pool)
2 show ip nat translations Are entries being created? Correct inside local/global addresses? Empty table → confirm interfaces first. Correct entries but no connectivity → Scenario D (check routing)
3 show ip interface [int] "IP NAT: inside" on LAN interface, "IP NAT: outside" on WAN interface? Missing or swapped → remove and re-add the correct label
4 show access-lists [n] Does the ACL permit the actual inside subnet? Is the match counter incrementing? Zero matches or wrong subnet → fix the ACL permit statement
5 show ip route Is there a default route (S* 0.0.0.0/0) or a specific route to the internet? No default route → add ip route 0.0.0.0 0.0.0.0 [next-hop]
6 debug ip nat [acl] Are translation events appearing? Or silence? Silence → interface labels missing (Scenario A). Events but traffic fails → routing gap (Scenario D)
7 clear ip nat translation * After any config fix, clear stale translations before retesting Always do this — old entries persist and mask fixes

Key Points & Exam Tips

  • NAT requires both ip nat inside on the LAN interface and ip nat outside on the WAN interface. Missing either label means NAT is never invoked — the translation table stays empty and the misses counter stays at zero.
  • show ip nat statistics is the fastest first diagnostic: check the Inside/Outside interface list first, then compare Hits vs Misses. All misses and no hits means the ACL is rejecting traffic or NAT is not being invoked at all.
  • The Misses counter distinguishes an ACL fault from an interface label fault: misses are zero when NAT is not invoked (no inside label), and non-zero when NAT is invoked but the ACL denies the packet.
  • Pool exhaustion is confirmed by show ip nat statistics showing "allocated 100%" on the pool. Fix with overload to enable PAT, or expand the address range in the pool definition.
  • A routing gap produces the most deceptive symptom: show ip nat translations looks healthy with correct entries, but end-to-end connectivity still fails. Always check show ip route when NAT looks correct but traffic does not flow.
  • Always run clear ip nat translation * after changing NAT configuration — stale entries from the old config persist and continue to be used for up to 24 hours for TCP sessions.
  • debug ip nat [acl] with a filter ACL is the most granular tool. Complete silence means NAT is not invoked. Seeing s=private->public entries confirms translation is happening. Always undebug all immediately after testing.
  • Static NAT entries (ip nat inside source static) are not cleared by clear ip nat translation * — they must be removed by deleting the static NAT command itself.
  • The four categories in order of frequency: interface labels (most common) → ACL mismatch → routing gap → pool exhaustion.
  • On the CCNA exam: know the output of show ip nat translations (inside local vs inside global), the meaning of the Hits/Misses counters in show ip nat statistics, the overload keyword for PAT, and the four NAT address terms (inside local, inside global, outside local, outside global).
Next Steps: For building the initial NAT/PAT configuration that this lab troubleshoots, see Dynamic NAT & PAT Configuration and Static NAT Configuration. For extended ACLs used in more specific NAT permit rules, see Extended ACL Configuration. For logging NAT translation events to a syslog server, review Syslog Configuration and show logging. For the NAT and PAT theory covered in this lab see NAT Overview. For broader Layer 3 troubleshooting beyond NAT see Troubleshooting Layer 3 Routing. For default route configuration referenced in Scenario D see Default Routes.

TEST WHAT YOU LEARNED

A router has a complete NAT configuration but show ip nat translations is empty and both Hits and Misses in show ip nat statistics are zero. What is the most likely cause?

Correct answer is B. The key diagnostic clue is that both Hits and Misses are zero. Misses only increment when NAT is invoked but the ACL denies the packet — so zero misses means NAT was never invoked at all. NAT is only invoked when a packet arrives on an interface marked ip nat inside. Without that label, the router processes the packet as ordinary routing — no translation, no counters. Option A (ACL mismatch) would show zero Hits but non-zero Misses. Option C (pool exhaustion) would show some Hits (first host) and growing Misses (subsequent hosts). Option D (no route) would show Hits incrementing because translation succeeds before the routing lookup fails.

show ip nat statistics shows Hits: 0, Misses: 47. The inside and outside interfaces are correctly labelled. What does this indicate?

Correct answer is D. The pattern of zero Hits with non-zero Misses is the definitive signature of an ACL mismatch. The interfaces are labelled (NAT is being invoked — hence the misses counter incrementing), but the ACL is denying every packet before a translation entry is created. Pool exhaustion (Option A) would show some Hits for hosts that translated successfully before the pool emptied — not zero Hits. A missing default route (Option B) would show Hits incrementing because translation succeeds; the routing failure happens after NAT. A missing outside label would produce a more complex symptom where the translation table might have entries but return traffic is not re-written.

What is the difference between the "Inside local" and "Inside global" addresses in show ip nat translations?

Correct answer is A. The four NAT address terms describe the same packet from two perspectives — inside (the private network view) and outside (the public internet view). Inside local: the private IP as it exists inside your network (e.g. 192.168.10.10). Inside global: the public IP that the internet sees for that same host after translation (e.g. 203.0.113.2). Outside local: the destination IP as seen from inside — usually the same as the real server IP. Outside global: the real public IP of the remote server. The "local" vs "global" distinction refers to whether the address is a private (local) or public (global) address, not physical location relative to the router.

A network has two inside PCs. PC1 can reach the internet, PC2 cannot. show ip nat statistics shows the pool at 100% allocation with misses incrementing. What is the fix?

Correct answer is C. The symptom — PC1 works, PC2 does not, pool 100% allocated, misses incrementing — is textbook pool exhaustion from dynamic NAT without overload. Each inside host requires one dedicated pool IP. When the pool has only one address, the first host to generate traffic claims it permanently (until the translation times out or is cleared). Adding overload converts the rule to PAT: all inside hosts share one public IP, distinguished by unique source port numbers. PAT supports up to ~65,535 simultaneous sessions per public IP. Option D (reducing timeout) is a workaround at best — it introduces connection instability for PC1 rather than solving the root cause.

show ip nat translations shows correct entries with accurate inside local and inside global addresses. But pings from inside PCs to 8.8.8.8 still fail. What should be checked next?

Correct answer is D. When the translation table contains correct entries, NAT is functioning. The problem is downstream of NAT — in the routing layer. After rewriting the source IP from private to public, the router performs a routing lookup for the destination (8.8.8.8). If no default route or specific route exists for 8.8.8.8, the packet is dropped. This is the most deceptive NAT fault because all NAT-specific commands appear healthy. The fix is to add ip route 0.0.0.0 0.0.0.0 [ISP-next-hop]. Always check show ip route when NAT diagnostics look correct but end-to-end connectivity fails.

After fixing a NAT misconfiguration, connectivity is still broken. The config looks correct. What step is frequently overlooked?

Correct answer is B. The NAT translation table is built dynamically and entries persist based on their configured timeout — up to 1 minute for ICMP/UDP, and up to 24 hours for established TCP sessions. When you fix a broken NAT rule (e.g. correct the ACL or change the pool), the stale entries created under the old broken config remain active. New traffic may match those stale entries rather than being processed by the corrected rule. clear ip nat translation * instantly removes all dynamic entries, forcing the next packet to create a fresh translation under the corrected configuration. This is a required step after any NAT fix — not optional.

What does complete silence from debug ip nat indicate when inside hosts are actively sending traffic toward the internet?

Correct answer is A. debug ip nat fires an event every time the NAT process handles a packet — whether it succeeds or fails to translate. Complete silence means the NAT process is not seeing the packets at all. The NAT process is only invoked when a packet arrives on an ip nat inside interface (for outbound) or an ip nat outside interface (for inbound translation). If neither label is present on the relevant interface, packets pass through the routing engine without touching NAT, and debug produces nothing. This is distinct from an ACL mismatch (where NAT is invoked but rejects the packet — the misses counter increments even though debug may not print a translation event).

An engineer configures ip nat outside source static 203.0.113.5 192.168.10.10 instead of ip nat inside source static 192.168.10.10 203.0.113.5. What is the practical effect?

Correct answer is C. ip nat inside source translates the source address of packets arriving from the inside network — standard outbound NAT used to allow private hosts to reach the internet. ip nat outside source translates the source address of packets arriving from the outside network — a much rarer configuration used in specific scenarios such as overlapping address spaces. Using ip nat outside source static instead of ip nat inside source static means the router is configured to translate traffic coming in from the internet (rewriting the internet source IP to a private IP), which is the opposite of the engineer's intent. The inside hosts still cannot reach the internet because no inside-source translation exists.

Which command removes a single stale PAT entry for inside host 192.168.10.10 talking to outside server 8.8.8.8 on TCP port 80, without clearing other active translations?

Correct answer is D. Cisco IOS supports granular translation clearing. The full syntax is clear ip nat translation tcp inside [inside-local-IP] [inside-local-port] outside [outside-global-IP] [outside-global-port]. This precisely targets one entry in the translation table while leaving all other entries intact — important in production when you need to reset a specific stuck session without disrupting other active users. Option A (clear ip nat translation *) clears all dynamic entries — too broad. Option B removes the NAT rule entirely and would break all NAT for all hosts. Option C clears all translations for the inside host 192.168.10.10 — closer, but still removes all of that host's translations, not just the specific TCP/80 entry.

An engineer is troubleshooting NAT on a router. show ip nat statistics shows the inside interface as GigabitEthernet0/0 and outside interface as GigabitEthernet0/1. The LAN is connected to Gi0/0 and the WAN to Gi0/1. The translation table is empty. What is wrong and how is it fixed?

Correct answer is A. ip nat inside must be applied to the interface facing the private network (the LAN — Gi0/0), and ip nat outside must be applied to the interface facing the public network (the WAN — Gi0/1). The output shows the labels are reversed: the LAN interface Gi0/0 is marked as inside-facing in the statistics, meaning it is actually labelled outside — which causes the router to intercept traffic arriving from the internet and attempt to translate it inbound rather than translating private LAN traffic outbound. The fix is to enter each interface and swap the labels: no ip nat outside on Gi0/1 followed by ip nat outside, and no ip nat inside on Gi0/0 followed by ip nat inside. Then clear the translation table.

Related Topics & Step-by-Step Tutorials

Related concepts and next steps:

Back to Home