IP leak, DNS leak, WebRTC leak: which is which
An IP leak means traffic bypassed the tunnel entirely. A DNS leak means lookups did. A WebRTC leak means the browser volunteered an address through an API. An IPv6 leak is an IP leak affecting only one address family, and it is the most common of the four.
4 min read
Four different failures share one word, and they expose different things to different parties. Sorting them out makes it much easier to decide which ones you actually need to care about.
IP leak
What: traffic is taking the normal route instead of the tunnel.
Who sees what: your network operator sees your destinations. Websites see your real address.
Causes: the tunnel is down while the client says otherwise; the routing table prefers the physical adapter; split tunnelling is configured more broadly than intended; the kill switch is absent and the tunnel dropped.
Test: open what is my IP. If it shows your address, this is what you have.
Severity: total. The VPN is providing nothing.
DNS leak
What: traffic goes through the tunnel; lookups do not.
Who sees what: whoever runs the resolver holds a timestamped list of every domain you opened. Websites see the VPN's address and are unaffected.
Causes: Windows asking every interface at once by design; a client that sets a tunnel resolver without removing the existing ones; Android Private DNS; a browser using its own encrypted DNS.
Test: the DNS leak test.
Severity: high, and frequently underrated. Encrypted traffic to a site your provider already watched you look up protects much less than it appears to.
WebRTC leak
What: the browser reports the addresses your machine can be reached on to a page that asked.
Who sees what: the website, and any script it loads. Your network operator learns nothing new.
Causes: an API designed to discover addresses, doing so.
Test: the WebRTC leak test.
Severity: moderate, and specific. It defeats address-based geolocation for a site actively checking, and it is invisible to everyone else.
IPv6 leak
What: the tunnel routes IPv4 only, and IPv6 traffic takes the normal path.
Who sees what: everything an IP leak exposes, for the portion of traffic using IPv6 — which on a dual-stack connection is most large sites, and on an IPv6-only mobile network is nearly everything.
Causes: a provider that does not route IPv6, and a client that does not blackhole it.
Test: compare curl -4 and curl -6 against an address service, or use a
test that reports both families.
Severity: total for the affected traffic, and the highest chance of going unnoticed, because tools that only report IPv4 show a clean result.
Which matters for which concern
| Your concern | Leaks that matter |
|---|---|
| Network operator seeing my browsing | IP, DNS, IPv6 |
| Websites knowing my real address | IP, WebRTC, IPv6 |
| Being in the wrong apparent country | IP, WebRTC, IPv6 |
| Safety on a shared network | IP, DNS, IPv6 |
WebRTC is the only one that matters to websites and not to the network. DNS is the only one that matters to the network and not to websites. The other two matter to both.
The order to test in
- IP. If this leaks, nothing else is worth checking yet.
- IPv6. The most commonly missed, and it is an IP leak wearing a disguise.
- DNS. The most revealing of the ones that leave traffic tunnelled.
- WebRTC. Browser-specific, worth doing per browser.
What closes them
- IP: a working tunnel with a full-tunnel route, plus a kill switch so a drop fails closed.
- IPv6: route
::/0through the tunnel, or have the client blackhole it. - DNS: leak protection in the client, plus turning off browser-level encrypted DNS and Android's Private DNS while connected.
- WebRTC: a browser preference on Firefox, an extension elsewhere.
Four checks, four fixes. Doing them once after any configuration change is the whole practice, and the failure mode of skipping it is that everything looks exactly the same either way.
Two more things people call leaks
Traffic analysis. Your network operator can see the volume and timing of what crosses the tunnel even though it cannot read any of it. That is not a leak — it is the residual metadata every encrypted channel has — but it gets described as one.
The provider seeing your traffic. Also not a leak. A VPN moves visibility from your network operator to your provider by design, and calling that a failure confuses the mechanism with a fault. What matters there is what the provider records, which is a policy question rather than a technical one.
Keeping these separate from the four real leaks is useful, because the four have fixes and these two have trade-offs.
Why leaks survive so long
Every one of these failures is silent. Pages load, video plays, the client shows connected, and nothing anywhere indicates that a portion of traffic went the wrong way. There is no error, no warning and no degradation in the experience.
That is why testing has to be deliberate and periodic rather than triggered by a symptom. A leak that produced a visible symptom would have been fixed years ago by whoever shipped it.
