How WebRTC Connects Peers Behind NATs

WebRTC and NAT Traversal

The internet is filled with middleboxes that make direct peer-to-peer communication complicated. Most devices are hidden behind routers that use Network Address Translation (NAT)—sometimes even multiple layers of NAT—to conserve the limited pool of IPv4 addresses. While NAT works great for client/server connections, peer-to-peer connections are difficult.

What Is NAT, and Why Does It Matter?

NAT (Network Address Translation) is a process used by routers to map private IP addresses within a local network to a single public IP address shared across devices. This allows multiple devices to access the internet without each needing its own public IP.

But NAT complicates direct communication between devices because devices behind NAT don’t have their own public IP. Instead, NAT decides how to map private IPs and ports to a shared public-facing one.

Not all NATs work the same way. The terminology is somewhat outdated but generally NATs fall into the following categories:

• Full Cone NAT: Connections are mapped one-to-one, meaning any external device can reach the internal device as long as it knows the public IP and port. This type offers the most straightforward connectivity.

• Restricted Cone NAT: External devices can only access the internal device if their IP address matches the IP address previously contacted by the internal device. This restricts unsolicited connections.

• Port-Restricted Cone NAT: Similar to restricted cone NAT, but even more selective—external devices must match both the IP address and port used by the internal device. This further limits accessibility.

• Symmetric NAT: Each outgoing connection from the internal device is assigned a unique mapping (IP and port) on the NAT. This makes it nearly impossible for external devices to initiate a direct connection since the mapping depends on the destination address.

What Is WebRTC?

WebRTC (Web Real-Time Communication) is an open-source protocol that enables direct, real-time communication between devices over the internet. Its used for everything from video and voice calls to file sharing and live streaming, by facilitating peer-to-peer connections without relying on central servers for data transfer.

To achieve this, WebRTC integrates several existing protocols into a unified framework. ICE (for connection discovery), DTLS (for encryption and security), and RTP (for streaming audio and video). These technologies work together to provide secure, efficient, and low-latency communication.

Discovering Public Addresses with STUN

Devices behind NAT need to know how their private IP and port appear to the outside world. This is where STUN (Session Traversal Utilities for NAT) servers come in. By sending requests to a STUN server, a device can discover its public IP address and the port mapping created by the NAT. This information is critical for establishing a connection but doesn’t establish one on its own—it’s simply the first step in understanding how the NAT translates addresses.

Signaling and Session Descriptors

Before any connection can occur, WebRTC devices exchange signaling data to negotiate the terms of the connection. Devices share Session Description Protocols (SDPs) , which act as blueprints for the connection. SDPs contain details like supported codecs, media formats, and network information, enabling both devices to agree on how to communicate. This signaling phase is facilitated by an external server but does not itself involve the transmission of any application data.

Finding the Best Path with ICE

Once public and private address candidates are gathered, ICE (Interactive Connectivity Establishment) takes over to determine the best path for communication. ICE collects all possible connection options—direct routes, NAT mappings, and even relayed connections via TURN servers—and tests them to find the most efficient and reliable option. The result is a prioritized list of paths, ensuring the connection is optimized for low latency and stability.

UDP Hole Punching

For devices behind compatible NATs, WebRTC employs UDP hole punching, a technique that creates a temporary path through the NAT for peer-to-peer communication. Here’s how it works:

1. Discover External Mappings: Each device uses a STUN server to determine its public-facing IP and port.

2. Exchange Mappings: This information is exchanged via the signaling phase, allowing devices to identify where to send data.

3. Punch Holes: Both devices send small packets to each other’s external addresses, prompting the NAT to create an entry in its mapping table.

4. Establish Direct Connection: Once the mapping exists on both sides, subsequent packets can traverse the NAT, enabling direct communication.

The Symmetric NAT Problem

Unlike other types of NAT, symmetric NATs assign a unique external mapping (IP and port) for every outgoing connection. This means that the mapping used to communicate with a STUN server is different from the mapping required for direct communication with another device. Since the external mapping depends on the destination address, symmetric NATs make it nearly impossible for two devices to establish a direct connection.

For peer-to-peer communication, this inconsistency forces a reliance on relay servers, as techniques like UDP hole punching won’t work. Symmetric NATs are common in enterprise or heavily secured networks, with strict controls on external connections.

How TURN Servers Solve the Problem

When direct connections are blocked by symmetric NATs or other restrictive networking conditions, TURN (Traversal Using Relays around NAT) servers are used to create the connection, by relaying data between devices. Data remains encrypted as it goes through the relay using DTLS and SRTP in the case of WebRTC.

TURN servers have trade-offs, though. Relaying traffic increases latency, and TURN servers can consume a lot of bandwidth depending on the application.

If you’re interested in seeing a simple WebRTC application, check out my PeerBeam-Web and PeerBeam-CLI projects, which both use WebRTC for peer-to-peer file transfer.