NAT

Definition: Network Address Translation (NAT) rewrites the source (or destination) IP address, and usually port, of packets as they cross a router boundary, most commonly to let many private-network hosts share a single public IP address.

How It Works

The dominant form is NAPT (Network Address and Port Translation), often just called “NAT” or “PAT” colloquially. A home or office router sits between a private network (e.g. 192.168.1.0/24) and the public internet with one public IP.

An internal host, 192.168.1.10:51000, sends a packet to 93.184.216.34:443.
The router rewrites the source address/port to its own public IP and a router-chosen port, e.g. 203.0.113.5:40001, and forwards the packet.
The router records the mapping (192.168.1.10:51000) <-> (203.0.113.5:40001) in its NAT translation table, keyed also by the destination.
The reply arrives addressed to 203.0.113.5:40001. The router looks up the table, rewrites the destination back to 192.168.1.10:51000, and forwards it inward.
Entries expire after a period of inactivity (TCP sessions tracked via SYN/FIN/RST, UDP tracked purely by idle timeout since it’s stateless).

Because the table is keyed by the full 4-tuple (plus protocol), thousands of internal hosts can share one public IP simultaneously, each distinguished by the router-assigned port. A simplified translation table mid-session might look like:

Protocol	Internal	External	Destination
TCP	192.168.1.10:51000	203.0.113.5:40001	93.184.216.34:443
TCP	192.168.1.12:52210	203.0.113.5:40002	142.250.72.14:443
UDP	192.168.1.15:60110	203.0.113.5:40003	8.8.8.8:53

Each row is an independent mapping even though two entries share the same external IP, the router-assigned external port is what keeps them distinct, and it’s exactly this table the router consults on every inbound packet to know which internal host to deliver it to.

Under the Hood

NAT variants differ in how permissive they are about who can send to a mapped port, which matters enormously for P2P and gaming:

Type	Behavior
Full Cone	Once mapped, any external host can send to the public IP:port and it reaches the internal host
Restricted Cone	Only external hosts the internal host has previously sent to, on any port, can reach it back
Port-Restricted Cone	Same as restricted, but must match the exact port too
Symmetric	A new mapping is created per unique destination, external hosts other than the original destination can’t reach it at all

Symmetric NAT is the hardest to traverse and breaks most naive P2P connection attempts, which is why STUN/TURN/ICE exist.

Destination NAT (DNAT), aka port forwarding, works in the opposite direction: an external request to the router’s public IP on a specific port gets its destination rewritten to an internal host, used to expose an internal server (e.g. a home web server) to the internet.

Carrier-Grade NAT (CGNAT) is NAT applied by the ISP itself, on top of customer-side NAT, because the ISP has run out of public IPv4 addresses to give every customer. This means a household’s “public” IP is often actually another private-ish address (from 100.64.0.0/10, reserved by RFC 6598 specifically for CGNAT), NATed again upstream, a double translation that breaks even more assumptions about direct reachability.

NAT necessarily breaks the end-to-end principle: it requires routers to maintain per-flow state and rewrite packet headers (and recompute checksums), which is why protocols that embed IP addresses in their payload (like older FTP’s PORT command, or SIP) need Application Layer Gateways (ALGs) to patch the payload too, or they break silently behind NAT.

NAT Traversal Techniques

Establishing a direct P2P connection between two hosts each behind their own NAT requires actively working around the translation:

STUN (Session Traversal Utilities for NAT): a host asks a public STUN server “what public IP:port do you see me as”, discovering its own external mapping so it can share that address with a peer out-of-band (e.g. via a signaling server).
TURN (Traversal Using Relays around NAT): when direct connection is impossible (typically symmetric NAT on one or both sides), both peers send traffic through a public relay server instead, at the cost of extra latency and relay bandwidth.
ICE (Interactive Connectivity Establishment): the umbrella framework, used by WebRTC, that tries multiple candidate paths (direct, STUN-assisted, TURN-relayed) and picks whichever actually works.
UDP hole punching: both peers simultaneously send packets to each other’s (STUN-discovered) public address, causing both NATs to create outbound-triggered mappings that then also accept the inbound reply, effective against cone NAT but not symmetric NAT.

History

NAT was formally specified in RFC 1631 (1994), explicitly framed as a short-term stopgap to slow IPv4 address exhaustion while the internet transitioned to a bigger address space, a transition that, three decades later, still hasn’t fully happened.
Its uptake accelerated through the late 1990s and 2000s alongside consumer broadband, home routers made NAT invisible and automatic for millions of households that never configured it explicitly.
CGNAT emerged in the 2010s as ISPs ran out of public IPv4 addresses even for one-per-household allocation, pushing NAT a layer further upstream and introducing the double-translation issues described above.
STUN (RFC 3489, 2003, later revised as RFC 5389) and TURN/ICE followed directly from NAT’s widespread deployment breaking then-new P2P and VoIP applications that assumed direct end-to-end reachability.

