WebRTC NAT Traversal Explained

Real-time communication on the web requires direct peer-to-peer connections, but Network Address Translation (NAT) often blocks these direct paths by hiding devices behind private IP addresses. This article explains how WebRTC successfully navigates and bypasses these network barriers using Interactive Connectivity Establishment (ICE), Session Traversal Utilities for NAT (STUN), and Traversal Using Relays around NAT (TURN) to establish secure, low-latency connections.

The NAT Obstacle in Peer-to-Peer Communication

Most devices on the internet do not have a unique public IP address. Instead, they sit behind routers utilizing NAT, which maps multiple private IP addresses within a local network to a single public IP address. While NAT conserves IP addresses and secures local networks, it prevents external peers from initiating direct connections to internal devices because the external peer does not know the internal device’s private IP or the port mapping on the router.

To bypass this barrier, WebRTC uses a framework called ICE to discover the best possible connection path between two peers.

Interactive Connectivity Establishment (ICE)

ICE is a framework used by WebRTC to find all possible ways for two peers to connect. These potential connection paths are called “ICE candidates.” ICE systematically gathers, exchanges, and tests these candidates to find the most efficient routing path.

An ICE candidate contains an IP address, a port, and a transport protocol (usually UDP). WebRTC gathers three types of candidates:

Step 1: Discovering Public IPs with STUN

The first step in bypassing NAT is finding out how the outside world sees the device. WebRTC uses STUN servers for this purpose.

A STUN server is a lightweight, public-facing server. The WebRTC client sends a simple request to the STUN server. The server inspects the incoming packet to see which public IP address and port the request came from, and sends this information back to the client.

Once the client receives its public IP and port (the Server Reflexive candidate), it shares this information with the remote peer via a signaling channel. If both routers allow direct incoming traffic on those ports, WebRTC establishes a direct, peer-to-peer connection. This works for the vast majority of consumer routers.

Step 2: Bypassing Restrictive NATs with TURN

Some network configurations, such as corporate firewalls or Symmetric NATs, block STUN-assisted direct connections. In a Symmetric NAT setup, the router changes the external port mapping for every unique destination the internal device tries to contact. As a result, the port mapping discovered via the STUN server will not work when the peer tries to connect to it.

When direct connection fails, WebRTC falls back to TURN. A TURN server acts as a media relay. Both peers connect directly to the TURN server, which then forwards the audio, video, and data streams between them.

Because both peers only make outbound connections to the public TURN server, this method bypasses almost all firewall and NAT restrictions. Although TURN requires significant server bandwidth and introduces slight latency, it guarantees that WebRTC connections succeed even on highly restrictive networks.

The Candidate Nomination Process

Once both peers have gathered and exchanged their ICE candidates, they begin connectivity checks. They test the candidate pairs in order of priority (Host candidates first for lowest latency, then STUN candidates, and finally TURN candidates as a fallback).

The moment a valid, stable path is verified and selected, WebRTC begins transmitting encrypted media and data over that path, ensuring a seamless real-time communication experience.