NAT Troubleshooting with Show and Debug Commands

Welcome back! In our last lesson, we configured Port Address Translation (PAT), the workhorse of NAT that allows many internal devices to share a single public IP. You learned to use the show ip nat translations command to verify that these many-to-one mappings were being created correctly.

However, in the real world, configurations don't always work on the first try. This lesson is dedicated to the crucial skill of troubleshooting. You will learn how to troubleshoot NAT translation issues using show and debug commands. We'll move from simply verifying a working configuration to systematically diagnosing and fixing a broken one. By the end of this lesson, you'll have a structured approach to pinpointing common NAT errors, from simple typos to more complex routing problems.

1. A Systematic Approach to NAT Troubleshooting

When faced with a connectivity issue in a NAT environment, it's easy to get lost. A structured approach is essential. The key is to follow the packet's journey and verify each step. We can break this down into a four-step methodology.

1. Verify the Configuration: Is the NAT configuration itself correct? Use show running-config to check for typos or logical errors in your NAT statements, access lists, and pool definitions. Are the ip nat inside and ip nat outside commands on the correct interfaces?
2. Verify the Translation Table: Is the router creating the NAT entries you expect? The show ip nat translations command will show if a static entry exists or if a dynamic entry has been created in response to traffic.
3. Verify Real-Time Translation: Are packets actually being translated as they pass through the router? The show ip nat statistics command gives you a summary of hits (successful translations) and misses. For a real-time view, the powerful debug ip nat command shows every translation as it happens.
4. Verify Routing: This is often the most overlooked step. NAT can be configured perfectly, but traffic will fail if the routing is broken.
   • Can the NAT router reach the external destination?
   • Can the external destination route back to the router's public IP address?
   • Can the NAT router route the return packet back to the original internal host?

To learn more about this troubleshooting framework, you can review the introductory sections of the following Cisco support document.

2. Key Troubleshooting Commands

Let's dive into the primary commands you'll use to diagnose NAT issues. You are already familiar with show ip nat translations from our previous lesson for verification, but let's see how it and other commands are used specifically for troubleshooting.

show ip nat statistics

This command provides a summary of NAT activity. The most important counters are:

• Hits: The number of times a packet was successfully translated using an existing entry in the NAT table. A rising number of hits indicates that NAT is actively translating traffic.
• Misses: The number of times a packet should have been translated (e.g., it matched the ACL) but a new translation could not be created. This might happen if a dynamic NAT pool is out of addresses.
• Inside/Outside interfaces: This quickly confirms which interfaces the router considers to be part of the inside and outside NAT zones.

debug ip nat

This is your most powerful tool for seeing what the router is doing in real time. When you enable this debug and a packet is translated, the router will print log messages to the console.

A typical debug entry for an outbound packet looks like this:
NAT: s=192.168.1.10 -> 209.165.200.226, d=8.8.8.8 [10]

• s=192.168.1.10->209.165.200.226: The source address is being translated from the private IP to the public IP.
• d=8.8.8.8: The destination remains unchanged.
• [10]: This is an internal ID for the session.

For the return packet, you'll see the reverse:
NAT*: s=8.8.8.8, d=209.165.200.226 -> 192.168.1.10 [10]

Important: The debug command can be very CPU-intensive. On a busy production router, it can generate a huge amount of output and impact performance. Use it carefully and always remember to turn it off with the undebug all or no debug ip nat command when you are finished.

3. Case Study 1: Configuration Errors

Let's apply these commands to a common scenario: a misconfigured router. The following video walks through a lab where a static NAT configuration is broken. Pay close attention to how the troubleshooter uses the commands we just discussed to isolate and fix the errors one by one.

This walkthrough demonstrates a key principle: troubleshooting is an iterative process of testing, observing, and correcting.

4. Case Study 2: Routing Issues

Sometimes, the NAT configuration is perfect, but connectivity still fails. In many of these cases, the root cause is a routing problem. Remember, for a connection to work, traffic must be able to get from the source to the destination and back again.

• Outbound Path: Does the NAT router have a route (usually a default route) to reach the external destination?
• Return Path: Does the external network have a route back to the public IP address used in the translation? Once the packet returns to the NAT router, does it have a specific route to the original internal host?

The next video provides an excellent example of a routing problem masquerading as a NAT problem.

This case highlights the importance of looking at the entire network path. Don't assume the problem is with NAT just because NAT is involved. Always verify basic IP connectivity and routing.

The Cisco document you looked at earlier ("Verify and Troubleshoot Basic NAT Connectivity") also contains two detailed scenarios where routing is the culprit. In one, the external router is missing a route back. In the other, the NAT router itself is missing a route to an internal network. These examples further reinforce that checking show ip route on all relevant devices is a critical troubleshooting step.

Conclusion

In this lesson, you've developed a systematic approach to diagnosing and resolving NAT issues. You've seen that problems can stem from simple configuration mistakes or from more complex underlying routing failures.

Key Takeaways:

• Follow a Method: A structured, four-step approach (Verify Config, Verify Translations, Verify Real-Time, Verify Routing) will help you solve problems efficiently.
• Master the Commands: The core troubleshooting toolkit includes show running-config, show ip nat translations, show ip nat statistics, debug ip nat, and show ip route.
• Think Beyond NAT: Many "NAT problems" are actually routing problems in disguise. Always verify that a valid route exists for traffic in both directions.
• debug with Caution: While debug ip nat provides invaluable real-time insight, it should be used carefully on production networks to avoid performance degradation.

This lesson concludes our module on NAT. You are now equipped to configure static NAT, PAT, and troubleshoot issues when they arise. In our next module, we will shift our focus to essential network services, starting with how to configure a router to function as a DHCP server to automate IP address assignment for hosts on your network.