Why It Matters

NAT is the single biggest reason IPv4 address exhaustion didn’t collapse the internet decades ago. A single public IPv4 address can serve an entire household, office, or even an ISP’s regional network of thousands of devices. It also provides an incidental security benefit: unsolicited inbound connections have no existing table entry to match, so they’re dropped by default, acting like a basic stateful firewall even without one configured explicitly.

NAT and IPv6

IPv6 was explicitly designed with enough address space that every device could have a globally routable address, removing the scarcity problem NAT solves for IPv4. In principle this means NAT isn’t needed for IPv6 at all. In practice:

Many dual-stack networks still run IPv4 NAT for legacy compatibility while IPv6 traffic flows natively without translation.
Some enterprises still deploy NAT66/NPTv6 (Network Prefix Translation) for renumbering flexibility or multihoming, not for address conservation.
Removing NAT doesn’t remove the need for a firewall, most consumer IPv6 deployments still block unsolicited inbound connections by default at the firewall, achieving a similar practical security posture to NAT’s incidental protection, but as an explicit policy rather than a side effect.

Common Pitfalls

Assuming NAT is a firewall. It’s a side effect of NAT that inbound-unsolicited traffic gets dropped, but NAT itself makes no security decisions, a misconfigured port forward (DNAT) bypasses that protection entirely.
P2P and VoIP connection failures behind symmetric NAT or CGNAT, requiring STUN (to discover the public mapping), TURN (a relay when direct connection is impossible), or ICE (which tries both) to establish a connection.
Port exhaustion: a single public IP has 65,536 ports; a busy NAT gateway serving thousands of concurrent connections can run out of translatable ports, especially under CGNAT shared across many customers.
Breaking protocols that embed addressing info in the payload rather than just the header, e.g. legacy active-mode FTP, without an ALG to rewrite it.
Confusing NAT with IPv6, IPv6’s address abundance was designed specifically so NAT wouldn’t be necessary, though some deployments still use NAT66/NPTv6 for renumbering or multihoming reasons unrelated to address scarcity.

Comparison

	NAPT (PAT)	Full Cone NAT	Symmetric NAT	CGNAT
Who applies it	Home/office router	Home/office router	Firewalls, strict routers	ISP, on top of customer NAT
P2P friendliness	Depends on cone type	Best	Worst	Worst (plus port scarcity)
Address sharing	One public IP, many hosts	One public IP, many hosts	One public IP, many hosts	One public IP, many customers

Debugging a NAT/Port-Forwarding Issue

A service that works fine from inside the network but is unreachable from outside is the classic NAT/port-forwarding symptom:

Confirm the server’s actual private IP and listening port on the internal host (ss -tulpn or netstat -an), it’s a common mistake to forward a port to the wrong internal IP after a DHCP lease renewal changed it.
Check the router’s port forwarding (DNAT) rule maps the correct external port to that internal IP:port, and that the protocol (TCP vs UDP) matches what the service actually uses.
From outside the network (a phone on cellular data, or an online port-checking tool), attempt to connect to the public IP and forwarded port, a connection refused vs a timeout tells you different things: refused means something answered and rejected it (often a local firewall on the server itself), a timeout usually means the packet never got forwarded at all.
curl ifconfig.me (or similar) from inside the network confirms what public IP the router is actually presenting, useful to rule out CGNAT, if this doesn’t match the IP you’re trying to forward on, the ISP is NATing you a second time and inbound port forwarding on your own router won’t be reachable at all without ISP-side cooperation.
Check the router’s NAT/connection table (interface varies by vendor) for whether an entry exists for the expected session at all, an entry that’s present but immediately expiring points to an overly aggressive idle timeout rather than a configuration error.

Example

Running curl ifconfig.me from a laptop returns the router’s public IP, not the laptop’s actual 192.168.x.x address, because NAT rewrote the source before the packet left the local network. Every device on a home Wi-Fi network shows the same public IP to external services for this reason.

FAQ

Does NAT slow down connections? Marginally, rewriting headers and looking up the translation table costs a small amount of processing per packet, but on modern hardware this is negligible compared to network latency.

Can two internal hosts behind the same NAT reach each other using the router’s public IP? Often not without “NAT hairpinning” (aka NAT loopback) support, some consumer routers don’t handle a LAN host addressing another LAN host via the shared public IP correctly.

Is IPv6 the actual fix for NAT’s problems? Largely yes, IPv6’s address abundance removes the scarcity that made NAT necessary, restoring end-to-end reachability, though firewalls (not NAT) still commonly restrict unsolicited inbound connections on IPv6 for security reasons.

Why does a video call sometimes fail to connect but a webpage loads fine? Web traffic is a simple outbound client request/response that NAT handles trivially. A video call needs a peer to connect back in, which runs straight into NAT/firewall traversal problems that STUN/TURN/ICE exist to solve.

Referenced by

Dig deeper

Spot an error in this note?

NAT