Is Your VPN Leaking? WebRTC Leaks, DNS Leaks and What Websites Still See

A VPN creates an encrypted tunnel from your device to a VPN server, and your traffic leaves the internet from there. Websites see the VPN server's IP address instead of yours, and your ISP sees only an encrypted connection to the VPN.

That hides three things:

• Your IP address, and with it your ISP's name and the approximate location that IP geolocation would reveal.
• Which sites you visit, from your ISP or the Wi-Fi network you're on.
• Unencrypted traffic contents from the local network — less important now that almost all web traffic is HTTPS anyway.

It does not hide:

• Who you are when you log in. Signing into Google, Facebook or your bank identifies you regardless of IP.
• Cookies and browser fingerprints. Trackers that recognise your browser keep recognising it through a VPN.
• Anything from the VPN provider itself. You've moved trust from your ISP to the VPN company; it can see the same metadata your ISP used to.

And it only hides your IP if all of your traffic actually goes through the tunnel. The two classic ways it doesn't are WebRTC and DNS.

WebRTC is the browser technology behind video calls, voice chat and peer-to-peer file transfer in sites like Google Meet. To connect two browsers directly, each one has to discover the addresses it can be reached at and share them. This process is called ICE, and the addresses it finds are ICE candidates.

To find your public address, the browser sends a small request to a STUN server, which replies with the IP and port it saw the request come from. Any website can start this process with a few lines of JavaScript — no permission prompt, because no camera or microphone is involved:

const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] })
pc.createDataChannel('')
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate)
pc.createOffer().then((o) => pc.setLocalDescription(o))

A WebRTC leak happens when that STUN request goes out *outside* the VPN tunnel — typically with split-tunnelling VPNs, VPN browser extensions (which only proxy the browser's HTTP traffic, not WebRTC's UDP), or VPN clients that don't route all traffic. The STUN server sees your real public IP, and the page that ran the script reads it from the candidate list.

Modern browsers have reduced the damage. Since around 2019, Chrome, Firefox and Safari hide local network addresses (like 192.168.1.20) behind random .local mDNS names. But the public address returned by STUN is still exposed if the request bypasses the VPN.

1. Connect to your VPN.
2. Open the Privacy Check. It shows the IP the server sees — this should be the VPN's address — and runs the WebRTC test above in your browser.
3. Compare. If WebRTC reports an IP other than the one the server sees, and that IP belongs to your ISP, you have a leak.

To be sure which IP is your real one, disconnect the VPN and note the address on the homepage, then reconnect and test again.

Some results are expected and harmless:

• Only the VPN IP appears. No leak.
• WebRTC returns nothing. Your browser or an extension is blocking WebRTC, which also prevents leaks (and may break video calls).
• An IPv6 address appears that you don't recognise. Check it on the homepage — if your VPN doesn't tunnel IPv6 and your ISP gives you IPv6, this is your real address leaking over IPv6 rather than WebRTC as such.

Before your browser connects to a website, it looks up the site's IP address via DNS. If those lookups go to your ISP's resolver instead of through the VPN, your ISP still sees every domain you visit, even though the connections themselves are tunnelled. That's a DNS leak.

It happens when the operating system keeps using the resolver configured on your network adapter, when IPv6 DNS bypasses an IPv4-only tunnel, or when Windows "smart multi-homed name resolution" sends queries out every interface at once.

Testing for a DNS leak needs a different technique from a WebRTC test. A test site makes your browser look up unique random subdomains under a domain it controls, then checks its own authoritative server logs to see which resolvers asked. If any of those resolvers belong to your ISP rather than your VPN provider, DNS is leaking. Our Privacy Check doesn't run this test; dedicated DNS leak test sites do.

Fixes, in order of reliability:

• Use the VPN client's own "DNS leak protection" or "use VPN DNS only" setting.
• Disable IPv6 on the VPN connection if the VPN doesn't support IPv6.
• Turn on DNS-over-HTTPS in the browser (Firefox and Chrome both support it). DoH encrypts lookups end to end, so even if they leave outside the tunnel, the ISP can't read them — though the DoH provider can.

Use the VPN's desktop app instead of a browser extension. A system-level VPN routes all traffic, including WebRTC's UDP, through the tunnel. This fixes the root cause.

Firefox: go to about:config and set media.peerconnection.enabled to false to disable WebRTC entirely. To keep WebRTC but stop it using anything other than the default route, set media.peerconnection.ice.default_address_only to true.

Chrome and Edge: there's no built-in switch. The official "WebRTC Network Limiter" extension from Google, or uBlock Origin's "Prevent WebRTC from leaking local IP addresses" setting, restricts which interfaces WebRTC may use.

Brave: Settings → Privacy and security → WebRTC IP handling policy → "Disable non-proxied UDP".

Safari: WebRTC only gathers candidates after a site has camera or microphone permission, so ordinary pages can't run the silent test above. Leaks are rare in practice.

Retest with the Privacy Check after each change. If video calls stop working, the policy is too strict for that browser; switch to the VPN's own app instead.

Even with no leaks, every request carries information:

• The VPN server's IP, which is easy to recognise. VPN servers sit in hosting networks and commercial databases list their address ranges, which is why streaming services and banks often block or challenge VPN traffic. The IP Reputation check shows how an IP is classified.
• Your browser's User-Agent, language and time zone. A browser whose time zone says Asia/Kolkata on an IP that geolocates to Amsterdam is an obvious VPN user.
• A browser fingerprint, built from screen size, fonts, graphics card rendering and dozens of other attributes. The EFF's Cover Your Tracks project found most browsers have a unique or near-unique fingerprint.
• Proxy headers. Some proxies, particularly corporate ones and misconfigured servers, add X-Forwarded-For or Via headers containing your original IP. The Privacy Check flags these.

A VPN is a tool for one job — hiding your IP from sites and your browsing from your network. For tracking protection, combine it with a browser that blocks third-party trackers and fingerprinting (Firefox's strict mode, Brave, or Safari's defaults), and log out of accounts you don't want associated with the browsing.