WebRTC Leak Test — PingThat

Q: How do I actually disable WebRTC IP leaks?

Three approaches with different trade-offs: (1) Disable WebRTC entirely — Firefox: set media.peerconnection.enabled=false in about:config (breaks video calls); Chromium: no built-in toggle, requires extension like uBlock Origin's 'Prevent WebRTC from leaking local IP' setting. (2) Bind WebRTC to a specific interface — set media.peerconnection.ice.default_address_only=true in Firefox; some VPN clients (Mullvad, ProtonVPN) provide WebRTC kill switches that block STUN traffic outside the tunnel. (3) Force WebRTC through proxy — only works if the VPN runs as a system-level kill-switch firewall blocking direct UDP. Approach (1) is the most reliable for privacy but breaks WebRTC features entirely; approach (2) requires careful VPN configuration and per-browser tuning; approach (3) requires VPN client support.

Q: Is the test result stored anywhere?

No. The test creates a local RTCPeerConnection (W3C WebRTC 1.0 spec) using a STUN server only to discover candidates, reads the resulting ICE candidates synchronously in the browser, and renders them in the page. No data is sent to a server, no candidates are logged, and no reports are stored. The connection is torn down immediately after enumeration. WebRTC Security Architecture (RFC 8827 Rescorla, January 2021) requires user consent for media capture; this test never requests microphone or camera access — only the connectivity-establishment subset of the API runs.

WebRTC Leak Test — ICE Candidates, mDNS Obfuscation & VPN Bypass Detection

WebRTC peer connections establish via ICE (Interactive Connectivity Establishment, RFC 8445 Keränen, Holmberg & Rosenberg, July 2018), which gathers four candidate types and shares them in SDP offers: host (interface IPs visible to the OS — including private RFC 1918 ranges), server-reflexive or srflx (public IP discovered by querying a STUN server), peer-reflexive (discovered during connectivity checks), and relay (TURN-allocated). Even with a VPN active, the browser may discover and expose IPs outside the tunnel if the VPN doesn't bind WebRTC traffic to the tunnel interface. Chrome 76+ (default August 2019, after experimental Chrome 73 March 2019), Firefox 75+ (April 2020 for outgoing obfuscation; Firefox 68 July 2019 added incoming-candidate handling only), and Safari iOS 12.2+ (March 2019) obfuscate host candidates with mDNS .local hostnames per the IETF draft-ietf-mmusic-mdns-ice-candidates work — random UUIDs that resolve only on the local subnet via mDNS (RFC 6762). This tool creates a real RTCPeerConnection (W3C WebRTC 1.0), enumerates the ICE candidates as the browser would expose them in an actual SDP offer, and classifies each candidate type so you can see exactly what a remote peer would learn about your network.

How to run a WebRTC leak test

Open the test in your browser — it triggers a real ICE candidate gathering exchange against a STUN server (no media capture).
Review the candidate list: each entry shows type (host/srflx/relay), IP family (4/6), and value. Public IPs from srflx that don't match your VPN exit node indicate a leak.
Toggle VPN connection state and re-run — the host candidates should change to the VPN-tunnel interface IP only; srflx should match the VPN exit public IP.
If your real IP still appears: bind WebRTC to a specific interface (Firefox `media.peerconnection.ice.default_address_only=true`), or disable WebRTC entirely (Firefox `media.peerconnection.enabled=false`).

Common use cases

Validating a new VPN setup doesn't leak host or srflx candidates outside the tunnel — critical before joining a sensitive video call.
Confirming Chrome 76+ mDNS host obfuscation is active (host candidates should appear as .local hostnames, not literal LAN IPs).
Auditing a corporate browser profile for WebRTC leaks before deploying to journalists, activists, or remote field staff.
Diagnosing why peer-to-peer WebRTC sessions fail behind a strict NAT — relay candidates indicate TURN fallback is needed.

Frequently asked questions

Why does WebRTC leak my real IP even behind a VPN?

ICE (RFC 8445 Keränen/Holmberg/Rosenberg, July 2018) gathers candidates from every available interface and queries STUN over UDP. If the VPN doesn't bind WebRTC traffic to the tunnel interface, STUN can take a direct path, exposing the real public IP. Host candidates expose LAN IPs unless mDNS-obfuscated.

What are mDNS host candidates and how do they protect privacy?

Chrome 76+ (default August 2019), Firefox 75+ (April 2020 outgoing; FF68 July 2019 incoming-only), Safari iOS 12.2+ replace literal host IPs (192.168.1.42) with random UUID.local mDNS hostnames per IETF draft-ietf-mmusic-mdns-ice-candidates. Only resolves on local subnet via RFC 6762 mDNS. Limitation: only obfuscates host candidates — srflx (STUN public IP) still leaks.

