Updated 10 hours ago
Network Address Translation (NAT) broke the Internet's founding promise.
The original Internet was symmetric: every device could both initiate and accept connections. Any machine could be a client or a server or both. NAT changed that. It turned most of the Internet into clients—devices that can speak but cannot listen, that can request but cannot serve.
This matters because NAT is everywhere. It sits between nearly every home network and the Internet. It hides inside corporate firewalls. It runs at massive scale inside ISP networks. Understanding NAT means understanding why peer-to-peer applications struggle, why running a home server requires special configuration, and why we've built entire protocol suites just to punch holes through it.
The Problem NAT Solves
IPv4 provides approximately 4.3 billion addresses. That seemed abundant in the 1980s, but we now have more Internet-connected devices than addresses to give them.
NAT solves this by letting multiple devices share a single public IP address. A typical home network might have dozens of devices—phones, laptops, smart TVs, thermostats—all using private addresses like 192.168.1.x. These private addresses can be reused by any network in the world because they never appear on the public Internet. A single NAT device at the network edge translates between private and public addresses.
The hack worked so well that IPv6, which provides enough addresses for every grain of sand on Earth to have trillions of IPs, still hasn't replaced IPv4 three decades after its design.
How Translation Works
When a packet leaves your network, NAT intercepts it and rewrites the source address. Your device thinks it's sending from 192.168.1.10, but the Internet sees the packet coming from your router's public IP.
Basic NAT (one-to-one) maps each internal IP to a unique external IP. This solves routing but not scarcity—you still need one public address per device.
Port Address Translation (PAT) is what actually runs in the wild. It lets thousands of devices share a single public IP by using port numbers as identifiers.
Suppose three devices all browse the web through a router with public IP 203.0.113.5:
The router maintains this mapping table. When a response arrives at 203.0.113.5:50002, the router knows to forward it to 192.168.1.11:50000. Each connection gets a unique external port, so the router can route replies correctly even though everyone shares the same IP.
The port space gives you roughly 65,000 possible mappings per public IP—enough for a household, enough for a small office, not enough for an ISP serving thousands of customers (which is why Carrier-Grade NAT gets complicated).
Protocol-Specific Translation
NAT must handle different protocols differently:
TCP and UDP have port numbers, so translation is straightforward. NAT rewrites addresses and ports, tracks connection state, and cleans up mappings when connections close or time out.
ICMP has no ports. NAT uses the ICMP identifier field (present in ping requests and replies) to distinguish between sources. This is why multiple devices can ping the same host simultaneously.
GRE, IPsec ESP, and other protocols lack port numbers or similar identifiers. NAT either can't handle them at all, or requires protocol-specific extensions like NAT-T for IPsec.
The Four NAT Behaviors
Not all NAT implementations behave identically. The differences determine what can traverse them:
Full Cone NAT creates a mapping that accepts packets from anyone. Once 192.168.1.10:50000 maps to 203.0.113.5:50001, any host on the Internet can send to that external address and reach the internal device. Most permissive.
Restricted Cone NAT only accepts packets from IPs the internal device has contacted. If you've sent packets to 8.8.8.8, then 8.8.8.8 can send back to your mapping—but 1.1.1.1 cannot.
Port Restricted Cone NAT only accepts packets from specific IP:port pairs you've contacted. If you sent to 8.8.8.8:53, only 8.8.8.8:53 can respond. 8.8.8.8:80 is blocked.
Symmetric NAT creates different mappings for different destinations. Talking to server A might use external port 50001; talking to server B uses 50002—even from the same internal port. This breaks most NAT traversal techniques because the mapping you discover via one server won't work for connecting to another.
Symmetric NAT is the most common in enterprise environments and the hardest to traverse. It's why peer-to-peer video calls sometimes fail in corporate networks.
Why Incoming Connections Break
NAT creates fundamental asymmetry: outbound connections work trivially, but inbound connections have nowhere to go.
When you initiate a connection, NAT creates a mapping and routes replies back through it. But when someone on the Internet tries to connect to your router's public IP, the router has no mapping—no way to know which internal device should receive the packet. The connection fails.
This is why you can browse any website but can't run a web server without extra configuration. NAT turned the Internet into a place where devices consume but don't produce.
Port forwarding solves this by manually configuring the router: "Send anything arriving on port 80 to 192.168.1.10." But this requires configuration access and knowledge.
UPnP and NAT-PMP let devices request port forwarding automatically. Your game console asks the router to forward a port, and the router complies. Convenient but has security implications—any software can punch holes in your NAT.
Punching Through NAT
Peer-to-peer applications need both sides to be reachable, but both sides might be behind NAT. An entire ecosystem of protocols exists to solve this:
STUN (Session Traversal Utilities for NAT) helps you discover your public IP and port. Your device contacts a STUN server, which tells you what address it sees packets coming from. Now you know your external mapping and can share it with peers.
Hole punching exploits the fact that NAT mappings allow return traffic. If Alice and Bob both send packets to each other's discovered external addresses simultaneously, both NATs create outbound mappings. The packets might cross in flight, but now both NATs have mappings that allow the peer's traffic through. Connection established.
Hole punching fails with symmetric NAT because the mapping discovered via STUN differs from the mapping created when contacting the peer.
TURN (Traversal Using Relays around NAT) is the fallback. A relay server accepts connections from both peers and forwards traffic between them. It always works but adds latency and requires relay infrastructure.
ICE (Interactive Connectivity Establishment) systematically tries everything: direct connection, STUN-assisted hole punching, TURN relay. It finds the best path that actually works. WebRTC uses ICE, which is why video calls usually succeed even through difficult NATs.
Connection Tracking and Timeouts
NAT maintains a table mapping internal to external addresses. This table has limits that affect real applications.
Size limits: Consumer routers might track a few thousand connections. Enterprise NAT can handle millions. Exceed the limit and new connections fail.
Timeouts: TCP mappings persist while the connection is open plus some time after closure. UDP mappings (no connection state to track) might timeout after 30–300 seconds of inactivity. ICMP mappings often timeout in seconds.
These timeouts break idle connections. A mobile app maintaining a persistent connection to its server might find the NAT mapping expired after the phone sat idle for a few minutes. The server sends a packet; the NAT has no mapping; the packet is dropped.
Keepalives solve this by sending periodic traffic to refresh the mapping. TCP keepalives, application-level heartbeats, or NAT-specific keepalive packets all serve this purpose. The cost: more traffic, more battery drain on mobile devices.
Application Layer Gateways
Some protocols embed IP addresses in their payload, not just their headers. NAT translates headers but not payloads. These protocols break.
FTP sends PORT commands containing IP addresses for data connections. A NAT device that understands FTP (an "Application Layer Gateway" or ALG) rewrites these embedded addresses. Without the ALG, FTP fails.
SIP for VoIP embeds addresses in multiple message fields. SIP ALGs attempt to rewrite them, but SIP implementations vary enough that ALGs often cause more problems than they solve. Many VoIP administrators specifically disable SIP ALGs.
Modern protocols like HTTP avoid embedding addresses in payloads. This is partly why HTTP won: it works through NAT without special handling.
Carrier-Grade NAT
As IPv4 addresses grew scarcer, ISPs started deploying NAT at scale. This Carrier-Grade NAT (CGN) puts customers behind NAT before they even reach the ISP's public addresses.
Your home router might receive 100.64.0.5 (from the shared address space reserved for CGN), which it NATs to your private 192.168.x.x addresses. The ISP then NATs 100.64.0.5 to a public IP shared among potentially thousands of customers.
This is NAT behind NAT. The problems compound: port forwarding is impossible (your router can't configure the ISP's NAT), STUN hole punching fails more often, and the "public" IP visible to websites is shared by strangers. When one customer gets that IP banned from a service, everyone sharing it suffers.
CGN is why some gamers pay for "static IP" service—they're actually paying to escape CGN.
NAT and IPv6
IPv6 provides 340 undecillion addresses—enough that NAT for address conservation is unnecessary. Every device can have globally unique addresses, restoring the Internet's original peer-to-peer architecture.
And yet NAT66 (IPv6 NAT) exists. Some operators deploy it because they've built processes around NAT's topology hiding, because their security policies assume NAT, or simply out of familiarity.
This is controversial. NAT66 reintroduces all of NAT's problems into a protocol designed to eliminate them. Most IPv6 deployments prefer stateful firewalls: allow outbound, block unsolicited inbound, no address translation required.
Security: Real and Imagined
NAT is often credited as a security feature. The reality is more nuanced.
NAT does block unsolicited inbound connections by default. It does hide internal network topology. For many home networks, this incidental protection is the only thing between internal devices and the Internet.
But NAT is not a firewall. It doesn't inspect traffic. It doesn't make intelligent allow/block decisions. It doesn't prevent malware that phones home (outbound connections work fine). And it complicates security monitoring because multiple internal devices share one external IP, making it harder to correlate external observations with specific internal machines.
The Persistence of a Temporary Fix
NAT was designed as a temporary hack to extend IPv4's life until IPv6 took over. That was the 1990s. We're still here.
IPv6 deployment has accelerated—major mobile carriers and content providers now handle majority IPv6 traffic—but the installed base of IPv4-only devices, networks, and operational practices ensures NAT will persist for years.
Meanwhile, we've built STUN servers and TURN relays and ICE negotiation and hole-punching algorithms. We've created an entire industry of workarounds for a problem we already solved with IPv6 but couldn't deploy fast enough.
NAT turned the Internet from a network of peers into a network of clients. Every device could talk, but most could no longer listen. Understanding NAT means understanding why that happened, how the translation works, and how protocols evolved to punch through the walls we built.
Frequently Asked Questions About NAT
Was this page helpful?