Guide

How to Configure NAT Overload (PAT) on Cisco (Step by Step)

NAT overload — usually just called PAT — is how almost every small network gets to the internet: dozens or hundreds of inside hosts share one public IP address, and the router keeps their sessions apart using port numbers instead of separate addresses. If you've ever wondered how a home router with one WAN IP serves every device in the house, this is the mechanism. It's a required CCNA topic and one of the most common configs you'll actually run in production.

Step 1 — Mark the inside and outside interfaces

NAT needs to know which side of the router is the private network and which side faces the internet (or upstream ISP). Apply ip nat inside on the LAN-facing interface and ip nat outside on the interface that connects out — everything else about the config hangs off this distinction.

This step is easy to skip and easy to forget, but without it the router has no idea which traffic is even eligible for translation.

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip nat inside
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip nat outside

Step 2 — Define which inside addresses get translated

Next, tell NAT which source addresses are allowed to be translated. A standard ACL does this — it isn't filtering traffic here, just identifying the inside-local addresses that qualify.

Match the ACL to your actual inside subnet. If it's wrong or missing entries, hosts outside the matched range simply won't get translated and won't reach the internet.

R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255

Step 3 — Create the overload rule and verify

This is where PAT actually happens. Bind the ACL to the outside interface's address and add the overload keyword — that's what turns plain dynamic NAT (one-to-one, limited by how many public IPs you have) into port-based overload, where every inside host can share that single outside IP at once.

Generate some traffic from an inside host (a ping or a web request works), then check the translation table and stats to confirm it's working. You'll see each inside-local address paired with a port number under the single inside-global IP.

Reading this off a diagram is one thing — typing it into a real router and having your config checked against an answer key is what actually makes it stick, which is the whole idea behind Goldfish Networks' daily labs.

R1(config)# ip nat inside source list 1 interface gigabitethernet0/1 overload
R1# show ip nat translations
R1# show ip nat statistics

A complete worked example: from empty table to verified translations

Concrete addresses make PAT click faster than any diagram. Picture R1 with GigabitEthernet0/0 as the LAN gateway at 192.168.1.1/24 and GigabitEthernet0/1 facing the ISP at 203.0.113.2/30. Two inside hosts, 192.168.1.10 and 192.168.1.11, both open web sessions to a server at 198.51.100.20. After tagging the interfaces, matching the inside subnet with a standard ACL, and adding the overload rule, one browse from each host populates the table.

The payoff is learning to read 'show ip nat translations', which has four columns that trip up almost everyone at first. Inside local is the real private source (192.168.1.10). Inside global is what the internet actually sees after translation (203.0.113.2). Outside local and outside global describe the destination, and here they match because the far-end address is not being translated. Notice both inside hosts share the single inside-global 203.0.113.2 but keep distinct port numbers, which is the entire trick of overload.

Cross-check with 'show ip nat statistics'. It confirms which interfaces are flagged inside and outside, names the ACL and interface driving the rule, and shows a rising hit count as traffic flows. If that hit count stays at zero while you are clearly generating traffic, the problem is upstream of NAT, usually routing or the interface tags, not the overload rule itself.

R1(config)# interface gigabitethernet0/0
R1(config-if)#  ip address 192.168.1.1 255.255.255.0
R1(config-if)#  ip nat inside
R1(config-if)# interface gigabitethernet0/1
R1(config-if)#  ip address 203.0.113.2 255.255.255.252
R1(config-if)#  ip nat outside
R1(config-if)# exit
R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255
R1(config)# ip nat inside source list 1 interface gigabitethernet0/1 overload
R1(config)# end

R1# show ip nat translations
Pro  Inside global      Inside local       Outside local      Outside global
tcp  203.0.113.2:1043   192.168.1.10:1043  198.51.100.20:80   198.51.100.20:80
tcp  203.0.113.2:1044   192.168.1.11:1044  198.51.100.20:80   198.51.100.20:80
icmp 203.0.113.2:9      192.168.1.10:9     8.8.8.8:9          8.8.8.8:9

R1# show ip nat statistics
Total active translations: 3 (0 static, 3 dynamic; 3 extended)
Outside interfaces: GigabitEthernet0/1
Inside interfaces:  GigabitEthernet0/0
Hits: altogether rising as traffic flows; Misses: 0
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 1 interface GigabitEthernet0/1 refcount 3

Why one public address is enough: port multiplexing under the hood

