The Problem NAT Creates
NAT (Network Address Translation) lets a whole household share one public IP address. The router keeps a translation table: when a device makes an outbound connection, the router notes the mapping between the device's private address and a public port, so replies can find their way back. The catch is what happens to unsolicited inbound packets — ones that do not correspond to any outbound connection. The router has no table entry for them and no idea which internal device they are for, so it drops them. That behaviour is essential for sharing an address and doubles as a basic firewall, but it is fatal to peer-to-peer apps: if both ends only accept replies to their own outbound traffic, who initiates?
Traditionally the answer was manual port forwarding — but you cannot ask millions of casual users to configure their routers. NAT traversal automates the whole thing.
STUN: "What Is My Public Address?"
The first obstacle is that a device behind NAT does not even know its own public face. It sees a private address like 192.168.1.40, but the outside world sees the router's public IP and some translated port. STUN (Session Traversal Utilities for NAT) solves this with a simple, cheap server on the public internet. The device sends a request to the STUN server; the server replies, "I see you coming from public address 203.0.113.7:51200." Now the device knows the public IP and port its NAT has assigned, and it can share that with a peer as a place to be reached.
STUN is lightweight — the server only answers one question and never touches the actual media traffic — so it is cheap to run at scale. For most NAT types, knowing each other's public address is enough for the two peers to connect directly.
Hole Punching: Why a Direct Connection Forms
Knowing the addresses is half the battle; the other half is getting past the "drop unsolicited inbound" rule on both routers at once. The technique is UDP hole punching. Once each peer knows the other's public address (via STUN, exchanged through a signalling server), both send packets toward each other simultaneously.
Here is the clever part: when peer A sends its first outbound packet to peer B, A's own router creates a translation-table entry for that destination. A moment later, B's packet arrives at A's router — and now it matches that fresh entry, so it is allowed in rather than dropped. Each side's outbound packet "punches a hole" that the other side's traffic can come back through. The connection is genuinely direct, peer to peer, with no relay in the middle. This is why real-time apps and games favour UDP — its connectionless model makes the simultaneous-send trick straightforward.
TURN: The Relay of Last Resort
Hole punching does not always work. The hardest case is symmetric NAT (and carrier-grade CGNAT), where the router assigns a different public port for every distinct destination. The address a peer learned from STUN is then useless for a connection to a third party, because a new destination gets a new port. When both ends sit behind such NATs, no direct path can be established.
The fallback is TURN (Traversal Using Relays around NAT). A TURN server sits on the public internet and simply relays all traffic between the two peers: A sends to the relay, the relay forwards to B, and vice versa. Because each peer is only ever talking outbound to the relay, NAT is never an obstacle. The cost is real, though — every byte of the call now flows through your server, consuming bandwidth and adding a little latency from the extra hop. TURN always works, which is exactly why it is reserved for when nothing else does.
ICE: Try Everything, Pick the Best
Rather than guessing in advance which approach will work, modern systems use ICE (Interactive Connectivity Establishment) to try them all. ICE is the coordinating framework that uses STUN and TURN together:
- Gather candidates. Each peer collects every address it might be reachable on: its local/private address (host candidate), its STUN-discovered public address (server-reflexive candidate), and a TURN relay address (relay candidate).
- Exchange and pair. The peers swap their candidate lists through a signalling channel and form pairs to test.
- Connectivity checks. ICE sends test packets across the candidate pairs and keeps the ones that succeed, ranked by preference: a direct local path first, a STUN-assisted direct path next, and a TURN relay only as a last resort.
The result is that a connection uses the most direct route available on that particular pair of networks, falling back gracefully as far as it must. ICE is the brain; STUN and TURN are the tools it reaches for.
Where You Meet This Every Day
This stack is the backbone of WebRTC, the technology behind in-browser video calls, and underlies most VoIP and peer-to-peer gaming connectivity. It is also why the NAT type shown on a games console matters: an "open" NAT punches holes easily, while a "strict" or symmetric NAT often forces traffic onto a relay, adding latency. If a peer-to-peer app feels sluggish or refuses to connect directly, a restrictive NAT — frequently double NAT or CGNAT on the path — is the usual culprit, and the session has quietly fallen back to a TURN relay.
Frequently Asked Questions
What is NAT traversal?
The set of techniques that let two devices behind separate NAT routers connect directly, despite NAT normally blocking unsolicited inbound traffic. It powers peer-to-peer calls, gaming, and file transfer without manual port forwarding.
What is the difference between STUN and TURN?
STUN is a lightweight server that tells a device its public address so a direct connection can form. TURN is a relay that forwards all traffic between peers when a direct connection is impossible. STUN is cheap and preferred; TURN is the bandwidth-hungry fallback.
What is ICE?
Interactive Connectivity Establishment — the framework that gathers every candidate address (local, STUN, TURN) and tests pairs until it finds a working path, preferring the most direct one.
Why does NAT block incoming connections?
NAT maps many private addresses to one public address using entries built from outbound traffic. An unsolicited inbound packet matches no entry, so the router cannot tell which device it is for and drops it — a side effect of address sharing that also acts as a firewall.
What is UDP hole punching?
Both peers send outbound packets to each other's public address simultaneously. Each outbound packet creates a NAT mapping, so the other peer's incoming packet now matches an entry and is let through — punching a hole that allows a direct connection.