NAT Traversal Techniques Explained

Every video call involves an impossible moment you never see.

Your computer and your friend's computer—both hiding behind routers, both using addresses that mean nothing on the public Internet—somehow find each other and establish a direct connection. This happens across a network that was designed to prevent exactly that.

This is NAT traversal. It's the reason peer-to-peer communication works at all.

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 home.

When you visit a website, Network Address Translation handles the conversion. 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 works beautifully 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 belong to your routers, not to 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

Before you can tell someone 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:

1. Your application sends a binding request to a STUN server on the public Internet
2. The STUN server examines the arriving packet and notes the source IP address and port
3. That's not your private address—it's what your router looks like from outside, after NAT translation
4. 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. Now you both know each other's public coordinates.

STUN (RFC 8489) is remarkably lean. A single exchange, milliseconds of latency, almost no bandwidth.

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 to receive packets.

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 only forwards packets from addresses you've previously contacted. If you sent packets to IP address X, then X can reply. But address Y cannot, even if it knows your public address and port.

Port Restricted Cone NAT tightens this further. Incoming packets must come from the same IP address and the same port you originally contacted.

Symmetric NAT is where direct connection often dies. Your router creates a different external port mapping for each destination you contact. When you query STUN server A, your router assigns external port 54321. When you try to reach 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.

In practice, most home routers and cellular networks implement cone NAT variants. Enterprise firewalls and security appliances often implement symmetric NAT. This is why corporate users frequently have more trouble with peer-to-peer connections.

Hole Punching: Coordinated Timing

Hole punching exploits 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:

1. Both peers contact a rendezvous server and share their public addresses (discovered via STUN)
2. The server tells each peer where to find the other
3. Both peers simultaneously send UDP packets to each other's public addresses
4. When you send to your peer, your NAT creates an outbound mapping—it punches a hole
5. When your peer's packet arrives, that hole already exists, so the router forwards it through
6. The same happens in reverse
7. 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 attempting to connect at precisely the right moment. Many NATs don't handle this well. It's why WebRTC and most peer-to-peer systems prefer UDP.

Hole punching fails against symmetric NAT. The port your peer tries to reach isn't the port your NAT assigned for communicating with them.

TURN: When Direct Fails

TURN—Traversal Using Relays around NAT—is the escape hatch when everything else fails.

A TURN server sits on the public Internet and simply relays packets:

1. You connect to the TURN server and request a relay allocation
2. The server assigns you a public address and port on the server itself
3. You share this relay address with your peer through signaling
4. Your peer sends packets to the relay address
5. The TURN server forwards them to you
6. Reverse flow for your outbound packets

TURN (RFC 8656) works in every scenario. Even the most restrictive corporate firewall, even symmetric NAT on both ends. If you can make an outbound connection to the TURN server, TURN works.

The cost is real. Every packet travels through the relay instead of directly between peers. Latency increases—an extra hop adds 20-100ms round trip. Server bandwidth costs money. The relay becomes a potential bottleneck and point of failure.

But it's necessary. Industry data suggests 15-30% of WebRTC connections require TURN relay, with higher rates in enterprise environments where symmetric NAT and strict firewalls are common. Without TURN, these connections would simply fail.

TURN is the difference between "works sometimes" and "works reliably."

ICE: Trying Everything at Once

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 simultaneously and picks the winner.

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.

Connectivity Checks: ICE tests all candidate combinations simultaneously. Each peer sends STUN binding requests to every pairing of local and remote candidates. The first pair that completes a successful exchange wins.

Priority System: ICE prefers faster, cheaper paths:

1. Host candidates (direct local network) — highest priority
2. Server reflexive candidates (direct Internet via STUN) — medium priority
3. Relay candidates (TURN) — lowest priority

This ensures direct connections are 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 reduces 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.

When you start a WebRTC call:

Signaling: Your browser connects to a signaling server (typically WebSocket) to coordinate with the peer

ICE Gathering: WebRTC collects candidates:

• Discovers local IP addresses (host candidates)
• Contacts 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 travels 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

Media Flows: Once connectivity is established, encrypted audio and video flow directly between peers—or through TURN if necessary

In optimal conditions, this entire process completes in under a second. 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 applications can establish peer connections regardless of network complexity.

Why This Matters

NAT traversal isn't academic curiosity. It's fundamental infrastructure.

Video Conferencing: A 1080p video stream consumes 2-4 Mbps. If every call went through a central server, the provider pays to receive your stream and send it to your peer—doubling bandwidth costs. With peer-to-peer via NAT traversal, streams flow directly between participants. The provider pays nothing for that bandwidth. Latency drops from 300-500ms through relay to 100-200ms direct.

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 the latency penalty of distant data centers.

File Sharing: Sending a large file through a relay consumes server bandwidth and is typically slower than direct transfer. BitTorrent, browser-based sharing, and sync tools use NAT traversal for direct connections 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.

The pattern: NAT traversal makes applications faster, cheaper, more private, and more scalable.

Current State

In 2025, NAT traversal is mature, standardized infrastructure. The key RFCs—8445 for ICE, 8489 for STUN, 8656 for TURN—define interoperable protocols that work across browsers, native apps, and IoT devices.

Success rates vary by environment. Consumer networks with cone NAT typically achieve 70-85% direct peer-to-peer connections. Enterprise environments with symmetric NAT and strict firewalls see higher TURN usage—sometimes 30% or more of connections require relay.

IPv6 adoption could eventually reduce NAT's prevalence—every device would have a globally routable address. But IPv6 deployment remains slow, and carrier-grade NAT (CGNAT) on mobile networks adds additional layers of translation. NAT traversal will remain essential for years.

What Matters

NAT creates a fundamental problem: peer-to-peer connectivity becomes impossible by default. The Internet was designed for end-to-end communication. NAT broke that model.

STUN lets you discover your public identity. Hole punching exploits NAT behavior to create temporary paths. TURN provides relay when direct paths don't exist. ICE orchestrates the entire process, trying everything simultaneously and choosing the best result.

Together, these techniques restore what NAT took away.

Every peer-to-peer connection you make involves this 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 talk directly to any other device—wouldn't exist.

NAT traversal is how we got the peer-to-peer Internet back.

Sources