WebRTC Leaks Explained

WebRTC and VPN Network Paths

Web Real-Time Communication (WebRTC) supports browser calls and peer-to-peer data transfer. Connection setup can expose candidate addresses to the application, making it useful to check how those addresses relate to your expected network route.

WebRTC is supported by common browsers including Chrome, Firefox, Safari, and Edge, powering video conferencing, low‑latency gaming, and instant file sharing directly in the browser. It is the backbone of Google Meet, Discord, and Zoom's web client. WebRTC uses ICE candidates to describe possible network paths for a connection. A web application may receive candidate addresses, so compare them with the routes you expect when using a VPN.

A VPN changes the network path for traffic it routes; it does not make a user anonymous. The route used for a WebRTC candidate depends on the browser, operating system, VPN configuration, and address family. A public candidate can be the VPN's egress address or a relay, so it is not by itself proof of a VPN bypass.

Why Results Vary

Candidate behavior and available controls vary by browser, operating system, version, VPN app, and network. An estimate based on a different setup cannot tell you which route your browser uses; check the same device and connection you plan to use.

Quick check: Use Zunavek's WebRTC Leak Test to record candidates, then compare results with VPN-off and VPN-on baselines for IPv4 and IPv6.

Anatomy of a WebRTC Leak

To assess a WebRTC privacy issue, understand how the browser gathers and shares possible network paths. The process uses the Interactive Connectivity Establishment (ICE) framework, a negotiation process designed to find a working connection between peers.

How ICE, STUN, and TURN Work

NAT is common in home and office networks, and can make direct peer connections difficult. ICE gathers candidate addresses and tests possible paths so the peers can select a connection (MDN Web Docs).

STUN and TURN servers can help ICE discover or establish those paths:

• STUN (Session Traversal Utilities for NAT): A STUN server can report the address and port from which it received a request, allowing ICE to form a server-reflexive candidate. That address reflects the route to the STUN server; depending on the network and VPN configuration, it may be a direct or VPN egress address.
• TURN (Traversal Using Relays around NAT): A relay can carry WebRTC traffic when a direct connection is unavailable or not selected. For a connection using a relay candidate, the peer receives that traffic through the relay endpoint. Other candidates may still be gathered, and using TURN is not by itself a guarantee about what the application can see (MDN Web Docs).

ICE Candidate Types

During ICE negotiation, your browser gathers a list of potential addresses called "ICE candidates." They describe possible connection paths; one public candidate alone does not show whether a VPN was bypassed. Click each type below to see what it represents (MDN Web Docs):

Assess a candidate against the route you expect, not against a blanket rule that every public address is a leak. Record VPN-off and VPN-on baselines in the same browser and network, and compare IPv4 and IPv6 separately. If a VPN-on candidate matches the direct baseline when that traffic should be tunneled, investigate the VPN route and split-tunnel settings; the match alone is not conclusive proof of a bypass.

Check IPv4 and IPv6 Separately

A device may have both IPv4 and IPv6 connectivity, and a VPN may handle the two address families differently. Check the VPN provider's routing documentation and compare IPv4 candidates with the IPv4 baseline, and IPv6 candidates with the IPv6 baseline. A public IPv6 address can reveal network information, but it does not by itself identify a particular device or prove a VPN bypass.

mDNS and Local IP Obfuscation

A host candidate describes a local interface address. Depending on browser behavior, a local address may be obscured with an mDNS name rather than exposed as a private IP address.

mDNS handling varies and local-address obfuscation does not establish which public route a server-reflexive candidate uses. Check the candidate type and compare public addresses with direct and VPN baselines.

What Candidate Addresses Can Reveal

If an application receives a candidate outside the route you expect, it may learn additional network information. The implications depend on the address, the application, and what other information is available.

1. Public Addresses and Linkability

A direct public address can reveal network or approximate location information to an application that receives it. An IP address alone does not establish a person's identity or precise location; identification depends on other signals and records as well.

