UDP Hole Punching: How Devices Behind Firewalls Connect Directly

Most devices sit behind NAT firewalls that allow outbound connections but block unsolicited inbound traffic. Two NAT-protected devices face an impossible standoff: neither can reach the other first.

UDP hole punching solves this with an elegant trick: both devices reach out simultaneously, and in doing so, each creates the opening the other needs.

The Standoff

When your device sends data through NAT, the router creates a temporary mapping—your internal address and port linked to an external address and port. Return traffic reaches you through this mapping. But unsolicited inbound traffic gets dropped.

Two devices behind NAT can't connect. Device A can't send to B because B's router rejects the unexpected packet. Device B can't send to A for the same reason. A can't reach B until B's NAT creates a mapping, but B's NAT won't create that mapping until B sends something first.

The traditional solution: relay servers that forward everything between peers. It works, but adds latency. For video calls or multiplayer games, that latency breaks the experience.

The Simultaneous Knock

UDP hole punching exploits predictable NAT behavior: once an outbound UDP packet creates a mapping, the router accepts inbound packets arriving at that same external port—even from sources the device never contacted directly.

The technique requires three participants: two peers and a publicly accessible rendezvous server.

Both peers connect to the rendezvous server. When A sends a UDP packet to the server, A's NAT creates a mapping—say, external IP 203.0.113.10 on port 5000. The server records this. B does the same, perhaps appearing at 198.51.100.20 on port 6000.

Now the server knows both public endpoints. It tells A where B is, and tells B where A is.

Here's the trick: both peers send UDP packets to each other's public endpoints at the same time.

When A sends to B's endpoint (198.51.100.20:6000), the packet probably gets dropped—B's NAT hasn't created a mapping for A yet. But this outbound packet from A punches a hole in A's NAT. Port 5000 is now listening.

Simultaneously, B sends to A's endpoint (203.0.113.10:5000). This packet punches a hole in B's NAT—and arrives at exactly the port where A's NAT is now accepting traffic.

Both peers send packets that will be rejected—but in being rejected, they create the conditions for acceptance.

Within milliseconds, both holes exist and packets flow in both directions. The rendezvous server's job is done. The peers communicate directly.

STUN and TURN

The Internet Engineering Task Force standardized this process:

STUN (Session Traversal Utilities for NAT) servers help devices discover their public endpoints. You send a request; the server tells you what address and port it saw. STUN servers are lightweight—they reflect information, never relay traffic.

TURN (Traversal Using Relays around NAT) servers are the fallback when hole punching fails. A TURN server actually relays traffic between peers. This defeats the bandwidth and latency benefits of direct connection, but ensures connectivity when nothing else works.

Modern applications use ICE (Interactive Connectivity Establishment), which tries multiple strategies in parallel: direct connection, hole punching via STUN, relay via TURN. The best working option wins.

When It Fails

Hole punching works with most consumer routers, but several things break it:

Symmetric NAT assigns different external ports depending on the destination. When A contacts the STUN server, it gets one external port. When A sends to B, it gets a completely different port. The endpoint information from STUN becomes useless. About 11% of Internet users sit behind this type of NAT¹.

Port-restricted NAT only accepts inbound packets from addresses the device has already contacted. B's packets to A get dropped unless they come from the exact address A sent to—but A sent to B's NAT, not B directly.

Corporate firewalls may block UDP entirely or inspect traffic at the application layer.

TCP doesn't work the same way. TCP's three-way handshake creates a "simultaneous open" scenario that most NAT implementations don't handle correctly. Hole punching is fundamentally a UDP technique, though recent research shows that with precise timing synchronization, TCP and QUIC can achieve similar success rates².

Hole punching succeeds in roughly 70-82% of real-world scenarios³. For the rest, TURN relays provide connectivity at the cost of latency.

Where You've Used It

VoIP calls pioneered the technique. Skype used hole punching to establish direct audio streams because real-time voice can't tolerate relay latency.

Multiplayer games punch holes constantly. When 10 milliseconds determines who wins a gunfight, you can't route through central servers. Game clients use rendezvous servers for matchmaking, then establish direct UDP connections for gameplay.

WebRTC brought hole punching to browsers. When you join a video conference, ICE automatically discovers your network configuration, attempts hole punching, and falls back to relays if needed. You click "join" and get peer-to-peer video.

The technique also powers file sharing, remote desktop tools, and IoT device communication. Anywhere you need direct connection while sitting behind NAT, some variant of hole punching makes it possible.

Sources