NAT (Network Address Translation) is the backbone of IPv4 address conservation and internal network privacy. On the CCNA 200-301 exam (Objective 4.1), you must be able to verify NAT operations, not just configure it. The real-world network engineer lives in the CLI, using show and debug commands to confirm translations, identify failures, and troubleshoot connectivity. This chapter arms you with the exact commands, expected outputs, and failure patterns you need to master NAT verification for the exam and for production networks.
Jump to a section
Imagine a large office building with one external phone number (the public IP) and hundreds of internal extensions (private IPs). The switchboard operator (the NAT router) maintains a logbook (the NAT translation table) of every call. When an internal extension (192.168.1.10) calls an external number (8.8.8.8), the operator picks a free external line (a public IP and port, say 203.0.113.1:5000) and records the mapping: 'Extension 192.168.1.10:12345 is using line 203.0.113.1:5000.' The operator then patches the call through. When the external party replies, the operator looks at the destination line number (203.0.113.1:5000), checks the logbook, finds the corresponding internal extension (192.168.1.10:12345), and connects the call. The operator's logbook has an expiration timer: if no conversation happens for 60 seconds (the NAT timeout), the entry is erased, freeing that external line for another call. If the logbook is full (no more available external lines), new calls fail—this is NAT pool exhaustion. In the Cisco CLI, the 'show ip nat translations' command is like asking the operator for a copy of the current logbook. 'debug ip nat' is like listening in on the operator's verbal confirmations as each call is patched. Understanding this analogy helps you grasp why NAT entries have timers, why port numbers matter, and why you see entries with '---' for inside global IP when using overload.
What is NAT Translation Verification?
NAT translation verification is the process of inspecting and confirming the state of Network Address Translation entries on a Cisco router. After configuring NAT (static, dynamic, or PAT), you must validate that translations are being created correctly, that traffic is being translated, and that the router's resources (memory, NAT pool) are not exhausted. The CCNA exam expects you to interpret the output of show commands, identify missing or incorrect translations, and troubleshoot common issues like asymmetric routing or NAT pool exhaustion.
Key Commands: The Big Three
The three most important verification commands are:
`show ip nat translations` – Displays the current NAT translation table.
`show ip nat statistics` – Shows counters, hit rates, and pool usage.
`debug ip nat` – Real-time logging of NAT translations (use with caution in production).
Let's examine each in detail.
show ip nat translations – The Translation Table
This command lists every active NAT entry. A typical output looks like:
Router# show ip nat translations
Pro Inside global Inside local Outside local Outside global
--- 203.0.113.10 192.168.1.10 --- ---
tcp 203.0.113.10:5000 192.168.1.10:12345 8.8.8.8:80 8.8.8.8:80
udp 203.0.113.10:5001 192.168.1.10:53 8.8.4.4:53 8.8.4.4:53Pro: Protocol (TCP, UDP, or --- for static or ICMP).
Inside global: The translated source IP/port as seen on the outside.
Inside local: The original source IP/port from the inside host.
Outside local: The destination IP/port as seen from the inside (usually same as outside global).
Outside global: The actual destination IP/port on the outside.
For static NAT, you see a line with --- because it's a one-to-one mapping without port translation. For PAT (overload), you see multiple entries with different ports sharing the same inside global IP.
show ip nat statistics – Counters and Pool Health
Router# show ip nat statistics
Total active translations: 3 (1 static, 2 dynamic, 2 extended)
Outside interfaces: GigabitEthernet0/0/0
Inside interfaces: GigabitEthernet0/0/1
Hits: 1524 Misses: 12
Expired translations: 89
Dynamic mappings:
-- Inside Source
[Id: 1] access-list NAT permit 192.168.1.0 0.0.0.255
pool POOL1 (203.0.113.10-203.0.113.20) refcount 2
total addresses: 11, allocated: 2 (18%), missed: 0Hits: Number of successful translations (packets that matched an existing entry).
Misses: Number of packets that required a new translation (first packet of a flow).
Expired translations: Total entries that have timed out.
refcount: Number of active translations using that pool.
missed: Number of times a translation was needed but no pool address was available (NAT exhaustion). This should be 0; if non-zero, you have a problem.
debug ip nat – Real-Time Translation Events
Router# debug ip nat
NAT: s=192.168.1.10->203.0.113.10, d=8.8.8.8 [10]
NAT: s=8.8.8.8, d=203.0.113.10->192.168.1.10 [20]s= source IP, d= destination IP. The arrow shows the translation.
The number in brackets is the packet sequence number (not critical).
The first line shows outbound translation (inside local to inside global).
The second line shows inbound translation (outside global to inside local).
Warning: In production, debug can overwhelm the router's CPU. Use only for targeted troubleshooting and disable with undebug all or no debug ip nat.
Timers and Timeouts
NAT entries are not permanent. They have timers:
Default timeout for dynamic NAT entries: 24 hours (86400 seconds).
Default timeout for PAT (overload) entries:
TCP: 24 hours (86400 seconds) for established flows, but the router uses a 'fast aging' mechanism for TCP that times out after 60 seconds of inactivity (configurable via ip nat translation tcp-timeout).
UDP: 5 minutes (300 seconds) default.
ICMP: 1 minute (60 seconds) default.
Static NAT entries: Never time out (unless explicitly removed).
You can adjust these with:
ip nat translation tcp-timeout 3600
ip nat translation udp-timeout 60
ip nat translation icmp-timeout 30The NAT Flow: Packet Walk
Host 192.168.1.10 sends a packet to 8.8.8.8:80 (TCP SYN).
Router receives on inside interface (G0/0/1). It checks NAT configuration: the packet matches ACL 1 (permit 192.168.1.0 0.0.0.255).
Router checks NAT table: no existing translation, so it creates a new entry. It picks an inside global address from pool POOL1 (say 203.0.113.10) and a random port (5000).
Router rewrites the source IP and port to 203.0.113.10:5000, updates checksums, and forwards out the outside interface (G0/0/0).
The return packet (from 8.8.8.8:80 to 203.0.113.10:5000) arrives on the outside interface.
Router looks up destination 203.0.113.10:5000 in NAT table, finds the corresponding inside local (192.168.1.10:12345), rewrites destination, and forwards to inside.
Subsequent packets in the same flow reuse the existing translation entry. The entry's timer resets with each packet.
After 60 seconds of inactivity (TCP), the entry is removed.
Common Verification Scenarios
Scenario 1: No translation for inside hosts
- Check show ip nat statistics for Misses: if Misses is zero, packets are not hitting the inside interface or not matching the ACL.
- Verify ACL with show access-lists.
- Verify inside/outside interface assignment with show ip nat statistics.
Scenario 2: NAT pool exhausted
- show ip nat statistics shows missed: 5 under the pool.
- Increase pool size or switch to PAT (overload).
Scenario 3: Asymmetric routing
- If return traffic takes a different path, the NAT router may not see the return packet. The entry will time out, causing one-way connectivity. Use show ip nat translations to see if entries are being created but never updated by return traffic.
Interaction with ACLs
NAT works with ACLs to identify traffic to translate. The ACL is evaluated on the inside interface. If the ACL is misconfigured (wrong source IP, wrong direction), NAT will not create translations. Always verify ACL hits with show access-lists.
Summary of Verification Best Practices
Use show ip nat translations to see active translations.
Use show ip nat statistics for hit/miss counts and pool utilization.
Use debug ip nat only when necessary.
Check timers if translations are disappearing too quickly.
Verify ACLs if no translations are being created.
Verify NAT interfaces and direction
First, confirm which interfaces are configured as inside and outside. Use `show ip nat statistics` and look for the lines 'Outside interfaces:' and 'Inside interfaces:'. If an interface is missing, NAT will not process packets on it. Also check the running config with `show running-config | section ip nat` to see the `ip nat inside` and `ip nat outside` commands on the correct interfaces. A common mistake is applying `ip nat inside` to the wrong interface, causing translations to fail silently.
Check the NAT translation table
Run `show ip nat translations` to view all current entries. Look for the expected inside local IP (e.g., 192.168.1.10) and its corresponding inside global IP. If you see an entry with `---` in the Pro column, it's a static translation. For PAT, you should see multiple entries with different ports sharing the same inside global IP. If no entries appear for traffic you expect, there may be an ACL mismatch or the traffic is not reaching the inside interface.
Inspect NAT statistics for misses and errors
Run `show ip nat statistics`. Pay attention to 'Misses' (packets that required a new translation) and 'missed' under the pool (translation failures due to exhaustion). A high 'Misses' count is normal for new flows, but if 'missed' is non-zero, the pool is exhausted. Also note 'Expired translations' – if this number is growing rapidly, check your timeouts. 'Hits' should be high for established flows; if hits are low while misses are high, translations are being created but not reused (possible asymmetric routing).
Verify ACLs matching NAT traffic
NAT uses an ACL to identify which inside traffic to translate. Run `show access-lists` to see the ACL referenced in the NAT configuration. Check the 'matched' counter. If it's zero, no traffic matches the ACL, so NAT will not create translations. Ensure the ACL permits the correct source networks and that it is applied in the correct direction (standard ACL matches source IP). Also verify the ACL is not inadvertently blocking traffic with a deny statement.
Use ping and extended ping to test connectivity
From an inside host, ping a public IP (e.g., 8.8.8.8). While the ping is running, quickly run `show ip nat translations` to see if a temporary translation appears. If it does, NAT is working. If not, check ACL and interface assignments. Use extended ping from the router to simulate traffic: `ping 8.8.8.8 source 192.168.1.1` (if the router has an inside IP). This forces the router to create a NAT entry for its own traffic (if NAT is configured for that source).
Debug NAT for real-time translation events
As a last resort, enable `debug ip nat` on the router. Generate traffic from an inside host. Look for lines like `NAT: s=192.168.1.10->203.0.113.10, d=8.8.8.8`. If no debug output appears, the traffic is not reaching the NAT process, so revisit interface configuration and ACLs. If you see only outbound translations but no inbound, return traffic may be taking a different path. Disable debug immediately with `undebug all` to avoid CPU overload.
In enterprise networks, NAT is ubiquitous for internet access from private IP spaces. A typical scenario: a company with a /24 public block (203.0.113.0/24) and thousands of internal users using RFC 1918 addresses (10.0.0.0/8). The network engineer configures PAT (overload) on the edge router to map all internal traffic to a few public IPs. Verification becomes critical when users report intermittent connectivity. The engineer runs show ip nat statistics and sees 'missed: 15' under the pool, indicating NAT pool exhaustion. The fix is to add more public IPs to the pool or reduce TCP timeouts to free entries faster. Another scenario: a branch office uses static NAT for a mail server (10.1.1.5 to 203.0.113.5). After a router replacement, external users cannot reach the mail server. The engineer checks show ip nat translations and sees no static entry. The configuration is missing the ip nat inside source static 10.1.1.5 203.0.113.5 command. After adding it, the entry appears and connectivity is restored. A third scenario: a data center uses dynamic NAT for outbound web servers. The engineer notices that some external websites are slow. show ip nat statistics shows high 'Misses' but also many 'Expired translations'. The TCP timeout is set to the default 24 hours, causing the NAT table to fill with stale entries. The engineer reduces the TCP timeout to 600 seconds (10 minutes) to free entries faster, improving performance. Misconfiguration can lead to complete loss of connectivity: if the ACL is reversed (deny instead of permit), no traffic is translated. Or if the inside/outside interfaces are swapped, the router may translate return traffic incorrectly, breaking sessions. Always verify with the commands in this chapter before declaring NAT operational.
The CCNA 200-301 exam (Objective 4.1: Configure and verify NAT) tests your ability to interpret NAT verification output. You will not be asked to configure NAT from scratch in a multiple-choice question, but you will see exhibit-based questions showing output from show ip nat translations or show ip nat statistics. You must be able to identify missing translations, pool exhaustion, and incorrect interface assignments. The most common wrong answers: (1) Choosing 'The ACL is blocking traffic' when the real issue is that the inside interface is missing the ip nat inside command. (2) Thinking that a 'missed' count of 0 under the pool means no translations are occurring, when actually it means no translations failed (good). (3) Misinterpreting 'Total active translations: 0' as configuration error, when it could simply be that no traffic has been generated yet. (4) Confusing 'Inside global' with 'Inside local' – the exam will ask which IP is the translated source. Remember: Inside global = public IP seen on the outside. Specific values: default TCP timeout 86400 seconds (24 hours), UDP 300 seconds, ICMP 60 seconds. You may be asked to calculate how many translations a pool of N addresses can support if each uses PAT – the answer is theoretically up to 65535 ports per IP, but the router's memory is the real limit. Decision rule: If you see a NAT verification question, first check if the output shows any translations. If yes, check for high 'missed' counts. If no translations, check ACL and interface configuration. Always eliminate answers that suggest NAT is not configured at all if the output shows statistics.
Use `show ip nat translations` to view the NAT table; inside local is the original private IP, inside global is the translated public IP.
Use `show ip nat statistics` to see hits, misses, expired translations, and pool utilization; a non-zero 'missed' under the pool indicates NAT pool exhaustion.
Default timeouts: TCP 86400 seconds, UDP 300 seconds, ICMP 60 seconds; adjustable with `ip nat translation *-timeout` commands.
Static NAT entries show `---` in the protocol column and never time out.
If no translations appear, verify inside/outside interface configuration with `show ip nat statistics` and ACL matches with `show access-lists`.
`debug ip nat` shows real-time translations; use `undebug all` to disable.
PAT (overload) allows multiple inside hosts to share a single public IP by using unique source ports.
These come up on the exam all the time. Here's how to tell them apart.
Static NAT
One-to-one fixed mapping between inside local and inside global.
No port translation; protocol column shows `---`.
Entry never times out.
Uses one public IP per inside host.
Commonly used for servers that must be reachable from outside.
Dynamic NAT with PAT
Many-to-many or many-to-one mapping using port numbers.
Port translation (PAT) allows multiple hosts to share one public IP.
Entries time out after inactivity (TCP: 86400s, UDP: 300s, ICMP: 60s).
Conserves public IP addresses.
Commonly used for outbound internet access for many users.
Mistake
If `show ip nat statistics` shows 'Total active translations: 0', NAT is not configured.
Correct
Total active translations can be 0 if no traffic has been translated yet, even with correct NAT configuration. The command `show running-config | section ip nat` confirms configuration.
Candidates confuse 'no active translations' with 'no configuration' because they associate zero with failure.
Mistake
The 'Inside local' address is the translated IP seen on the outside.
Correct
Inside local is the original private IP of the host. Inside global is the translated public IP seen on the outside.
The terms 'local' and 'global' are confusing; many swap them.
Mistake
A high 'Misses' count in `show ip nat statistics` indicates a problem.
Correct
Misses count packets that required a new translation (first packet of a flow). A high misses count is normal for many new connections. The 'missed' field under the pool indicates failures.
Candidates think 'miss' means failure, but it's just a counter for new translations.
Mistake
`debug ip nat` is safe to run in production for extended periods.
Correct
`debug ip nat` can overwhelm the router's CPU, especially with high traffic. It should be used only briefly for targeted troubleshooting and disabled immediately.
Debug commands are often misunderstood as lightweight; they are CPU-intensive.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use `show running-config | section ip nat` to see all NAT-related configuration lines, including `ip nat inside`, `ip nat outside`, and `ip nat inside source` commands. Alternatively, `show ip nat statistics` will show the inside and outside interfaces if NAT is configured.
The 'missed' field under a dynamic pool indicates the number of times a translation was needed but no public IP address was available. This is a sign of NAT pool exhaustion. If 'missed' is non-zero, you need to add more addresses to the pool or use PAT (overload) to share addresses.
NAT entries have timeouts. By default, TCP entries time out after 86400 seconds (24 hours) of inactivity, but the router uses a fast aging mechanism that can time out after 60 seconds. UDP entries time out after 300 seconds, and ICMP after 60 seconds. If you see entries disappearing quickly, check your timeout configuration with `show ip nat translations` and adjust with `ip nat translation *-timeout` commands.
Use `debug ip nat` to see translation events as they happen. Each line shows the source and destination IPs before and after translation. Be careful: this debug can be CPU-intensive in production. Always disable it with `undebug all` when done.
Inside local is the IP address of the host as seen from inside the network (usually a private IP like 192.168.1.10). Inside global is the IP address of the host as seen from outside the network (the translated public IP like 203.0.113.10). For PAT, port numbers are also included.
First, verify that the inside and outside interfaces are correctly assigned with `show ip nat statistics`. Then check the ACL used in the NAT configuration with `show access-lists` to see if traffic is matching (look at the 'matched' counter). Also ensure that the inside hosts have a default gateway pointing to the router's inside interface.
Yes, use the `clear ip nat translation *` command to remove all dynamic translations. For specific entries, use `clear ip nat translation inside global-ip global-port local-ip local-port [outside local-ip local-port]`. Static entries cannot be cleared; they must be removed from the configuration.
You've just covered NAT Translation Verification — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?