Check Your NAT Type for Gaming and Video Calls

Check Your NAT Type for Gaming and Video Calls

Your NAT type controls whether direct connections succeed. When two peers try to connect via WebRTC, the ICE protocol tests whether each peer's router will allow the incoming connection, and the strictness of that test depends entirely on the NAT classification your router applies. Open NAT allows any incoming packet; restricted NAT allows only packets from known hosts; symmetric NAT assigns a new external port for every distinct destination, blocking most direct P2P connections without a relay server.¹

The STUN probe on this page discovers your NAT type automatically. Sending a binding request to a public STUN server, it reads back your public IP address and the external port the router assigned to that outbound connection, then compares multiple requests to determine whether the router uses the same port for different destinations, which is the defining characteristic of symmetric NAT.²

The four NAT types and what they mean for P2P

Full Cone NAT (Open) maps one internal IP:port to a single external port and accepts any incoming packet on that port regardless of the original source address or port. Restricted Cone NAT tightens that rule by accepting incoming packets only from IP addresses the internal host contacted first. Port Restricted Cone adds the source port check on top of the IP check, so both the address and port must match a prior outbound contact. Symmetric NAT, the strictest classification, assigns a different external port for every unique destination the host reaches.¹ Because the STUN server and the remote peer are always different destinations, a symmetric NAT prevents the peer from learning the correct external port, which is why direct P2P connections fail without a relay.

Why symmetric NAT forces traffic through TURN relay infrastructure

Consequently, symmetric NAT prevents direct WebRTC connections in the majority of cases because the peer never receives a stable external port it can advertise to the other side of the session.³ ICE therefore falls back to a TURN relay server, which acts as a public intermediary that both peers can reach regardless of their respective NAT strictness. Relaying adds latency and bandwidth cost, since every media packet travels through the relay rather than taking a direct path between the two endpoints. CapyToolkit's NAT test reveals the same classification your console reports, giving you a cross-platform reference before troubleshooting game connectivity.

Why gaming consoles use NAT type labels

Gaming networks use simplified NAT labels because their underlying technology (PSN, Xbox Live, Nintendo Switch Online) relies on direct peer-to-peer connections for multiplayer traffic. PlayStation uses NAT Type 1 (direct), Type 2 (router, open cone), and Type 3 (strict or symmetric). Xbox uses Open, Moderate, and Strict. All three platforms map their labels to the same underlying cone/symmetric distinction, even though the numbering and terminology differ between manufacturers. Building on this understanding, a router showing "NAT Type 3" on PlayStation will also show "relay" ICE candidates in this WebRTC tester, confirming the symmetric classification. The value of running the STUN probe in this tool is that it reveals the actual NAT behavior your console experiences, independent of how each manufacturer chooses to label it.

How NAT type affects matchmaking and peer connectivity in online games

Matchmaking systems in online games attempt to connect players with compatible NAT types to ensure successful peer-to-peer connections. Open NAT players can connect directly to any other NAT type. Moderate NAT players connect to Open and Moderate peers but may fail to connect with Strict NAT players. Strict NAT players can typically only connect with Open NAT peers, which limits the pool of potential opponents and can increase matchmaking times. Understanding your NAT type helps explain why you may experience failed game sessions or long wait times when playing with specific friends. CapyToolkit's NAT test reveals the same classification your console reports, giving you a cross-platform reference before troubleshooting game connectivity.

How to improve a strict or symmetric NAT

Enabling UPnP on your router lets devices negotiate port mappings automatically, often moving a strict NAT to restricted or open.⁴ Many gaming routers include UPnP enabled by default; check your router admin panel under WAN or NAT settings to confirm. Port forwarding specific game ports achieves the same result for known applications. For symmetric NAT behind carrier-grade NAT from your ISP, the only reliable fix is requesting a dedicated public IP from your ISP, as no router-side change can override the upstream NAT.⁵ Conversely, running a TURN relay server provides a fallback path for applications that support it.

Verifying NAT improvement after router configuration changes

Your router's admin panel report of "Open NAT" does not guarantee that direct WebRTC connections will succeed. The admin panel reflects the router's internal configuration, but the actual externally visible NAT behavior depends on how the router assigns external ports to outbound connections. Running the STUN probe in this tool before and after a configuration change is the only reliable confirmation that the change produced the expected result.

The STUN probe reveals cone NAT by sending binding requests to two different STUN server addresses and confirming that both responses contain the same external port.⁶ Matching ports across both requests confirm cone NAT; ICE hole-punching will succeed for most peer configurations. Different ports confirm symmetric NAT remains active regardless of what the admin panel reports.

What to do when the admin panel and probe results disagree

A mismatch between the router's reported NAT type and the STUN probe result typically indicates carrier-grade NAT upstream from the router. Your router is configured for Open NAT, but the ISP's CGNAT layer above it imposes symmetric port assignment on outbound connections. Contact your ISP and ask whether you are behind CGNAT; request a dedicated public IPv4 address or confirm IPv6 availability as the alternative path forward.

Carrier-grade NAT identification and resolution paths

Addresses in the 100.64.0.0/10 range (the IANA Shared Address Space defined in RFC 6598) reveal CGNAT directly.⁵ When the STUN probe returns an address starting with 100.64 or 100.65, your ISP is assigning you a shared internal address rather than a unique public IP. No router-side change, UPnP rule, or port forwarding configuration can fix symmetric NAT imposed by the ISP's upstream CGNAT infrastructure.

Two reliable resolution paths exist for CGNAT. Requesting a static public IPv4 address from your ISP removes the CGNAT layer entirely; many ISPs offer this as an optional paid upgrade. Enabling IPv6 bypasses IPv4 CGNAT because IPv6 allocates globally routable addresses directly to each device, with no NAT layer at the ISP.³ With IPv6 active, WebRTC ICE generates host candidates from the device's global IPv6 address, and direct connections succeed without STUN or TURN involvement.

Testing for CGNAT before contacting your ISP

Confirm CGNAT independently before calling support by comparing your router's WAN IP against the STUN-discovered address, which reveals your externally visible public IP without waiting on a support ticket. Open your router's admin panel and note the WAN IP your ISP assigned. If the two addresses differ, your router's WAN address is a CGNAT-internal address and the probe shows the real public IP shared with other customers. Matching addresses confirm a direct public IP with no upstream CGNAT.

Documenting the mismatch with a screenshot of both IP addresses gives your support ticket a concrete starting point instead of a vague latency complaint. Many ISPs will only escalate a CGNAT request after you show that the router WAN address and the STUN-discovered address genuinely differ. Running this comparison once before calling avoids the back-and-forth of first-line support asking you to reboot the router, which never resolves an upstream NAT layer.

When to use this

Run this test before troubleshooting multiplayer game connection errors, when WebRTC video calls refuse to connect, or when you need to confirm that a router configuration change moved your NAT type from strict to open.

Examples

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