Why IPv6 Is the Leak People Forget

Most devices today have both an old-style IPv4 address and a newer IPv6 address, and they will happily use whichever one a website supports. If a VPN tunnels only the IPv4 traffic, everything sent over IPv6 leaves your connection normally — unencrypted by the tunnel and carrying your provider’s address. That is an IPv6 leak, and it is easy to miss because the VPN app still reports a healthy connection.

The failure is silent by design: nothing errors, pages load, and the leak only appears if you look for it specifically.

Two address families running side by side

IPv6 exists because IPv4 addresses ran short. The old scheme has a finite pool that was exhausted years ago, which is why providers resort to sharing addresses across customers under carrier-grade NAT. The new scheme has an address space large enough that every device can hold a globally reachable address of its own.

The transition has been slow, so nearly everything runs both at once — “dual stack”. Your device has an IPv4 address and one or more IPv6 addresses, and when it looks up a hostname it may get answers for both. Operating systems generally prefer IPv6 when it is available and appears to work.

That preference is the crux. If IPv6 works outside the tunnel and IPv4 works inside it, your device will route a meaningful share of traffic outside the tunnel without being asked.

The three ways a VPN handles IPv6

Providers take one of three approaches, and they behave very differently.

Full IPv6 support. The tunnel carries IPv6 as well as IPv4, and the VPN server presents an IPv6 address of its own. Nothing leaks and dual-stack sites work over IPv6 as intended. This is the best outcome.

IPv6 blocking. The client disables or blackholes IPv6 on the device while connected, so the operating system falls back to IPv4 inside the tunnel. Nothing leaks. Some dual-stack-only services become unreachable, which is rare but does happen, and occasionally local network features stop working.

Neither. The client tunnels IPv4 and leaves IPv6 alone. This is the leak. Any site reachable over IPv6 gets contacted directly, with your real address, outside the encrypted path.

The third case is not always a provider’s decision — it can also be a configuration that was correct once and stopped being correct when a network gained IPv6 support.

What actually leaks

The address, the destinations, and the traffic itself for anything that went over IPv6.

A site you reach over IPv6 sees your device’s real IPv6 address, which is issued by your provider and identifies your connection. Worse, IPv6 addresses are typically per-device rather than per-router, so it can distinguish individual devices in a household in a way an IPv4 address behind a router cannot.

Your provider sees IPv6 destinations in the clear as well. Even though hostnames are what actually get looked up, the addresses alone reveal which services you contacted — and if your DNS queries are also escaping, the hostnames go with them, which is the overlap between this and a DNS leak.

It is worth being precise about scope: transport encryption on the site’s own connection still applies, so a leak of this kind exposes who you talked to rather than the contents of an encrypted session. That is still a substantial loss of what a VPN was supposed to provide.

How to check

Compare what you see with and without the tunnel, on both address families.

The reliable sequence:

1. With the VPN off, note both your IPv4 and IPv6 addresses as reported by a checker that tests both. If no IPv6 address is reported at all, your network does not have IPv6 and you cannot leak it — though that can change when your provider enables it or when you join a different network.
2. Connect the VPN.
3. Check again. Your IPv4 address should now be the VPN server’s. The IPv6 result should either be a VPN-provided address or nothing at all.
4. If the IPv6 address matches what you saw in step one, you have a leak.

The mistake to avoid is testing only the IPv4 result and concluding all is well. A basic address check may report a single value and never touch IPv6. Deliberately verifying both is the whole point, and the general method is the same one covered in how to check for a VPN leak.

Fixing it

In order of preference:

Turn on the client’s IPv6 setting. Look for “IPv6 leak protection”, “block IPv6”, or an IPv6 toggle in the VPN app’s settings. Many clients ship with protection available but not enabled, or offer full IPv6 tunnelling that is off by default.

Update the client. IPv6 handling is an area where older versions genuinely lag, and an update sometimes resolves it outright.

Choose a provider that tunnels IPv6. If the app has no relevant setting and leaks anyway, that is a design gap rather than a misconfiguration, and it is a fair reason to switch.

Disable IPv6 on the device, as a last resort. This works and is easy to reverse, but it is a blunt instrument: it applies whether or not the VPN is connected, and it can break local network features and any service that is IPv6-only. Prefer a client that manages it dynamically.

Be careful with router-level VPNs. Running the tunnel on the router covers every device, but router firmware is a common place for IPv6 to be forwarded straight through while only IPv4 is tunnelled. Test from a device behind the router, not just from the router’s own status page.

Why this deserves attention

It is the leak most likely to be present without anyone noticing. A dropped connection is obvious. A DNS misconfiguration usually shows up in a standard leak test. IPv6 sits in the gap: the tunnel is genuinely up, the app is genuinely working, and a large fraction of popular destinations are reachable over IPv6 and will be contacted that way.

The check takes a minute and is worth repeating whenever you change networks, change providers, or update the client — and any time a leak test looks suspiciously clean.