Plain dynamic NAT is one-to-one, so with a single outside IP the second host to connect would find no free address and fail. The overload keyword changes the key the router uses to keep sessions apart. Instead of one translation per host, the router builds one translation per unique session and identifies each by a combination of inside-global IP, protocol, and Layer 4 port. Because the port field alone gives roughly 64,000 values per protocol, a single address can distinguish far more sessions than any small network will ever run at once.

The router is not random about port assignment. When an inside host sends outbound, PAT first tries to keep the original source port unchanged so the entry reads cleanly, and only when that exact inside-global-IP-and-port pair is already in use does it pick a substitute from its port range and record the swap in the table. That is why you sometimes see the inside-local and inside-global ports match on one flow and differ on another. The far end always replies to the inside-global address and port, and the translation table tells the router exactly which private host and port to hand the packet back to.

Protocols without ports still work because PAT improvises a substitute identifier. ICMP has no port field, so the router overloads the ICMP query identifier instead, which is why ping entries appear in the table with a small number in the port column. This session-level bookkeeping is also the ceiling on scale: you are limited by concurrent sessions and available ports, not by host count, which is exactly when moving from a single interface address to a NAT pool with overload buys you headroom.

Common problems (and the fix)

Nothing translates at all: almost always a missing ip nat inside or ip nat outside on one of the interfaces. Check show ip nat statistics — it lists the interfaces NAT currently sees as inside/outside, so a missing entry there is the tell.

Some hosts translate, others don't: the ACL doesn't cover the full inside subnet, or you're matching the wrong subnet entirely. Compare the ACL's network/wildcard against the actual host addresses.

Translations stop working after a handful of sessions: you forgot the overload keyword, so the router is doing one-to-one dynamic NAT and ran out of spare outside addresses — overload is what enables port multiplexing so one address is enough.

show ip nat translations comes back empty right after configuring: that's expected. Entries are built dynamically from real traffic, so nothing shows up until an inside host actually sends something outbound.

Frequently asked questions

What's the difference between NAT overload (PAT) and port forwarding?

They are essentially opposite directions of the same idea. NAT overload dynamically translates many inside hosts to one outside IP for sessions those hosts initiate outbound, while port forwarding (static PAT) is a fixed rule that lets unsolicited inbound traffic hitting a specific outside port reach a chosen inside host. You configure the inbound case with something like 'ip nat inside source static tcp 192.168.1.10 80 interface gigabitethernet0/1 80'.

When should I bind the ACL to the interface versus using a NAT pool with overload?

Use the interface form ('...source list 1 interface g0/1 overload') when you have a single outside IP, especially a DHCP-assigned one from the ISP, because it always tracks whatever address currently sits on that interface. Use a NAT pool with the overload keyword when you own a small block of public addresses and want the router to spread translations across several IPs before it starts multiplexing ports. Both still do port overloading; the pool just supplies more inside-global addresses to draw from.

How many inside hosts can realistically share one public IP with PAT?

In theory a single IP has roughly 64,000 usable ports per protocol, so it can back tens of thousands of concurrent TCP and UDP sessions. What actually matters is the number of simultaneous sessions, not hosts, since each device opens many sockets at once, so you typically support hundreds of busy hosts per public IP before port pressure pushes you toward a pool. Uniqueness is enforced per inside-global IP, protocol, and port, and Cisco PAT tries to preserve the original source port and only rewrites it on a collision.

How do I clear or refresh the NAT translation table while testing?

Run 'clear ip nat translation *' to wipe all dynamic entries and start from a clean table between tests. Otherwise entries linger until their idle timers expire, which default to 24 hours for TCP and about 5 minutes for UDP, so a stale entry can hide a change you just made. You can adjust these with 'ip nat translation timeout'.

Why do apps like FTP or VoIP break through PAT even when web browsing works?

PAT rewrites the IP header and Layer 4 ports, but some protocols also embed IP addresses or port numbers inside the packet payload, such as FTP active mode, SIP, and PPTP. When the far end reads that embedded private address it cannot reply correctly, so the application fails even though HTTP works fine. IOS fixes many common cases with a NAT ALG (application-layer gateway), but coverage is not universal, which is why passive-mode FTP and NAT-aware VoIP settings often matter.

Practice this on graded Cisco labs

Reading is step one — build NAT & PAT on real Cisco IOS and grade your own config, or try a free sample lab first.