"The internet is down"
On Monday morning PC1 can't open any website. PC1 can ping its gateway, R1, at 192.168.10.1. R1 itself can ping the server at 198.51.100.10. So the LAN works and the ISP link works. The problem is in between, and that is exactly where NAT lives.
The three tools
| Command | What it tells you |
|---|---|
show ip nat translations | Every current mapping. Is anything being translated at all? |
show ip nat statistics | Which interfaces are inside and outside, hit and miss counters, and pool usage. |
debug ip nat | A live log line for every packet translated. Use briefly, on a quiet router. |
Reading the statistics
Start with the statistics, because they show the setup and the counters on one screen. These outputs are based on Cisco documentation, not run on a lab device.
R1#show ip nat statistics Total active translations: 0 (0 static, 0 dynamic; 0 extended) Outside interfaces: GigabitEthernet0/0 Inside interfaces: GigabitEthernet0/1 Hits: 0 Misses: 0 Expired translations: 0 Dynamic mappings: -- Inside Source [Id: 1] access-list 1 interface GigabitEthernet0/1 refcount 0
interface GigabitEthernet0/0
no ip nat outside
ip nat inside
interface GigabitEthernet0/1
no ip nat inside
ip nat outsideThe fix (based on Cisco documentation): put each interface on the right side.
Watching packets with debug
R1#debug ip nat IP NAT debugging is on NAT: s=192.168.10.11->203.0.113.2, d=198.51.100.10 [21507] NAT*: s=198.51.100.10, d=203.0.113.2->192.168.10.11 [40211] NAT*: s=192.168.10.11->203.0.113.2, d=198.51.100.10 [21508]
s= is the source and d= the destination; an arrow shows the address being changed. The first line is PC1 going out, the second is the reply coming back in. The star means the packet was handled in the fast path (CEF). The number in brackets is the IP ID of the packet. Turn debug off with undebug all.Faults and their clues
Almost every NAT problem is one of these. Each one leaves a clue in the outputs above.
| Fault | Clue | Fix |
|---|---|---|
| Inside and outside swapped, or one missing | Wrong interface lists in statistics; no translations | Correct ip nat inside / outside |
| ACL doesn't match the hosts | No rows for that host; a wrong subnet or wildcard in the ACL | Fix the ACL, e.g. 0.0.0.255, not 255.255.255.0 |
| NAT rule names the wrong ACL or pool | Statistics show refcount 0 while users send traffic | Match the numbers and names exactly |
| Pool used up (no overload) | allocated 100% and rising misses | Add overload or more addresses |
| No route back to the public addresses | Translations appear, but replies never arrive | The ISP must route the pool or static block to R1 |
| No default route on R1 | Packets dropped before NAT; ping from R1 to the internet fails | ip route 0.0.0.0 0.0.0.0 203.0.113.1 |
- 1. Does the packet reach an inside interface? Check the gateway, then that Gi0/0 is ip nat inside and the ACL matches PC1.
- 2. Is a translation made? show ip nat translations and statistics: rows, hits, misses, pool use.
- 3. Can R1 route it out? Gi0/1 must be ip nat outside, and R1 needs a default route to the ISP.
- 4. Can the reply find R1? The ISP must route the inside global address back to R1. If not, the reply never arrives.
💡 Testing from the router? A plain ping from R1 uses R1's outside address and is not translated. To test NAT from R1, use an extended ping with source GigabitEthernet0/0, or better, test from a real inside PC.
Check yourself
show ip nat statistics shows Hits: 0 and the office-facing interface listed under Outside interfaces. What is wrong?
R1 uses a pool. A row maps PC1 to 203.0.113.17, but its web pages never load. What should you check next?
A pool shows 'allocated 4 (100%), misses 12'. What is the simplest fix?