When Does WebRTC Use a TURN Server?

WebRTC is designed for peer-to-peer real-time communication, but direct connections often fail due to restrictive network barriers. This article explains the specific network circumstances—such as symmetric NATs, strict corporate firewalls, and blocked UDP ports—that force WebRTC to fall back to a TURN (Traversal Using Relays around NAT) server to successfully route media and data between peers.

To establish a connection, WebRTC uses the ICE (Interactive Connectivity Establishment) protocol. ICE first attempts to connect peers directly. If a direct connection is impossible, it falls back to a TURN server, which acts as a media relay. The following specific network conditions trigger this fallback:

1. Symmetric NAT on Both Ends

Network Address Translators (NATs) allow multiple devices on a private network to share a single public IP address. Under a “Symmetric” NAT, the router maps an internal IP and port to a unique external IP and port for each specific destination.

If Peer A and Peer B are both behind Symmetric NATs, a STUN (Session Traversal Utilities for NAT) server cannot predict the port mappings required for a direct connection. Because neither peer can “hole-punch” through the other’s NAT, WebRTC must route all traffic through a TURN server.

2. Strict Firewalls and Blocked UDP Ports

WebRTC prefers using UDP (User Datagram Protocol) for its low-latency media delivery. However, many secured networks—such as those in enterprise offices, schools, and hospitals—block all outbound UDP traffic on non-standard ports to protect their internal networks.

When a firewall blocks UDP traffic, WebRTC cannot establish a direct P2P connection. A TURN server resolves this by accepting traffic over TCP, or by wrapping the data in TLS (TURNS) on port 443, which mimics secure web traffic and easily bypasses most firewall restrictions.

3. Corporate Proxies and Deep Packet Inspection (DPI)

Many corporate environments force all outbound traffic to pass through an explicit HTTP or SOCKS5 proxy. Direct WebRTC peer-to-peer connections cannot negotiate these proxies. Furthermore, firewalls equipped with Deep Packet Inspection (DPI) can identify and block standard WebRTC media streams.

In these environments, a TURN server operating over TLS (port 443) is required. The encrypted WebRTC traffic looks like standard HTTPS web traffic to the proxy and DPI firewall, allowing the connection to succeed.

4. Carrier-Grade NAT (CGNAT)

Mobile network operators and some residential ISPs utilize Carrier-Grade NAT (CGNAT) to share a limited pool of public IPv4 addresses among thousands of users. While STUN can sometimes successfully traverse CGNAT, the combination of CGNAT with strict device-level firewalls or mobile hotspot configurations frequently prevents direct P2P connections, requiring a TURN server to bridge the gap.