Back to Learning
CCNA · 200-301Beginner

NAT Overload: A Perfect Mapping That Never Translates

A flawless NAT overload configuration that translates nothing. Diagnose the missing inside interface and fix it yourself, live, right below.

Interactive simRoutingNATPAT

Symptom

A standard ACL and a correct PAT overload rule are already present. Find the missing interface role that leaves every LAN flow untranslated, then repair it in a live Cisco-style shell.

Your mission

Prove the cause, then fix it

Format

Guided CLI investigation

NAT Overload: A Perfect Mapping That Never Translates

Investigate before you configure.

Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.

Observe the symptom and link state.

Diagnose by comparing the protocol evidence.

Verify the expected device state and confirm the original symptom is resolved.

Console access: R1

This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.

Need a hint?

Reveal the root cause when you're ready.

Try the investigation first, then use this as your escape hatch, not a dead end.

Locked

Sign up with your email to open NAT Overload: A Perfect Mapping That Never Translates, free. You get the root cause and the full step-by-step fix.

No spam. The fix lands in your inbox too. Signing up includes 4 guided labs free, tracked against your email. After that, the Learning Pass unlocks every remaining lab.

Lab debrief

Turn the session into a repeatable troubleshooting pattern.

Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.

The problem

R1 connects the private LAN 192.168.1.0/24 to an ISP through GigabitEthernet0/1 at 203.0.113.2/30. The ACL and PAT mapping are present, and GigabitEthernet0/1 is outside. A host at 192.168.1.10 cannot ping 8.8.8.8 because GigabitEthernet0/0 has not been marked inside.

What you'll practice

  • Read NAT statistics and recognise an empty Inside interfaces list
  • Trace a sourced flow from 192.168.1.10 through R1 to 8.8.8.8
  • Distinguish the ACL and overload mapping from the interface roles that activate NAT
  • Apply ip nat inside to the LAN-facing GigabitEthernet0/0 and verify the PAT translation

1. What the mapping does, and what it does not do

The standard ACL selects 192.168.1.0 with wildcard 0.0.0.255, while the overload rule selects GigabitEthernet0/1 as the public address source. Those statements describe the translation policy, but they do not classify an interface as the private side of the boundary.

2. Why an empty interface list beats a perfect-looking rule

show ip nat statistics reports the interfaces that IOS can use for translation. When Outside interfaces lists GigabitEthernet0/1 but Inside interfaces is empty, the NAT policy has no valid entry point for the LAN traffic. The zero-row translation table and failed sourced ping confirm the same fault from two other angles.

3. How PAT becomes visible after the repair

Once GigabitEthernet0/0 is inside, traffic from 192.168.1.10 matches ACL 1 and can be overloaded onto 203.0.113.2. The sourced ping succeeds, and show ip nat translations displays the ICMP flow with the translated address and port.

The topology

R1 sits between a private LAN and an ISP. The LAN host 192.168.1.10 reaches R1 on GigabitEthernet0/0 at 192.168.1.1/24. R1 reaches the ISP on GigabitEthernet0/1 at 203.0.113.2/30. ACL 1 selects 192.168.1.0 0.0.0.255, and the overload mapping uses GigabitEthernet0/1.

Commands to run yourself

The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.

Inspect the NAT boundary and counters
show ip nat statistics
Check whether a PAT row exists
show ip nat translations
Test the LAN source end to end
ping 8.8.8.8 source 192.168.1.10

Topology diagram

Frequently asked

Why does the correct overload rule create no translation?

The rule selects ACL 1 and GigabitEthernet0/1, but NAT also needs an inside interface. GigabitEthernet0/0 is the LAN-facing interface and is missing ip nat inside, so the sourced packet never enters the translation process.

What should I look for in show ip nat statistics?

Before the repair, Outside interfaces lists GigabitEthernet0/1 and Inside interfaces is empty. The same output begins with Total active translations: 0 (0 static, 0 dynamic; 0 extended). That combination points to the boundary, not the ACL or mapping.

Why is marking both interfaces outside not a fix?

Inside and outside describe each interface's position relative to the translation boundary. If both interfaces are outside, there is still no inside interface, so NAT cannot translate the LAN flow. The simulator also reports two outside interfaces in its statistics.

Ready to run this lab yourself?

No setup, no image sourcing. Book a session or ask for a live demo.