Symmetric NAT and WebRTC: What Breaks and Why

Symmetric NAT and WebRTC: What Breaks and Why

Symmetric NAT blocks direct WebRTC connections in most configurations.¹ When a browser behind symmetric NAT sends a STUN binding request, the router assigns a new external port specifically for that STUN server destination. A peer attempting to connect using that port will fail because the router assigned a different external port for the peer's IP (a port the peer never knew about). The ICE protocol exhausts all reflexive candidates without finding a matching port pair and falls back to relay via TURN, or fails entirely if no TURN server is available.

Around 10 to 20% of WebRTC connections involve at least one peer behind symmetric NAT, based on published WebRTC statistics from major video call providers.² Corporate networks and mobile carrier networks use symmetric NAT most frequently. Home routers typically use restricted cone NAT, which allows ICE to succeed through hole-punching, but mixing a symmetric NAT peer with any other NAT type prevents the hole-punch from working.³

Why symmetric NAT breaks ICE hole-punching

ICE hole-punching works by having both peers send packets to each other's reflexive candidates (the external IP:port pairs reported by STUN). For the hole-punch to succeed, the router must accept the incoming packet on the same external port it used for the outbound STUN request. Symmetric NAT assigns different external ports for different destinations, so the external port the peer is targeting is not the port the router has mapped for the peer's IP address. Consequently, the router silently drops all incoming connection attempts from the peer, and ICE marks the candidate pair as failed after multiple retry attempts.¹

Why cone NAT types allow hole-punching to succeed

Cone NAT types (full, restricted, and port-restricted) keep the external port consistent across all destinations, which is the property that makes hole-punching work. Once a cone NAT router maps an internal IP:port to an external port, any remote peer can send packets to that external port and the router forwards them back to the internal host. ICE relies on this predictability: both peers learn each other's external ports from STUN, then send packets to those ports, and the cone NAT forwards them without needing per-destination port assignments.

TURN relay as the fallback path

TURN (Traversal Using Relays around NAT) provides a server-mediated fallback when direct connectivity fails. Both peers connect outbound to the TURN server, which relays packets between them. Because both connections are outbound, symmetric NAT routers allow them. The ICE protocol lists relay candidates alongside host and reflexive candidates, and if direct connection fails, ICE promotes the relay candidate pair to active. Building on this, the relay path adds the round-trip to the TURN server to the overall RTT, typically 20 to 80 ms extra depending on TURN server location. Selecting a TURN server geographically close to both peers minimizes this overhead, which is why production WebRTC deployments distribute TURN infrastructure across multiple regions to keep relay latency manageable for the majority of their user base.

Diagnosing and resolving symmetric NAT

The STUN probe on this page identifies symmetric NAT by sending multiple binding requests to different STUN server endpoints and comparing the assigned external ports. Different ports for different destinations confirm symmetric NAT. To resolve it at the router level, switch the router's NAT mode to "Full Cone" or "Open NAT" if the admin panel exposes this setting; not all consumer routers offer this control. If the ISP applies symmetric NAT upstream via carrier-grade NAT, the only reliable fix is requesting a static public IP. Yet for applications that support TURN relay, configuring a geographically close TURN server limits the relay overhead to under 30 ms. CapyToolkit's STUN probe reveals the same symmetric-or-cone classification that your router's admin panel may show, giving you an independent confirmation before you contact your ISP about a potential CGNAT issue.

Deploying a TURN relay server for symmetric NAT fallback

Coturn is the most widely deployed open-source TURN and STUN server implementation, available at github.com/coturn/coturn.⁴ Deploying coturn on a cloud VM with a static public IP takes under an hour; the default coturn configuration on port 3478 UDP handles most WebRTC deployments without customization.⁵ Add the TURN credentials to the RTCPeerConnection iceServers array as a turns: URL on port 5349 for TLS-secured relay, alongside the default stun: entries. Port 5349 passes most corporate firewalls; adding TURN over TLS on port 443 provides a universal fallback for networks that block all non-HTTPS traffic.

Cloudflare TURN (part of Cloudflare Calls) provides a managed relay service without self-hosting. Each WebRTC session obtains a short-lived TURN credential via the Cloudflare API, and traffic relays through Cloudflare's global anycast network. For production deployments where symmetric NAT is a common case rather than an edge case, managed TURN with geographic distribution produces lower relay overhead than a single-region self-hosted instance.

Choosing TURN server location to minimize relay latency

TURN server location determines how much latency the relay path adds beyond the direct peer-to-peer path. For two users in the same city forced onto relay by symmetric NAT, a TURN server in that same city adds 5 to 15 ms of relay overhead. The same two users relaying through a server on another continent add 80 to 200 ms. Deploy TURN servers in each region where your user base is concentrated; three to five servers distributed across North America, Europe, and Asia-Pacific covers most populations with relay overhead under 30 ms.

Identifying carrier-grade NAT and escalating with your ISP

Carrier-grade NAT (CGNAT) sits upstream of your home router: the ISP operates a large NAT device that shares one public IP among many subscribers. Your router receives an address in the 100.64.0.0/10 range (RFC 6598 Shared Address Space) rather than a true public IP.⁶ The STUN probe in this tool reveals CGNAT when the discovered address falls in the 100.64.0.0/10 range. Symmetric NAT detection at the router level cannot fix CGNAT, because your router cannot control the port assignment behavior of the ISP's upstream device.

Escalating CGNAT with an ISP involves requesting a dedicated public IPv4 address. Many ISPs charge an additional fee (typically $5 to $15 per month) for a dedicated IP. Alternatively, enabling IPv6 on your connection bypasses CGNAT entirely: IPv6 connections use globally routable addresses without NAT, producing host candidates in ICE negotiations rather than reflexive candidates.⁷ If your ISP offers IPv6 (most major residential ISPs do as of 2026), enabling it is the zero-cost path to eliminating symmetric NAT and CGNAT effects on WebRTC connections.

Confirming CGNAT removal after ISP escalation

After the ISP provisions a dedicated public IP or enables IPv6, rerunning the STUN probe after an ISP fix confirms whether the discovered address now falls in a public IPv4 range (not 100.64.0.0/10 and not 10.0.0.0/8) or shows a global IPv6 address. A P2P test with a remote peer should then produce an ICE candidate type of "srflx" or "host" rather than "relay", confirming direct connectivity is now available.

Capturing the probe result and the candidate type together documents the fix in case the problem returns after a later firmware or ISP change. A single confirmation run is useful, but repeating it a week later proves the correction is stable rather than a temporary state. Treat the srflx or host candidate as the evidence your escalation succeeded, and keep that screenshot alongside the ISP ticket so you can show the before and after without re-running the whole diagnosis.

When to use this

Run this test when ICE negotiation fails for a WebRTC connection, when the connection always falls back to relay mode, or when you need to confirm whether your network or a remote peer's network is the source of the symmetric NAT restriction.

Examples