How WebRTC can reveal your real IP behind a VPN

What WebRTC is

WebRTC (Web Real-Time Communication) is a set of browser features for video calls, voice chat and direct file transfer. It lets two browsers talk to each other without sending all the data through a central server. Video meetings, browser-based games and many support chat tools rely on it.

For two devices to connect directly, each has to learn the addresses where it can be reached. That discovery process is the source of the privacy problem. It is not a bug in your VPN. It is a normal feature of the browser that happens to handle network addresses.

How the leak happens

WebRTC gathers possible network routes, called ICE candidates. There are three kinds. Host candidates are addresses on your own device or local network. Server-reflexive candidates are your public address as seen from outside, learned by asking a STUN server. Relay candidates go through a TURN server that forwards traffic.

Any web page can start this process with a few lines of JavaScript, without showing a call window and without asking. The page then reads the list of candidates. If the browser sends its STUN request outside the VPN tunnel, or if it lists an address the VPN does not cover, the page sees an address that is not the VPN's. That is a WebRTC leak.

• A VPN that tunnels all traffic at the operating system level usually catches the STUN request too, so the public address matches the VPN's.
• A browser-level proxy, or a VPN extension that only handles web requests, may not cover the UDP traffic WebRTC uses, so the STUN request can go out over your real connection.
• Split tunnelling, where some apps or addresses bypass the VPN, can send the browser's traffic around it.
• IPv6 is a frequent cause. If your VPN only handles IPv4, the browser may still report a public IPv6 address from your real provider.

What mDNS changed

Older versions of WebRTC exposed the local network address of your device, such as 192.168.1.20, to any page that asked. That can help a site tell devices apart and reveal details about your network. Modern browsers now hide it. Instead of the real local address, a host candidate carries a random name ending in .local that is resolved only inside your local network. This is called mDNS obfuscation, and Chrome, Firefox, Safari and Edge all use some form of it.

Two points matter. First, mDNS protects the local address only. It does nothing about the public address a STUN server reports, which is the one a VPN user cares about. Second, browsers can still reveal real local addresses once a page has been granted camera or microphone permission, because a call is then clearly intended. So the common advice to grant media permissions only to sites you trust still applies.

Test your connection first

Before changing anything, find out whether you have a problem. Connect your VPN or proxy, open the WebRTC leak test and press the button. It collects the addresses your browser reports and compares them with the address this site sees on the normal connection. If they belong to different networks, you have a leak. If they differ only inside the same network provider, our test does not count it, because that is usually just a second address of the same VPN.

Also run the DNS leak test, which checks a separate way your location can show, and compare against What's my IP to confirm the address websites see is the one you expect. Repeat the test after each change you make, with the VPN connected.

Fixing it in Chrome

Chrome has no setting in its normal menus for this. The option exists in its extension programming interface as the WebRTC IP handling policy, and extensions can change it. The strictest value, disable_non_proxied_udp, tells Chrome to use WebRTC only when traffic can go through a proxy, and otherwise not at all. A less strict value, default_public_interface_only, makes the browser use only the default public route rather than listing every interface.

In practice, you install a reputable extension that sets this policy, check what permissions it asks for, and then run the test again. Some VPN apps include this protection in their own browser extension. Be aware that a stricter policy can break video calls on sites you use.

Fixing it in Firefox

Firefox lets you change this without an extension. Type about:config in the address bar, accept the warning, and search for the settings below.

• media.peerconnection.enabled set to false turns WebRTC off completely. This is the most effective fix, and it also stops video calls in the browser.
• media.peerconnection.ice.default_address_only set to true limits the browser to the default route.
• media.peerconnection.ice.no_host set to true stops it listing host addresses.

Firefox can change these preference names between versions, so run the leak test after any change to confirm it took effect. Resetting a value restores the default.

Fixing it in Safari

Safari applies mDNS to local addresses and, in recent versions, only reveals them after a page has media permission. Apple does not provide a simple setting that stops WebRTC from reporting a public address through a STUN server. In Safari, the dependable approach is to use a VPN that tunnels all system traffic, including IPv6, and then confirm the result with the test. If your VPN is only a browser add-on, it is unlikely to cover WebRTC.

Content blockers and extensions that target WebRTC exist for Safari, but their coverage varies, so verify rather than assume. If you need guaranteed isolation, consider using a different browser for that task.

Fixing it in Edge

Microsoft Edge is built on the same engine as Chrome, so the same WebRTC policy applies and the same extension approach works. Install an extension that sets the WebRTC IP handling policy, check what it asks permission for, and run the leak test again. Some Edge versions have also offered privacy flags related to WebRTC, but their names and availability change, so check the current version instead of relying on a flag name from an old guide.

Organisations can set this policy centrally through browser management settings. If you use a work-managed device, the policy may already be set for you, or you may not be allowed to change it.

A note on other browsers: Brave, which is also Chromium-based, includes its own setting for WebRTC IP handling in its privacy settings. If you want a browser where this is a normal menu option, that is worth knowing.

Fix the cause, not only the browser

• Use a VPN or proxy setup that covers all traffic from your device, not only web requests from one app.
• Turn on the VPN's IPv6 leak protection, or disable IPv6 on the network adapter if the VPN does not handle it.
• Turn off split tunnelling for the browser you are testing.
• Keep the browser updated, because WebRTC privacy behaviour has changed over the years.
• Do not grant camera or microphone permission to sites you do not trust.

A clean test result is a snapshot. It shows what your browser reports now, with your current settings. Repeat it after browser or VPN updates.