IPv6 leaks: how they happen and how to close them

An IPv6 leak is the quietest failure in this whole category, because everything works. Pages load, the client says connected, and a proportion of your traffic — often the majority — never entered the tunnel at all.

Why it happens

Most connections now have both an IPv4 address and an IPv6 address. Most large sites publish both an A record and an AAAA record. When both are available, RFC 6724 and RFC 8305 describe how a client chooses, and the practical result is that IPv6 is generally preferred.

Now put a tunnel in the middle that routes 0.0.0.0/0 and nothing else. Every IPv4 destination goes through it. Every IPv6 destination takes the ordinary path, with your real address, visible to your network operator, exactly as if no VPN were running.

Nothing breaks, so nothing tells you.

Test for it

Load what is my IP with the tunnel up. If the page can show both an IPv4 and an IPv6 result, compare them: the IPv4 address should be the server's, and an IPv6 address that is not the server's is the leak.

The DNS leak test catches a related case, where IPv6 lookups escape to a resolver outside the tunnel even when IPv6 traffic itself does not.

A quicker check on the command line:

curl -4 https://vpnmine.com/api/tools/ip
curl -6 https://vpnmine.com/api/tools/ip

If the second returns an address that is not the VPN's, IPv6 is going around it.

Fix one: route IPv6 through the tunnel

The correct fix. In a WireGuard config that means both families in AllowedIPs, and an IPv6 address on the interface:

[Interface]
Address = 10.7.0.14/32, fd00:7::14/128

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0

The provider has to support it — the server needs IPv6 connectivity and has to issue an address. VPNmine's profiles route both families, which is why the default configuration does not have this problem.

Fix two: disable IPv6 while connected

The blunt fix, and the only one available when the provider is IPv4-only.

• Windows: the adapter's properties, clear Internet Protocol Version 6.
• macOS: networksetup -setv6off Wi-Fi in Terminal.
• Linux: sysctl -w net.ipv6.conf.all.disable_ipv6=1.
• Android and iOS: not user-configurable. A client with IPv6 leak protection is the only option, and it works by installing a route that blackholes IPv6 rather than by disabling it.

Turning IPv6 off permanently is worth avoiding. More of the internet depends on it every year, several mobile networks are IPv6-only, and a machine with it disabled will eventually meet something it cannot reach.

Fix three: let the client blackhole it

Most decent clients handle this by adding a route for ::/0 pointing at nothing while the tunnel is up. IPv6 destinations become unreachable, so the connection falls back to IPv4, which goes through the tunnel.

It is a hack, and it works. Check whether your client has an IPv6 leak protection setting and whether it is on by default; several ship with it off.

Why the mobile case is the worst one

Several large mobile carriers run IPv6-only to the handset, translating to IPv4 at the network edge. On such a network, a tunnel that carries only IPv4 is carrying the minority of your traffic — possibly a small minority.

This is the situation where an IPv6 leak stops being a technicality and becomes the whole picture: the VPN is running, the icon is on, and most of what you do is outside it.

A word on what a leak actually exposes

An IPv6 leak reveals your real address to the sites you visit, and reveals which sites you visited to your network operator, for the leaked portion of traffic. That is the same exposure you would have with no VPN at all, applied to a subset you cannot easily see.

It is also more identifying than an IPv4 leak in one respect: IPv6 addresses are not shared behind carrier NAT, so an address usually maps to one connection rather than to hundreds.

The checking habit worth having

After any change to a VPN configuration, check both families rather than one. The single most common way this leak survives for months is that someone tested with a tool showing only IPv4, saw the server's address, and concluded everything was fine.

Why providers ever ship IPv4-only tunnels

Not laziness, mostly cost and complexity. A server needs routable IPv6 from its host, an address block to hand out to peers, and firewall rules maintained for both families rather than one. Some hosting providers charge for IPv6 blocks or supply them awkwardly, and a provider running dozens of locations has to solve it at every one.

That explains it without excusing the ones that ship an IPv4-only tunnel and say nothing about it. A provider that does not route IPv6 should say so plainly and should blackhole it by default, because the silent partial coverage is worse than either alternative.