WebRTC: A Pet Flap in Your Fortress Wall

Armored door. Hardened windows. Alarms on every floor. You bought a VPN, switched on encryption, and now all your traffic runs through a sealed tunnel.

A pet flap sits in the wall. Opens straight onto the street. Anyone who walks past can crouch and peer into your living room. Installed for the dog. Dog isn't the only one who uses it.

Video calls are the dog. WebRTC is the flap. Ships with every modern browser. Open out of the box. Unlike the camera or microphone, nobody asks your say-so.

January 2015, Daniel Roesler put out a proof of concept: a webpage with twenty lines of JavaScript showing the real IP of a VPN user. Security crowd reacted the way it always does. Shock, anger, bug reports. Wasn't a bug. Was the blueprint. Ten years on, the flap is still wide open.

In brief: WebRTC fires UDP requests at STUN servers outside your VPN tunnel, laying bare your real IP. No permission needed. Not a bug. Architecture.

How the Flap Works

WebRTC lives for peer-to-peer links: video calls, voice, file transfers. For two machines to find each other across the internet, the protocol uses ICE, Interactive Connectivity Establishment. ICE tries every reachable path and picks the best one.

Paths are called candidates. Four types exist:

host stands for your local IP. 192.168.1.42. A raw fingerprint of your home network.

srflx, server reflexive, is your public IP found through a STUN server. STUN request travels over UDP. VPN tunnel? Proxy? SOCKS5? UDP slips past all of them. Straight out. Real IP comes back in the reply.

relay routes through a TURN server. Safest option. Slowest option. Almost never the default.

prflx, peer reflexive, surfaces during connectivity checks between peers.

Crux of the matter: a STUN request is a UDP packet your browser sends outside the VPN tunnel. Without asking. Without telling you. A webpage calls RTCPeerConnection, browser dutifully pings STUN servers, and every gathered IP lands in the ICE candidates object, readable from JavaScript. Roesler's twenty lines still work in 2025.

VPN tunnels encrypt TCP. SOCKS5 proxies route TCP. STUN runs on UDP and sidesteps both. Shown in 2018 and again in 2025: SOCKS5 against WebRTC is a dead letter. Browser VPN extensions leak until WebRTC is blocked by hand. Reddit's r/Adguard stumbled on this anew in September 2025. Same song, different year.

Koysha et al. published a cross-platform study at arXiv:2510.16168 in 2025, measuring WebRTC leaks across current builds of Chrome, Brave, Firefox, and Tor Browser on desktop and mobile. Same work ran the attack on a semi-trusted WiFi network: ICE candidates silently laid bare the internal network topology. No user action. No extra software. Just an open webpage.

Who Leaks, Who Doesn't

Browser	Desktop	Mobile
Chrome	Metadata leaks: mDNS stands in for the IP, but the foundation attribute still bleeds	LAN addresses and CGNAT addresses leak in the open
Brave	No outright IP leaks, but mDNS tokens hold steady within a session	Same as desktop
Firefox	Strong shielding	Android: internal IPs leak
Tor Browser	Full block on all leaks	Full block on all leaks

Chrome leads the pack in the worst way. On mobile, it spills not just local addresses but CGNAT addresses from the 100.64.0.0/10 range. Belong to your carrier. Finger your mobile provider and rough location inside its network. Mobile Chrome won't even let you shut WebRTC off through built-in settings.

Headline finding from the 2025 study: direct LAN leakage is shrinking, but fresh vectors like mDNS and CGNAT breed lasting privacy risks that call for protocol-level rework.

VPN testing in 2025 bore out the obvious: top-shelf services block 95 to 100% of WebRTC leaks. Budget VPNs often block nothing. Zero percent. You pay $3 a month and think you're shielded while your IP pours through the flap.

mDNS: A Band-Aid on a Gusher

Chrome M74 in 2019 started swapping local IPs for random mDNS tokens like a1b2c3d4-e5f6.local. Instead of 192.168.1.42, a site sees a throwaway UUID. Problem over?

Three problems say otherwise.

First: mDNS token stays fixed within a session. One string for the whole browsing stint. A tracking lever. Unnamed but followable.

Second: in 2022, a Chromium bug leaked the local IP through the foundation attribute in ICE candidates. Prflxion attack from Peer5 in 2023 widened that crack.

Third, the big one: mDNS only shields host candidates. Public IPs found through STUN are shielded by nothing. STUN request goes around your VPN, fetches your real IP, and mDNS can't touch it. Band-aid sits on a scratch while the gusher keeps flowing.

Visible Even Without an IP

Say every IP is hidden. STUN is blocked. mDNS works flawlessly. Marks remain.

Network fingerprint through NAT type. Mix of ICE candidate types maps your network. host and srflx means a plain home NAT. Only relay means symmetric NAT or a corporate firewall. Only host means a bare public IP. Fingerprint outlasts sessions and cookie wipes. Spoofing it without wrecking WebRTC altogether is nearly hopeless.

CGNAT as a carrier tag. Addresses in the 100.64.0.0/10 range point to a given mobile carrier and a rough zone within its network. Pair that with the MSS from TCP fingerprinting, covered in the server-side fingerprinting piece, and you get carrier identification neither WebRTC nor TCP reaches on its own.

STUN timing as geolocation. STUN reply from a Frankfurt server hitting in 3ms means you're in Germany. 150ms means Australia. Even if the IP is cloaked through relay, round-trip time betrays your geography. Stealth geolocation that works without a single IP.

Disabling trap. Turned off WebRTC? Firefox: media.peerconnection.enabled = false. You've now joined a sliver of users who bother. Browser just grew orders of magnitude more unique. Same trap as blocking JavaScript or killing cookies: shield becomes signal.

Triple clash. WebRTC shows an IP in country A. DNS resolver sits in country B. HTTP request arrives from country C. Three different answers to where you are, and the game is up. WHOX flags exactly this cascade through check C07. Each leak alone is a trifle. Together, a verdict.

Test your WebRTC right now. You might be startled: whox.com/test/

FAQ

My VPN claims it blocks WebRTC leaks. Is it lying? Depends on the VPN. Top-shelf services block 95 to 100% of WebRTC leaks. Budget ones often block nothing. Browser VPN extensions leak until WebRTC is killed by hand. Only way to know: test.

How do I turn off WebRTC? Firefox: about:config, then media.peerconnection.enabled set to false. Chrome: only through an extension like WebRTC Leak Prevent. Mobile Chrome: you can't. Bear in mind the trap: shutting off WebRTC is itself a fingerprint.

Does Tor Browser truly fix this? Yes. Only browser tested in 2025 that steadily blocks every form of WebRTC leakage across all platforms. Trade-off is speed and compatibility.

What does WHOX check? WHOX reads all fp.rtc.* fields: host, srflx, relay candidates, NAT type, ICE metadata. Test A09 zeroes in on WebRTC leaks and cross-checks them against 300+ other signals.

---

Quick rundown of WebRTC leaks. For the full technical deep-dive with academic sources and ICE/STUN/TURN mechanics, see WebRTC and DNS: The Leaks Nobody Closes.

Read Next

• WebRTC and DNS: Full Research for academic data, ICE mechanics, cross-platform tests
• Server-Side Fingerprinting: 4 Layers Before JavaScript
• DNS-over-HTTPS: The Privacy That Isn't
• What Actually Works: A Protection Guide

---

WHOX - We tell real signals from manufactured ones. Check your fingerprint at whox.com and find out what signals leak from your browser and how unique you are.