What WebRTC Reveals About Your Local IP Address
WebRTC is the browser technology behind in-page video calls and direct file transfers. To connect two people without relaying everything through a server, it has to discover the addresses each side can be reached on — including private ones on the local network. A page can trigger that discovery, and historically it could learn addresses that a VPN was supposed to be substituting.
Modern browsers have narrowed this considerably, but it remains a leak worth checking specifically, because it happens inside the browser rather than on the network path where a VPN operates.
Why it needs your addresses
Direct connections are much better for real-time media than relayed ones, and finding a direct path requires knowing your addresses.
Two people behind separate routers cannot simply connect: each sees only a private address locally, and their public addresses belong to routers performing translation. The negotiation process gathers every plausible way to be reached — the private address on the local network, the public address as seen from outside, and a relayed path as fallback — then tests which combinations work.
Gathering the public address requires asking an external server what address the request appeared to come from. Gathering the private one requires enumerating the device’s own network interfaces. Both are legitimate parts of making a call connect, and both produce information a page can read.
What the exposure looks like
Three distinct pieces of information, with different significance.
Your private local address. Something like 192.168.1.20. On its own this is close to meaningless to an outsider — private ranges are reused everywhere, as covered in public vs private IP addresses. Its value to a tracker is as a small additional fingerprinting signal, and as a hint about the shape of your network.
Your public address, discovered outside the tunnel. This is the serious one. If the discovery process reaches its helper server without going through the VPN, the page learns your real public address while every other request appears to come from the VPN server. Your address substitution is defeated by a mechanism the VPN never saw.
Your IPv6 addresses. Often globally routable and per-device, which makes them a stronger identifier than a shared public address behind a router. This overlaps directly with the broader problem in why IPv6 is the leak people forget.
Why a VPN does not automatically stop it
A VPN operates on network routing; this happens in the browser’s own address enumeration.
If the browser lists the physical adapter’s addresses and reports them, no routing decision was involved — the addresses were read from the interface, not obtained by sending traffic anywhere. Routing everything through a tunnel does not change what interfaces exist.
The public-address discovery is different: that does involve traffic, and if the tunnel is carrying it properly the helper server sees the VPN’s address, which is the correct outcome. Problems arise when the discovery traffic uses a path the tunnel does not cover — an interface the client did not claim, or a protocol the tunnel does not carry.
This is a general lesson about leaks. A VPN covers what passes through the network stack it controls. Anything that reads device state directly, or escapes on a path outside the tunnel, is a separate problem needing a separate fix — which is why checking for leaks means testing several distinct things rather than one.
What browsers changed
The obvious version of this leak has largely been closed. Browsers now generally replace private addresses in the negotiation with randomised placeholder names rather than exposing the real ones, so a page cannot read your local address as easily as it once could.
Two caveats. The protections are about private address exposure and do not guarantee that public-address discovery follows your tunnel. And browser versions differ — an older build, or a less-maintained one, may behave the way things used to.
So the correct posture is neither “this is solved” nor “this is a gaping hole”. It is a specific check to run once per browser you use, and again after changing VPN clients.
How to test it
Use a page that reports what a script can actually see, with the VPN connected.
The interpretation:
- Only the VPN’s public address is reported. Working as intended.
- A private address is reported. Minor. It is a fingerprinting signal, not a deanonymisation.
- Your provider’s public address is reported. This is the failure that matters. Your address substitution is not holding.
Do this alongside the ordinary checks rather than instead of them, since a clean result here says nothing about whether your lookups are leaking or whether IPv6 is bypassing the tunnel.
What to do if it leaks
In rough order of preference:
Check the VPN client’s settings first. Some clients include a browser-leak or WebRTC protection option. If present, that is the cleanest fix because it leaves the technology working for calls you actually want to make.
Update the browser. The mitigations arrived over successive versions, and an old build is the most common reason a test reports what it should not.
Adjust the browser’s own configuration. Some browsers expose a setting controlling how aggressively addresses are hidden during negotiation. This is preferable to disabling the feature outright.
Disable WebRTC entirely, as a last resort. It works, and it breaks every in-browser call and any site relying on direct peer connections. Worth it only if you never use those and the leak persists.
Run the VPN on the router. Putting the tunnel on the router means there is no non-tunnelled path for discovery traffic to escape on, which removes the public-address version of the problem at the source. Private-address exposure is unaffected, since that is read from the interface either way.
Keeping it in proportion
This is one item on a checklist, not a reason to distrust VPNs. The private-address version is a weak signal that mostly contributes to fingerprinting, and fingerprinting works on people who are not using WebRTC at all.
The public-address version genuinely undoes what you are paying for, which is why it is worth the two minutes to verify. Test it once per browser, retest after client changes, and then stop thinking about it — the remaining privacy work is in accounts, cookies, and browser characteristics, none of which a VPN was ever going to address.