Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 43

Troubleshooting NAT with show ip nat translations and debug ip nat

Recommended resources

Welcome to your final lesson on Network Address Translation. In our previous lessons, we've focused on configuring the three main types of NAT: static, dynamic, and PAT. Now, we'll shift our focus to the equally critical skill of troubleshooting. When a user reports they "can't get to the internet," a misconfigured NAT is often the culprit.

This lesson directly addresses your project needs by equipping you with a systematic process for diagnosing and fixing NAT problems. We will move beyond basic verification and dive into using powerful Cisco IOS commands like show ip nat translations and debug ip nat to pinpoint the exact source of a failure.

A Systematic Approach to NAT Troubleshooting

When troubleshooting, it's best to have a structured approach rather than randomly typing commands. A logical workflow for NAT is:

  1. Verify the configuration: Check for typos, incorrect interface assignments, or ACL errors.
  2. Check the translation table: See if translations are being created.
  3. Check NAT statistics: Get a high-level view of translation activity (hits and misses).
  4. Perform real-time debugging: As a last resort, watch the translation process packet by packet.

Let's look at the key commands for each step.

The NAT Troubleshooting Toolkit

You are already familiar with show ip nat translations from our previous lesson. Now let's add two more powerful commands to your toolkit.

  • show ip nat statistics: This command provides a summary of your NAT configuration and performance. The most important counters are Hits and Misses.
    • Hits: A counter that increments each time a translation is successfully found in the NAT table. A rising Hits count means traffic is being translated.
    • Misses: A counter for packets that should have been translated (e.g., they matched the ACL) but for which no translation was available (e.g., the dynamic pool was exhausted).
  • debug ip nat: This command provides a real-time log of every packet the router translates. It shows the source and destination addresses before and after translation. It's incredibly detailed but can overwhelm a router's CPU on a busy network.
This image shows the output of both `show ip nat translations` (top) and `debug ip nat` (bottom). Notice how the debug output explicitly shows the translation from an inside local address (10.1.1.1) to an inside global address (200.1.1.2) with the "NAT:" prefix, and the reverse translation for return traffic with "NAT*:".

A crucial piece of advice for your future work:

Warning: The debug ip nat command can generate a large amount of output on a production network, leading to high CPU utilization. Use it with caution and for short periods during off-peak hours, or use an ACL to limit its output to only the traffic you are interested in. Always remember to turn it off with undebug all or no debug ip nat when you're finished.

For a summary of these commands and a checklist of common issues, you can refer to the document below.

[PDF] The Basics of Configuring and Using Cisco Network Address ...

This guide from Global Knowledge provides a concise overview of NAT troubleshooting.

Focus on two parts: Read the bulleted list under "Troubleshooting NAT/PAT" which introduces the key commands. Review the checklist under "Translation Occurring: Installed Translation Entry but No Connectivity". This highlights that even if NAT is working, routing issues can still prevent connectivity.

Practical Troubleshooting Lab

The best way to learn troubleshooting is to see it in action. The following video lab walks through a Packet Tracer activity where you must find and fix several common NAT configuration errors for both static and dynamic NAT.

9.3.1.5 Lab - Troubleshooting NAT Configurations

This video from Tech Acad, "Lab - Troubleshooting NAT Configurations," is a step-by-step guide to solving realistic NAT problems.

Follow the two troubleshooting scenarios presented: Static NAT: Watch from the first scenario. Pay close attention to how the presenter uses show running-config and show ip nat statistics to identify an incorrect static IP mapping and wrongly configured ip nat inside/outside interfaces. Dynamic NAT: Continue from the second scenario. Notice the errors found here: a typo in the NAT pool name within the ip nat inside source command and an incorrect network address in the ACL.

The video demonstrates a critical troubleshooting lesson: if debug ip nat shows no output when you send traffic, it's a strong clue that the packet isn't matching your NAT rules in the first place. This directs your attention immediately to the configuration itself—specifically, the NAT interfaces and the ACL.

When NAT is Working, But Connectivity Fails

The lab video focused on configuration errors on the NAT router. But what happens if your show ip nat translations and debug ip nat outputs show that translation is occurring perfectly, yet the ping still fails?

This often points to a routing problem.

Consider this sequence of events:

  1. PC-A (10.0.0.5) sends a packet to an external Server (209.165.200.226).
  2. Your NAT router correctly translates the source IP to 203.0.113.5 and forwards the packet.
  3. The Server receives the packet and attempts to send a reply to the destination IP 203.0.113.5.

The problem occurs if the Server (or any router between it and your NAT router) does not have a route to the 203.0.113.0 network. The reply packet will be dropped, and from PC-A's perspective, the connection simply times out.

Similarly, once the reply packet gets back to your NAT router, the router must have a route to the original internal host (10.0.0.5) to deliver the de-translated packet.

The Cisco document below provides a detailed example of this exact issue.

Verify and Troubleshoot Basic NAT Connectivity - Cisco

This official Cisco support document walks through two advanced troubleshooting scenarios. We will focus on the logic rather than every command.

Skim the first scenario, "Ping One Router but not Another Router." The key takeaway is in the Troubleshooting steps. The engineer sees NAT "Hits" increasing but the ping fails. This leads them to check the routing table on the destination router (Router7), where they find a missing route for the translated address. Skim the second scenario, "Outside Network Devices Cannot Communicate with Inside Routers." Here, the final problem is that the NAT router itself is missing a route back to the internal source network after it de-translates the return packet.

This highlights a golden rule of network troubleshooting: always consider the entire path, not just one device.

Conclusion

You have now completed the NAT module, progressing from basic concepts to advanced configuration and, finally, to systematic troubleshooting. You have the knowledge to implement and manage one of the most fundamental technologies in modern networking.

Key Takeaways:

  • Troubleshooting Commands: Your primary tools are show ip nat translations, show ip nat statistics, and debug ip nat. Use them to verify configurations, check for active translations, and observe real-time packet processing.
  • Common Configuration Errors: Be vigilant for typos in ACLs and NAT pools, incorrect IP addresses in static mappings, and, most frequently, incorrectly assigned ip nat inside and ip nat outside interfaces.
  • Look Beyond NAT: If NAT appears to be working correctly but connectivity still fails, the problem is likely related to routing. Ensure that remote networks have a route back to your inside global (public) addresses and that your NAT router has a route to your inside local (private) hosts.

With these skills, you are well-prepared to handle the NAT portion of your project. In our next session, we will begin a new module on essential IP services, starting with the DHCP protocol, which automates the IP address assignment process for hosts on your network.