Updated 8 hours ago
Every video call you make involves a moment of negotiation you never see. Your computer and your friend's computer—both hiding behind routers, both using addresses that mean nothing on the Internet—somehow find each other. They establish a direct connection across a network designed to prevent exactly that.
This is NAT traversal. It's the reason peer-to-peer communication works at all in the modern Internet.
The Problem NAT Creates
Your home router performs a daily magic trick. It takes one public IP address and makes it work for every device in your house. Your laptop gets 192.168.1.100. Your phone gets 192.168.1.101. Your smart TV gets 192.168.1.102. None of these addresses exist outside your house.
When you visit a website, Network Address Translation handles the translation. Your router remembers that you requested that webpage, so when the response arrives at your public IP address, it knows to forward it to 192.168.1.100. The system was designed for this: you reach out, servers respond, everyone's happy.
But what happens when both sides are behind NAT? You want to video call a friend. Neither of you can reach out first—neither knows where the other actually is on the Internet. Your private addresses are meaningless outside your respective networks. Your public addresses are owned by your routers, not by you.
NAT broke peer-to-peer connectivity. The techniques we're about to explore are how the Internet got it back.
STUN: Discovering What You Look Like
The first step is self-awareness. Before you can tell someone else where you are, you need to know where you are.
STUN—Session Traversal Utilities for NAT—answers one question: "What's my public address?"
Here's the exchange:
- Your application sends a binding request to a STUN server somewhere on the public Internet
- The STUN server looks at the packet that just arrived and notes the source IP address and port
- That's not your private address—it's what your router looks like from outside, after NAT translation
- The server sends this information back: "You appear to be at 203.0.113.42, port 54321"
You now possess critical intelligence. You share this address with your peer through some other channel—typically a signaling server both of you can reach. Your peer does the same with their own STUN server. Now you both know each other's public coordinates.
STUN (RFC 8489) is remarkably lean. A single exchange, milliseconds of latency, almost no bandwidth. It's efficient enough to run on every connection attempt without thinking twice.
But here's what STUN doesn't tell you: whether that address will actually work.
Why NAT Type Determines Your Fate
Not all NATs behave identically. The type of NAT between you and the Internet determines whether knowing your public address is enough.
Full Cone NAT is permissive. Once your router creates a mapping—say, internal port 50000 maps to external port 54321—anyone on the Internet can send packets to that external port and reach you. You sent one packet out; now anyone can reply.
Restricted Cone NAT adds a condition. Your router will only forward packets from addresses you've previously contacted. If you sent packets to IP address X, then X can send packets back. But address Y cannot, even though it knows your public address and port.
Port Restricted Cone NAT tightens this further. The incoming packets must come from the same IP address and the same port number you originally contacted. Different source port? Blocked.
Symmetric NAT is where direct connection dies. With symmetric NAT, your router creates a different external port mapping for each destination you contact. When you send packets to STUN server A, your router assigns external port 54321. When you send to peer B, your router assigns external port 54322. The address the STUN server told you about isn't the address your peer needs to use. There is no single "public address" for you—there's a different one for every destination.
RFC 4787 clarified the terminology: endpoint-independent mapping (cone NATs) versus address-and-port-dependent mapping (symmetric NAT). In practice, many modern routers implement hybrid behaviors. This unpredictability is why NAT traversal requires trying multiple approaches simultaneously.
Hole Punching: Coordinated Timing
Hole punching is a technique born from understanding how NAT creates and maintains port mappings.
The insight: when you send an outbound packet, your NAT creates a temporary mapping to allow the response. What if both peers send packets to each other at the same time?
Here's UDP hole punching:
- Both peers contact a rendezvous server and share their public addresses (discovered via STUN)
- The server tells each peer where to find the other
- Both peers simultaneously send UDP packets to each other's public addresses
- When you send to your peer, your NAT creates an outbound mapping—it punches a hole
- When your peer's packet arrives, that hole already exists, so the router forwards it through
- The same happens in reverse
- Direct connection established
The coordination is everything. Both sides must send before receiving. The outbound packet creates the state that allows the inbound packet through.
TCP hole punching exists but is fragile. TCP requires a three-way handshake, so both peers must perform a "simultaneous open"—each attempts to connect at precisely the right moment. Many NATs and firewalls don't handle this well. It's why WebRTC and most peer-to-peer systems prefer UDP.
Hole punching fails completely against symmetric NAT. The port your peer tries to reach isn't the port your NAT assigned for communicating with them. It also struggles in corporate networks with strict firewalls that block incoming attempts regardless of outbound state.
TURN: When Direct Fails
TURN—Traversal Using Relays around NAT—is the escape hatch. It's what you use when everything else is blocked.
A TURN server sits on the public Internet and simply forwards packets:
- You connect to the TURN server and request a relay allocation
- The server assigns you a public address and port on the server itself
- You share this relay address with your peer through signaling
- Your peer sends packets to the relay address
- The TURN server forwards them to you
- Reverse flow for your outbound packets
TURN (RFC 8656) works in every scenario. Even the most restrictive corporate firewall, even symmetric NAT. If you can make an outbound connection to the TURN server, TURN will work.
The cost is obvious. Every packet goes through the relay instead of directly between peers. This increases latency—an extra hop means an extra 20-100ms round trip. It consumes server bandwidth, which costs money. It creates a potential bottleneck and point of failure.
But it's necessary. Research shows roughly 8-10% of WebRTC connections require TURN relay, particularly in enterprise environments. Without it, these connections would simply fail. TURN is the difference between "works sometimes" and "works reliably."
ICE: Trying Everything Simultaneously
Interactive Connectivity Establishment is the orchestrator. ICE (RFC 8445) doesn't replace STUN, TURN, or hole punching. It combines them into a systematic process that tries every possible connection method at once and picks the winner.
Think of it as parallel path discovery.
Candidate Gathering: Each peer collects every way they might be reachable:
- Host candidates: local IP addresses on each network interface
- Server reflexive candidates: public addresses discovered via STUN
- Relay candidates: addresses allocated from TURN servers
A typical peer gathers 10-20 candidates representing different network paths.
Candidate Exchange: Peers exchange these candidates through signaling—usually a WebSocket to a server both can reach. This signaling is out-of-band from the actual media connection being established.
Connectivity Checks: Instead of trying candidates sequentially, ICE tests them all simultaneously. Each peer sends STUN binding requests to every combination of local and remote candidates. The first pair that completes a successful exchange wins.
Priority System: ICE prioritizes to prefer faster, cheaper paths:
- Host candidates (direct local network connection) - highest priority
- Server reflexive candidates (direct Internet via STUN) - medium priority
- Relay candidates (TURN relay) - lowest priority
This ensures that if a direct connection is possible, it will be discovered and used before falling back to relay. The application doesn't choose—ICE finds the best path automatically.
Trickle ICE: Traditional ICE waits until all candidates are gathered before exchanging them. Trickle ICE sends candidates incrementally as they're discovered. The moment a STUN response returns, that candidate goes to the peer and testing begins. This optimization can reduce connection setup from several seconds to under one second.
ICE's thoroughness makes it remarkably robust. Even in hostile conditions—different NAT types, corporate firewalls, multiple network interfaces—ICE methodically tests every possibility. If a path exists, ICE finds it.
WebRTC: The Complete Stack
WebRTC—Web Real-Time Communication—demonstrates how all these techniques work together in practice.
When you start a WebRTC call:
Signaling: Your browser connects to a signaling server (typically WebSocket) to coordinate with the peer
ICE Gathering: WebRTC starts collecting candidates:
- Discovers local IP addresses (host candidates)
- Contacts configured STUN servers for public addresses (server reflexive candidates)
- Allocates relay addresses from TURN servers (relay candidates)
Offer/Answer Exchange: Your browser creates an SDP (Session Description Protocol) offer containing media capabilities and ICE candidates. This goes through the signaling server to your peer. They respond with an SDP answer containing their candidates.
Connectivity Checks: Both browsers simultaneously test all candidate pairs to find working connections
Media Flows: Once connectivity is established, encrypted audio/video flows directly between peers—or through TURN relay if necessary
In optimal conditions—good Internet, no restrictive firewalls—this entire process completes in under a second. Even challenging scenarios requiring TURN typically connect within 2-3 seconds.
WebRTC standardizes the complete NAT traversal stack. It's why Google Meet, Microsoft Teams, Discord, and hundreds of other services can establish peer connections regardless of network complexity.
Why This Matters
NAT traversal isn't academic curiosity. It's fundamental infrastructure that determines whether modern applications can exist.
Video Conferencing: A 1080p video stream consumes 2-4 Mbps of bandwidth. If every call went through a central server, the service provider pays to receive your stream and send it to your peer—doubling bandwidth costs. With peer-to-peer via NAT traversal, streams go directly between participants. The provider pays nothing for bandwidth. Latency drops from 300-500ms through relay to 100-200ms direct. Your peer sees you speak without delay.
Gaming: In competitive gaming, 100ms of latency is the difference between winning and losing. NAT traversal enables peer-to-peer hosting where one player acts as server, avoiding latency to distant data centers. Even games with dedicated servers use these techniques for voice chat and invitations.
File Sharing: Sending a large file through a relay consumes server bandwidth and is typically slower than the direct connection between peers. BitTorrent, browser-based sharing, and sync tools use NAT traversal to establish direct transfers whenever possible.
IoT and Remote Access: Smart home devices and security cameras use NAT traversal for direct connections from your phone to your home without exposing devices publicly or routing everything through cloud servers. This improves privacy, reduces latency, and lowers infrastructure costs.
The pattern: NAT traversal makes applications faster, cheaper, more private, and more scalable by enabling direct peer-to-peer connections instead of forcing everything through centralized relays.
Current State and Future
In 2025, NAT traversal is mature, standardized infrastructure. The key RFCs define interoperable protocols that work across browsers, native apps, and IoT devices.
Success rates are high. Studies show roughly 86% of WebRTC connections succeed with direct peer-to-peer paths via STUN and hole punching. Another 6% require TURN due to symmetric NAT. Another 3-4% need TURN because of restrictive firewalls. Only 1-2% fail completely, typically in extremely locked-down corporate networks that block all peer-to-peer traffic.
Cloud providers offer managed TURN infrastructure. Open-source implementations like coturn provide battle-tested relay servers. Public STUN servers exist, though production applications usually run their own for reliability.
Challenges remain. IPv6 adoption could eventually eliminate NAT entirely—every device would have a globally routable address. But IPv6 deployment has been slow. NAT will persist for years. Carrier-grade NAT (CGNAT) used by mobile networks adds multiple layers of translation, increasing complexity. Security-conscious networks may make TURN increasingly necessary as firewalls become more restrictive.
What Matters
NAT creates a fundamental problem: it makes peer-to-peer connectivity impossible by default. The Internet was supposed to be end-to-end. NAT broke that model.
STUN lets you discover your public identity. Hole punching exploits NAT behavior to create temporary paths. TURN provides a relay when direct paths don't exist. ICE orchestrates the entire process, trying everything simultaneously and choosing the best result.
Together, these techniques restore peer-to-peer connectivity. They're invisible infrastructure that makes video calls, multiplayer games, file sharing, and real-time communication possible.
Every peer-to-peer connection you make involves this sophisticated negotiation happening in milliseconds. The techniques work so reliably that you never notice them. But without them, the modern Internet—the one where any device can communicate directly with any other device—wouldn't exist.
NAT traversal is how we got the peer-to-peer Internet back.
Sources
Was this page helpful?