What a WebRTC leak is and how to read the test

Candidates: the addresses a browser offers

WebRTC uses ICE (Interactive Connectivity Establishment, RFC 8445) to find a working path between two devices that may both sit behind routers. Each possible address and port is called a candidate. RFC 8445 defines the main kinds, and MDN lists the same values a page sees in the type property:

• host: an address on the device itself, including those of physical interfaces and logical ones such as a VPN interface.
• srflx (server reflexive): the public address and port a NAT allocated when the device sent a packet to a STUN server.
• prflx (peer reflexive): the same idea, but learned from the other peer instead of a server.
• relay: an address on a TURN server that forwards the media when no direct path works.

How STUN reveals your public address

STUN (Session Traversal Utilities for NAT, RFC 8489) is a small request-and-answer protocol. The browser sends a Binding request to a STUN server. When the packet passes through a NAT, its source becomes the public address and port the NAT chose, which RFC 8489 calls the reflexive transport address. The server copies that address into its reply, in an attribute named XOR-MAPPED-ADDRESS.

So a STUN reply tells the browser the public address of the outermost NAT on the path to that server. Normally this is the same address every website sees. The question the leak test asks is whether it is.

When it becomes a leak

RFC 8828, which sets rules for how browsers handle IP addresses in WebRTC, describes three kinds of extra information WebRTC can reveal:

• If the device has more than one route to the internet, additional public addresses. With a split-tunnel VPN, one that sends only some traffic through the tunnel, WebRTC can find not only the VPN's public address but also the ISP address the VPN runs over.
• Behind a NAT, the device's private addresses, often RFC 1918 addresses such as 192.168.1.23.
• Behind a configured web proxy that still allows direct internet access, the real public address, because STUN checks bypass the proxy.

Private addresses and the mDNS fix

A private address is not your public IP, but RFC 8828 explains why it still matters. Private IPv4 addresses can carry up to 24 bits of identifying information and rarely change, which makes them useful for fingerprinting, and they can let a site link a normal window and a private window on the same device.

Browsers address this in two ways. RFC 8828 defines four handling modes, from enumerating all addresses (mode 1, allowed only with user consent, which a browser may tie to camera or microphone permission) to forcing traffic through a proxy (mode 4). Without consent, mode 2 should be used: follow the normal route and reveal only that interface's addresses. A browser can also hide local addresses behind random names ending in .local, an approach described in an IETF draft on Multicast DNS (mDNS) candidates. The page then sees something like 1f4712db-ea17-4bcf-a596-105139dfd8bf.local instead of 192.168.1.23.

What the result does and doesn't mean

No WebRTC leak means WebRTC shows the same public address every website already receives. It does not mean the connection is anonymous. A leak result means a page can learn an address you might have expected to be hidden; whether that matters depends on why you use a VPN or proxy in the first place.

Fixes depend on the cause: a VPN app that routes all traffic through the tunnel, or a browser setting that limits WebRTC to the default route, both stop extra public addresses from appearing. Running the test again after a change confirms it.