How do I actually disable WebRTC IP leaks?

Three options: (1) Disable entirely — Firefox media.peerconnection.enabled=false, Chromium needs uBlock Origin extension. (2) Bind to one interface — Firefox media.peerconnection.ice.default_address_only=true; some VPNs (Mullvad, ProtonVPN) provide WebRTC kill switches. (3) System-level UDP kill switch in VPN client config.

Is the test result stored anywhere?

No. RTCPeerConnection runs locally in the browser, ICE candidates render synchronously, no data sent server-side, connection torn down immediately. WebRTC Security Architecture (RFC 8827 Rescorla, January 2021) consent model never triggered — no microphone or camera access requested.

Why might the test show different results on different runs?

Three sources of variability: (1) Network interface changes (VPN connect/disconnect, Wi-Fi↔Ethernet switch, DHCP renewal) change host candidates. (2) STUN server throttling at peak load reduces srflx candidates. (3) mDNS rollout state — older browsers (pre-Chrome 76, pre-FF75) show literal IPs instead of .local hostnames.

How WebRTC leaks work — and why mDNS only solves part of the problem

When a website calls `new RTCPeerConnection()` and triggers ICE gathering, the browser binds to every available network interface (Wi-Fi, Ethernet, cellular, VPN tunnel) and queries STUN servers from each. The four candidate types defined in RFC 8445 reveal increasingly less about the network: host candidates list the literal IPs the OS reports for each interface; srflx candidates show the public IP each interface presents to the STUN server (which may differ from the host IP if NAT is in play); prflx candidates emerge during connectivity checks; relay candidates route through TURN with no source IP visible. The leak happens because: (1) STUN is UDP, and many VPN clients only force TCP through the tunnel; (2) host candidates expose private RFC 1918 IPs that reveal LAN topology; (3) srflx candidates expose the public IP of any interface that can reach STUN, including the unencrypted ISP interface. The mDNS Obfuscation work (Borst, Fablet, Uberti & Wang, IETF draft) replaces literal host IPs (192.168.1.42) with random .local hostnames that only resolve on the same subnet — but srflx candidates remain unaffected, so a VPN-bypassing STUN query still leaks the real public IP. WebRTC Security Architecture (RFC 8827 Rescorla, January 2021) defines the consent model — this tool never requests media access, only the connectivity-establishment subset of the API.

ICE candidate enumeration per RFC 8445 (host, srflx, prflx, relay types)
IPv4 and IPv6 candidate detection separately
Public vs private IP classification (RFC 1918 + RFC 4193 + RFC 6598 ranges)
mDNS host obfuscation detection (Chrome 76+ / Firefox 75+ / Safari iOS 12.2+)
STUN reachability test (probes Google STUN and reports response)
Re-runnable per session (changes after VPN connect/disconnect visible immediately)

Free. No signup. Browser tools (subnet, JWT, password strength) run locally; lookup tools query public APIs (Cloudflare DoH, RDAP, certificate logs). Full per-tool breakdown at /methodology/.

Sources (7)

Alvestrand, H. (2021). Overview: Real-Time Protocols for Browser-Based Applications. RFC 8825, IETF (January 2021 — WebRTC suite overview).
Uberti, J., Jennings, C., & Rescorla, E. (Eds.) (2021). JavaScript Session Establishment Protocol (JSEP). RFC 8829, IETF (January 2021 — SDP offer/answer model used by WebRTC).
Keränen, A., Holmberg, C., & Rosenberg, J. (2018). Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal. RFC 8445, IETF (July 2018 — Internet Standards Track; obsoletes RFC 5245; defines host/srflx/prflx/relay candidate types).
Rescorla, E. (2021). WebRTC Security Architecture. RFC 8827, IETF (January 2021 — companion to RFC 8826 threat model).
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., & Lear, E. (1996). Address Allocation for Private Internets. RFC 1918, IETF (private IPv4 ranges 10/8, 172.16/12, 192.168/16).
Borst, J. de, Fablet, Y., Uberti, J., & Wang, Q. (2020). Using Multicast DNS to Protect Privacy When Exposing ICE Candidates. IETF draft-ietf-mmusic-mdns-ice-candidates; default in Chrome 76 (August 2019, after experimental Chrome 73 March 2019), Firefox 75 (April 2020 for outgoing obfuscation; Firefox 68 July 2019 added incoming-candidate handling only), and Safari iOS 12.2+ (March 2019); obfuscates host candidate IPs via .local mDNS hostnames.
Cheshire, S., & Krochmal, M. (2013). Multicast DNS. RFC 6762, IETF (February 2013 — link-local name resolution used for .local hostnames).

These are the IETF RFCs, NIST publications, and W3C standards the tool implements or queries. Locate them on the IETF Datatracker (datatracker.ietf.org) or the official standards body.