NAT Traversal Explained

NAT traversal is the collection of techniques used to establish direct network connections between devices that sit behind Network Address Translation (NAT) routers or firewalls. It is the fundamental technical challenge that every peer-to-peer application must solve to enable direct communication without routing all traffic through a central server.

Why NAT Is a Problem

Most devices on the internet do not have a public IP address. Instead, they sit behind a NAT router (your home router, office firewall, or mobile carrier gateway) that assigns them a private IP address. The NAT router maps outgoing connections to its single public IP address and routes responses back.

This works fine for client-server communication: your browser opens a connection to a web server, and the NAT router tracks the mapping. But when two devices behind different NATs want to connect directly to each other, neither knows the other's public address, and neither NAT will accept an incoming connection it did not initiate.

The result: direct peer-to-peer connections are blocked by default on the modern internet.

NAT Traversal Techniques

Several standardized techniques exist to solve this problem:

STUN (Session Traversal Utilities for NAT)

A STUN server is a lightweight public server that tells a device what its public IP address and port mapping look like from the outside. The device behind a NAT sends a request to the STUN server, which responds with the public address that the NAT assigned. Both peers discover their public addresses via STUN, then attempt to connect directly using those addresses.

This works for most common NAT types (called "cone NATs") but fails for symmetric NATs, which assign different public ports for each destination.

TURN (Traversal Using Relays around NAT)

When direct connection is impossible (symmetric NATs, strict firewalls), TURN provides a fallback. A TURN server acts as a relay: both peers connect to the TURN server, and it forwards traffic between them. This always works but adds latency and requires the relay server to handle all data throughput.

TURN is expensive to operate because the relay server must process every byte of transferred data. For large file transfers, this becomes a significant cost and performance bottleneck.

ICE (Interactive Connectivity Establishment)

ICE is a framework that combines STUN and TURN to find the best possible connection path. It works by:

1. Gathering all possible connection candidates: local addresses, STUN-discovered public addresses, and TURN relay addresses.
2. Testing candidates in priority order, preferring direct connections over relayed ones.
3. Selecting the best working path and establishing the connection.

ICE is used by WebRTC and is the standard approach for modern peer-to-peer applications.

Hole Punching

UDP hole punching is a technique where both peers simultaneously send packets to each other's public address. This creates NAT mapping entries on both sides, allowing subsequent packets to flow through. When it works, it enables a fully direct connection with no relay. TCP hole punching also exists but is less reliable because TCP's handshake protocol makes simultaneous connection attempts more complex.

NAT Traversal Success Rates

Not all NAT types are equal. The success rate of direct connection depends on the NAT types on both sides:

• Full cone NAT: Most permissive. Direct connection almost always succeeds.
• Address-restricted cone: Requires the peer to send first. STUN usually works.
• Port-restricted cone: More restrictive. STUN often works with hole punching.
• Symmetric NAT: Most restrictive. Direct connection usually requires a TURN relay or advanced prediction techniques.

In practice, direct P2P connections succeed roughly 80-90% of the time across the general internet population. The remaining cases require relay fallback.

How Handrive Handles NAT Traversal

Handrive handles NAT traversal automatically, with no configuration required from users. Its connection layer implements ICE-style candidate gathering, UDP hole punching, and relay fallback transparently. Users simply share a link, and Handrive establishes the most direct connection possible.

When a direct connection succeeds, data flows peer-to-peer with zero relay overhead. When NAT conditions require it, Handrive falls back gracefully without any user intervention. This is critical for P2P file transfer to work reliably across the range of network environments users operate in. Learn more about Handrive's approach to infrastructure on the AI Data Centers hub page.