WebRTC STUN

WebRTC STUN (Session Traversal Utilities for NAT) is a lightweight networking protocol that enables browsers and real-time communication clients to discover their public-facing IP address and port mapping when operating behind a Network Address Translation (NAT) router or firewall. WebRTC relies on direct peer-to-peer (P2P) connections between endpoints to stream voice, video, and data without routing high-bandwidth media through centralized servers. Because residential and enterprise routers assign private local IP addresses (such as 192.168.x.x or 10.x.x.x) that are unroutable over the public internet, endpoints cannot communicate directly until a public STUN server reflects back their external, internet-accessible coordinates.

Core Components of WebRTC STUN

The STUN architecture (defined in RFC 5389 and RFC 8489) operates on a client-server request-response model integrated into the WebRTC signaling workflow. It consists of four fundamental elements:

• STUN Client: The WebRTC-enabled application or web browser (such as Google Chrome, Firefox, or Safari) that originates binding requests to determine its own external addressing.
• STUN Server: A publicly reachable server listening on standard UDP and TCP port 3478 (or port 5349 for encrypted TLS sessions) that reflects the client's public socket details back to it.
• NAT Mapping Mechanism: The local gateway or router table that translates private internal sockets into external public IP and port combinations.
• Interactive Connectivity Establishment (ICE) Agent: The browser engine that coordinates STUN queries, collects local and remote candidate pairs, and negotiates the lowest-latency connection path.

Types and Variants of WebRTC Traversal Candidates

During the signaling exchange, the browser evaluates several types of network candidates generated via STUN, host inspection, and relay mechanisms.

Host candidates represent direct network interfaces attached to the local machine, including private Ethernet addresses, Wi-Fi adapters, and internal virtual interfaces. These candidates allow two devices situated on the same local subnet to connect directly without leaving the local network.

Server reflexive candidates (srflx) are generated specifically by WebRTC STUN queries. When the client contacts an external STUN server, the server inspects the packet headers and returns the public IP address and port allocated by the NAT router. These candidates are essential for connecting two endpoints located behind standard residential routers.

Peer reflexive candidates (prflx) occur dynamically during direct ICE connectivity checks. If an endpoint receives a binding request from a public socket that differs slightly from the server reflexive candidate previously signaled (often due to symmetric NAT port reallocation), it logs the new coordinate as a peer reflexive candidate.

Relayed candidates (relay) are produced when STUN fails entirely due to restrictive enterprise firewalls or symmetric NATs. Instead of establishing a direct peer-to-peer path, the browser invokes Traversal Using Relays around NAT (TURN) to route media packets through a dedicated relay server.

How WebRTC STUN Works Mechanically

The STUN discovery and hole-punching process follows a sequence of five precise steps:

1. Candidate Gathering Initiation: When a web application executes RTCPeerConnection.createOffer() or RTCPeerConnection.createAnswer(), the browser’s ICE agent checks its configured iceServers array for STUN and TURN URIs.
2. STUN Binding Request Dispatch: The browser sends a lightweight UDP packet known as a STUN Binding Request to the designated STUN server on port 3478.
3. NAT Gateway Translation: As the packet traverses the local router, the NAT engine assigns a public IP address and an outbound source port, recording this temporary binding in its state table.
4. Attribute Reflection: The STUN server inspects the inbound UDP header, extracts the source IP and source port, encodes them into an XOR-MAPPED-ADDRESS attribute, and transmits a STUN Binding Success Response back to the client.
5. ICE Candidate Exchange and Hole Punching: The client extracts its reflexive public address, attaches it to a Session Description Protocol (SDP) candidate string, and exchanges it with the remote peer via a signaling server. Both clients then execute direct UDP hole-punching checks to finalize media streaming.

Practical Considerations and Privacy Risks

While WebRTC STUN is critical for frictionless browser communications, it introduces distinct privacy, operational, and network challenges.

Real IP Exposure Past VPNs and Proxies

The most prominent vulnerability associated with STUN is the WebRTC IP leak. Standard browser proxy extensions redirect only HTTP and HTTPS traffic; they do not intercept low-level UDP requests dispatched by the browser's WebRTC subsystem. When a webpage executes a WebRTC script, the browser issues STUN requests directly through the default physical network interface, exposing the user’s real ISP-assigned IP address.

Running a regular WebRTC leak test helps identify whether your browser reveals underlying public credentials while an anonymizing tool is active. Similar to how DNS leaks expose domain queries outside an encrypted tunnel, STUN queries bypass browser-level routing. For users attempting to protect your browser against location leaks, locking down WebRTC handling via browser policies or system-wide VPN configurations is just as vital as spoofing geolocation APIs.

Incompatibility with Symmetric NAT

STUN is not a universal NAT traversal solution. In a symmetric NAT environment—common in corporate networks, mobile 4G/5G carriers, and university campuses—the router assigns a unique external port for every distinct destination IP and port contacted.

Because the port opened toward the STUN server is different from the port allocated when communicating with the remote peer, the reflexive candidate returned by the STUN server becomes invalid for direct hole punching. In these scenarios, WebRTC connection attempts fail over to TURN relays, which consume substantial bandwidth and increase infrastructure hosting costs.

IP Check

Check if your real public IP address is exposed through browser leaks, proxy misconfigurations, or network queries.

Test Your IP Address

WebRTC STUN vs. TURN vs. ICE

Understanding WebRTC connectivity requires distinguishing between the discovery protocol (STUN), the relay fallback (TURN), and the coordinating framework (ICE).

Summary

WebRTC STUN serves as the foundational mechanism for peer-to-peer real-time communication on the modern web, allowing browsers behind NAT routers to discover their public coordinates and establish low-latency media streams. While it minimizes server bandwidth and enables efficient conferencing, its ability to bypass browser-level proxies makes it a primary source of real IP leaks. Users and administrators prioritizing anonymity must monitor WebRTC candidate generation and enforce operating-system-level tunneling to keep private IP addresses protected.