NAT & PAT Explained — Inside Local, Inside Global, and Overload (CCNA Tutorial)

NAT is not a hard topic. The concept — a router rewriting IP addresses as packets cross it — takes about thirty seconds to understand. What trips people up is the vocabulary: inside local, inside global, outside local, outside global. Four terms that sound interchangeable and aren’t.

So this tutorial does two things: makes the concept click, then nails down the four terms so the exam questions become free points. This is the CCNA-scoped version — for carrier-grade NAT, NAT64, and the deeper edge cases, see the full NAT & PAT library topic.

The one-line idea

The public internet ran out of IPv4 addresses years ago. NAT is the workaround that kept it running.

Organizations use private IP ranges (RFC 1918) internally — addresses the public internet refuses to route:

Range	Typical use
10.0.0.0/8	Large enterprise
172.16.0.0/12	Mid-size networks
192.168.0.0/16	Home + small business

When a private host wants to reach the internet, the NAT router on the edge rewrites the source IP from private to a public address it owns. The reply comes back to that public address; the router checks its translation table and rewrites the destination back to the private IP before forwarding it inside. (If /8 and /12 still look like magic, read Subnetting in your head first — NAT is much easier once CIDR is automatic.)

That’s the whole mechanism. Everything else is detail.

The three flavors

Flavor	Mapping	When you use it
Static NAT	Fixed 1:1 — one private IP always maps to one public IP	An inside server that must be reachable from the internet
Dynamic NAT	A pool of public IPs handed out 1:1, returned when idle	Rare today — you’d need a stack of spare public IPs
PAT (overload)	Many private hosts share one public IP, told apart by source port	The default. Every home router, every branch office

PAT is what you’ll deploy 99% of the time. The exam tests all three, but knowing which one fits a scenario is the skill that matters.

The four terms — the part everyone gets wrong

Two axes. Learn them once and every NAT question becomes mechanical.

• Inside = a host on our network.
• Outside = a host on someone else’s network.
• Local = the address as seen from the inside.
• Global = the address as seen from the outside (the routable internet).

Cross the two axes and you get four combinations:

Term	Plain English	Example
Inside Local	Our host’s private IP, before translation	10.0.0.5
Inside Global	Our host’s public IP, after translation	203.0.113.7
Outside Global	The remote host’s real public IP	8.8.8.8
Outside Local	The remote host as seen from inside (usually = Outside Global)	8.8.8.8

The exam loves this question: “10.0.0.5 becomes 203.0.113.7 while talking to 8.8.8.8. What is the Inside Global address?” Answer: 203.0.113.7.

The mnemonic that makes it automatic:

Inside = our hosts. Local = before translation. Global = after translation.

So “Inside Local” = our host before translation = the private IP. “Inside Global” = our host after translation = the public IP. Draw the arrow 10.0.0.5 → 203.0.113.7 and label the left side Local, the right side Global. You’ll never miss it again.

PAT — what your home router actually does

Right now, every device in your house is sharing one public IP. PAT (Port Address Translation, or NAT Overload) makes that work by adding the source port to the translation:

Inside                         →  Inside Global (shared)        →  Outside
10.0.0.5 : 50000               →  203.0.113.7 : 50000           →  8.8.8.8 : 443
10.0.0.6 : 51000               →  203.0.113.7 : 51000           →  8.8.8.8 : 443
10.0.0.7 : 52000               →  203.0.113.7 : 52000           →  8.8.8.8 : 443

All three conversations leave from the same public IP — the router tells them apart by source port. When two hosts happen to pick the same source port, the router rewrites one of them to keep the pair unique.

One CCNA gotcha worth banking: ICMP has no ports. So when you ping from behind PAT, the router can’t overload on a port — it rewrites the ICMP Query ID instead. Same idea, different field.

The config — the two patterns to memorize

PAT / overload (the everyday config)

! 1. Tag the interfaces
R1(config)# interface Gig0/0
R1(config-if)# ip nat inside
R1(config)# interface Gig0/1
R1(config-if)# ip nat outside

