WebRTC Symmetric NAT Traversal Explained

WebRTC is designed for peer-to-peer (P2P) communication, but security configurations like Symmetric NAT make direct connections impossible. This article explains how WebRTC bypasses Symmetric NAT restrictions using the ICE framework, STUN servers, and ultimately TURN servers to guarantee connection success through media relaying.

The Challenge of Symmetric NAT

In a standard network, Network Address Translation (NAT) maps local IP addresses to a single public IP. With Symmetric NAT, the router assigns a unique external port for every specific destination IP and port that an internal device tries to contact.

Because of this security mechanism, if Peer A and Peer B are both behind Symmetric NATs, they cannot predict the external ports the other peer’s router has allocated for the connection. Any attempt at a direct peer-to-peer connection fails because the routers reject incoming packets from unexpected sources, making direct P2P mathematically impossible.

How WebRTC Resolves the Conflict: ICE, STUN, and TURN

WebRTC resolves this issue using a framework called ICE (Interactive Connectivity Establishment). ICE acts as a protocol coordinator that gathers different connection pathways, known as “candidates,” and tests them to find the most efficient working connection.

1. The STUN Request (First Attempt)

ICE first contacts a STUN (Session Traversal Utilities for NAT) server. STUN allows a peer to discover its own public IP address and port. If the peers are on simple NATs, they exchange these STUN-derived public addresses and establish a direct P2P connection. However, if a Symmetric NAT is detected, the STUN address becomes useless because the NAT will change the port mapping as soon as the peer attempts to connect to the other party instead of the STUN server.

2. The TURN Fallback (The Solution)

When ICE determines that a direct connection is impossible due to Symmetric NAT on both ends, it falls back to a TURN (Traversal Using Relays around NAT) server.

Instead of trying to connect directly, both peers establish a secure outbound connection to the TURN server. Because the connection is outbound from both sides, the Symmetric NATs allow the traffic to pass. The TURN server then acts as a media relay: * Peer A sends its media to the TURN server. * The TURN server forwards the media to Peer B. * Peer B sends its media to the TURN server, which forwards it to Peer A.

Performance and Cost Implications

While TURN servers guarantee that a WebRTC call will connect, they change the architecture from peer-to-peer to a client-server model. This introduces two main drawbacks:

• Latency: Routing media through an intermediary server adds physical distance and processing time, which can increase latency.
• Server Costs: Relaying high-definition video and audio requires significant bandwidth. Unlike STUN servers, which only assist in connection setup, TURN servers must handle the entire stream of data for the duration of the call.

Despite these drawbacks, TURN servers are a critical component of WebRTC infrastructure, ensuring connection reliability for the estimated 8% to 15% of calls that take place behind restrictive symmetric enterprise firewalls and NATs.