NAT Overload Causing Internet Access Failure

NAT OVERLOAD

I once had a small office setup where users suddenly lost internet access. The router was up, local traffic worked fine, but anything beyond the LAN was dead. At first glance, it looked like the ISP was down, but digging deeper revealed the real culprit: a misconfigured NAT overload (PAT).

🔍 How I Diagnosed It

I started with the basics:

• show ip interface brief → confirmed all interfaces were up.

• ping 8.8.8.8 from the router worked, but not from internal hosts.

• show ip nat translations → came back empty.

That was the red flag. NAT wasn’t translating internal IPs to the public IP. Without translations, users couldn’t reach the internet.

✅ How I Fixed It

1. Defined the ACL for internal traffic:

   Code

   access-list 1 permit 192.168.1.0 0.0.0.255
   

2. Configured NAT overload:

   Code

   ip nat inside source list 1 interface GigabitEthernet0/0 overload
   

3. Set interface roles:

   Code

   interface GigabitEthernet0/1
     ip nat inside
   interface GigabitEthernet0/0
     ip nat outside
   

4. Verified NAT translations:

   Code

   show ip nat translations
   

Once this was in place, NAT entries started populating, and users could access the internet again.

📌 Why This Is Important

This issue looks simple but happens a lot—especially when configs are copied from one router to another or after a reset. NAT isn’t plug-and-play; it needs precise alignment between ACLs, inside/outside interface roles, and overload rules.

For me, the lesson was: always check NAT translations early when internet access breaks. If the router itself can ping out but users can’t, it’s almost always NAT misconfiguration. Fixing it quickly restores productivity and avoids unnecessary ISP blame.