Sites may combine network information with account or device signals, but a candidate on one page does not by itself link activity across sites or identify a person.

2. Network Location Signals

A web application using WebRTC may receive candidate addresses in addition to the address it sees for ordinary page requests. A difference can be a reason to inspect routing, but services vary in whether they use this information and what decisions they make from it.

3. Local Network Address Information

If a browser exposes a private host candidate, it may disclose some local addressing information to the application. The address alone does not show that a device is reachable from the internet or grant access to internal services.

4. Limits of an Address Check

Seeing an address in an ICE candidate does not mean a site can reach that device or scan other devices on a private network. Network routing, firewalls, and browser permissions still apply; evaluate a candidate as network information, not proof of access or attack.

5. Other Browser Signals

WebRTC candidates describe network paths. They do not measure microphone characteristics or establish a hardware identity. Audio processing can expose separate fingerprinting signals through the Web Audio API; this is a different mechanism from gathering ICE candidates (Web Audio specification).

Browser‑Specific Checks

Browser controls and settings change across products, platforms, and releases. Use the notes below to check a route and consult current browser and VPN documentation before changing advanced settings:

VPN and Network Checks

VPN routing and operating-system firewall rules can affect WebRTC traffic, but their behavior depends on the app, device, and configuration. Review the provider's documentation and verify the candidate routes on the device you use.

VPN Settings to Verify

A feature name alone does not show which browser traffic it covers. Check how the settings work on your operating system and test the browser's candidates:

1. WebRTC or IP protection: If your VPN app advertises a related control, read its documentation to see whether it changes browser candidate handling, network routes, or something else.
2. Kill switch: Check what traffic it blocks, on which devices, and under what conditions. A kill switch is not proof that every candidate uses the VPN route.
3. Split tunneling: An excluded browser may use a direct route. Confirm which apps and address families are included, then compare direct and VPN-on baselines.

Firewall Rules

Firewall rules can restrict traffic, but STUN and TURN services are not limited to one short port list. Blocking selected ports does not prove that WebRTC follows a VPN route and may disrupt calls. Use rules only when you understand their scope, then verify the actual routes and candidates.

Mitigation Strategy Comparison

Not every solution fits every user. Use the sortable table below to compare approaches based on your needs:

How to Test for WebRTC Leaks

Candidate output does not label a route as safe or leaked. Compare the same browser and network with the VPN off and on:

1. Direct baseline: With the VPN off, use Zunavek's WebRTC Leak Test and record the IPv4 and IPv6 candidates it shows, if present.
2. VPN baseline: Turn on the VPN and repeat the test in the same browser, device, and network.
3. Analyze the results:
   • Compare IPv4 candidates with IPv4 and IPv6 candidates with IPv6. Check each VPN-on address against the route the VPN provider documents; a VPN egress or relay address can be expected.
   • If an address matches the direct baseline when that traffic should be tunneled, review split-tunnel and VPN routing settings. Treat the match as a signal to investigate, not proof by itself.

For another comparison, you can also use BrowserLeaks.com and IPLeak.net. Compare what each tool displays with the documented routes for your setup.

Limits of WebRTC Privacy Controls

A control that changes candidate output does not establish how all browser traffic is routed. Check the connection behavior as well as the displayed addresses.

Media over QUIC (MoQ)

Work on MoQ concerns media delivery over QUIC. It does not make an ICE candidate test a general test of streaming privacy or VPN coverage; each application and transport needs its own routing checks.

Media Permissions

Camera and microphone access are separate from candidate gathering. Review site permissions and revoke access you no longer need. A candidate test does not assess what a permitted calling application records or how it processes media.

Address Spoofing Is Not Routing Protection

Replacing an address shown to a page does not change the network route used by packets. A fabricated candidate can prevent a connection from working, and a tool that shows a substitute address does not prove anonymity. Prefer documented browser controls and VPN routing settings, then test whether calls still work as intended.

Frequently Asked Questions