! 2. Pick which inside sources may be translated (an ACL)
R1(config)# ip access-list standard NAT-INSIDE
R1(config-std-nacl)# permit 10.0.0.0 0.0.0.255

! 3. Enable PAT, overloading the outside interface
R1(config)# ip nat inside source list NAT-INSIDE interface Gig0/1 overload

The overload keyword is what makes it PAT instead of plain 1:1 NAT. The ACL decides which inside sources get translated — point it at the wrong subnet and nothing matches (a top-3 mistake).

Static NAT (for an inside server)

! Inside server 10.0.0.50 is reachable from the internet as 203.0.113.50
R1(config)# ip nat inside source static 10.0.0.50 203.0.113.50

This 1:1 mapping is permanent — it sits in the translation table even when no traffic is flowing.

Verify it — the commands that prove NAT works

R1# show ip nat translations
R1# show ip nat statistics

show ip nat translations is the daily driver. Healthy PAT output looks like this:

Pro  Inside global       Inside local      Outside local   Outside global
tcp  203.0.113.7:50000   10.0.0.5:50000    8.8.8.8:443     8.8.8.8:443
tcp  203.0.113.7:51000   10.0.0.6:51000    8.8.8.8:443     8.8.8.8:443
---  203.0.113.50        10.0.0.50         ---             ---

The first two rows are PAT (note the protocol and ports). The last row — protocol ---, no ports — is a static NAT entry: it never times out. That --- is how you spot a static mapping at a glance.

When NAT “isn’t working” — the 6-step check

Nine times out of ten in a CCNA lab, it’s one of these:

1. Interfaces tagged? show ip nat statistics — does it list the correct inside and outside interfaces? You need both.
2. ACL matching? show access-lists — is the hit counter rising? Zero hits means the ACL’s source range is wrong.
3. Translations appearing? show ip nat translations — empty table means the ACL didn’t match or an interface isn’t tagged.
4. overload present? Without it you get 1:1 dynamic NAT, which exhausts fast.
5. Public IP routable back? For static NAT, the upstream must actually route that public address to you.
6. Right subnet in the ACL? The ACL must permit your inside-local (private) sources — not the public side.

Common mistakes (memorize these)

1. Forgetting an interface tag. No ip nat inside and ip nat outside → nothing translates.
2. ACL pointed the wrong way. It must list the private inside sources, not the public addresses.
3. Dropping overload. Without it, dynamic NAT runs out after the pool size.
4. Static NAT to an IP you don’t own. Replies never arrive — usually use the router’s own outside-interface IP.
5. Assuming NAT is security. NAT is address translation, not access control. Always pair it with a real firewall.

Try it yourself

Reading about translation tables is one thing — watching one build is another. Two free, no-login tools:

• NAT / PAT simulator — send packets from inside hosts to the internet, watch R1 rewrite the source IP and port, see the translation table fill in, then watch the reply get untranslated. Flip between PAT, static, and dynamic, and break it on purpose (missing ip nat inside, wrong ACL) to see exactly where traffic dies.
• NAT / PAT “fix the lab” — a partially-configured Packet Tracer file where NAT is broken on purpose. Diagnose it and finish the config.

Do the simulator first to build the mental picture, then the lab to build the muscle memory.

Where NAT goes next (beyond CCNA)

Once the CCNA version is solid, the real-world extensions are: CGNAT (your ISP doing a second layer of NAT, the 100.64.x.x addresses), NAT-T (UDP 4500, how IPsec VPNs survive PAT), and NAT64 (bridging IPv6-only clients to IPv4-only servers). They all live in the full NAT & PAT topic — and they all matter less as IPv6 rolls out, since IPv6 removes the address shortage that NAT exists to patch.

What’s next

• NAT & PAT — full library topic — the complete reference with worked scenarios, debug workflow, and the simulator built in.
• Cisco ACLs explained — because NAT leans on an ACL to choose its sources.
• DHCP and Subnetting — the two topics that make NAT labs feel effortless.

The four terms are the whole battle. Get inside local vs inside global to reflex and the rest of NAT is just two config patterns and a show command. We drill exactly this kind of “make it automatic” repetition — on real gear, with feedback — in the 1:1 CCNA program. First session is free.