IPv6 leaks: the hidden way your "secure" VPN can give you up
Most consumer VPN clients tunnel your IPv4 traffic and pretend IPv6 does not exist. Meanwhile your machine has a perfectly working IPv6 address from your ISP, and every site that supports IPv6 — Google, Cloudflare-fronted, Facebook, GitHub — sees it. Here is how to check, and how to fix it.
You connect to a VPN. The little icon turns green. You go to whatismyip.com. The address shown is the VPN exit. You feel safer. You click around for a bit. Somewhere in the background, your browser opens a connection to a Cloudflare-fronted CDN. Your laptop has an IPv6 address that your ISP assigned via SLAAC five minutes after you booted. The VPN client did not touch the IPv6 routing table. Your real IPv6 address goes out the local interface, straight past the tunnel, to the destination.
Cloudflare logs your real IP. Google logs your real IP. The site you thought you were visiting through the VPN logs your real IP. You did not get a warning. You did not see anything suspicious. The icon is still green.
This is an IPv6 leak. It is one of the most embarrassingly common failure modes in the consumer VPN industry, and most users have no idea their VPN is doing it.
Why this happens
IPv6 deployment is uneven by country and ISP, but the trend is unmissable. As of early 2026, Google reports about 47% of its global traffic arrives over IPv6. In India, Reliance Jio gives every customer a /64 by default — that is 18 quintillion addresses, all routable, all visible to any IPv6-capable destination. In Germany, Deutsche Telekom is dual-stack. In the US, Verizon Wireless is IPv6-first.
Meanwhile, a non-trivial fraction of consumer VPN clients are still architected as if it were 2010. They install a tun device, push an IPv4 default route into it, configure DNS, and walk away. The IPv6 routing table is left untouched. The result: any destination with an AAAA record skips the tunnel entirely, because your operating system sees a working IPv6 default route on your local interface and prefers it.
Operating systems prefer IPv6 by default — RFC 6724 says so — when both are available. So if your VPN gives you only IPv4, you have unintentionally configured your machine to leak every IPv6-capable destination outside the tunnel. The list of IPv6-capable destinations now includes Google, YouTube, Facebook, Instagram, Cloudflare, Netflix, GitHub, Akamai, Fastly, AWS CloudFront — basically the modern web.
How to check, in three minutes
You do not have to take any vendor at its word. Test it.
- 1Connect to your VPN.
- 2Visit test-ipv6.com. It runs a series of probes from your browser to dual-stack and IPv6-only test endpoints. The "What is my IPv6 address?" line is the one that matters. If it shows your real ISP-assigned address, you are leaking.
- 3Cross-check with our DNS-leak tester at planet-proxy.com/tools/dns-leak — it explicitly probes for IPv6 DNS resolvers as well as IPv4, and flags mismatches between what the VPN should be doing and what is actually happening.
- 4For thoroughness, run "curl -6 https://ifconfig.co" from a terminal. If it returns an address, your machine has an IPv6 path that is reaching the open internet. If that address is not your VPN exit, the path is bypassing the tunnel.
If all three of those tests show your VPN exit, congratulations — your client is doing the right thing. If any of them show your real address, you have a leak.
The two correct fixes
There are exactly two architecturally correct ways to handle IPv6 in a VPN client. Anything else is a workaround.
Fix 1: Drop IPv6 entirely
When the tunnel comes up, the client adds firewall rules that black-hole all IPv6 traffic on every non-tunnel interface, and removes the IPv6 default route. IPv6-capable destinations now have no path; the operating system falls back to IPv4 (this is what Happy Eyeballs is for). The IPv4 traffic goes through the tunnel cleanly. No leak.
This is the simpler fix and it is what most VPN clients that actually address the problem do. Trade-off: you lose IPv6-only sites, which today is a tiny minority but a growing one, and you fall back to slower IPv4 paths even when IPv6 would be faster.
Fix 2: Full dual-stack tunnel
The tunnel carries both IPv4 and IPv6. The client assigns the user a unique IPv6 address from a routed prefix on the exit, pushes an IPv6 default route into the tun device, and the exit server NATs or routes that prefix out to the public internet. IPv6 traffic goes through the tunnel; IPv4 traffic goes through the tunnel; nothing leaks.
This is harder. The exit server needs an actual routed IPv6 prefix from its hosting provider — not all of them give you one, especially in budget-tier locations. The client has to handle IPv6 ICMP correctly. The kill-switch logic has to consider both protocol families. Most VPN providers do not bother. We do, because if we did not we would be lying to users.
What a kill-switch must actually do
A kill-switch is the feature that stops traffic from leaving your machine if the VPN tunnel drops. The naive implementation blocks IPv4 traffic on non-tunnel interfaces. The correct implementation:
- Blocks IPv4 traffic on every non-tunnel interface.
- Blocks IPv6 traffic on every non-tunnel interface.
- Blocks DNS to anything other than the tunnel-pushed resolvers, on both protocol families.
- Survives interface flaps, suspend/resume, and network changes without re-enabling the leak.
- Activates before the tunnel is up, not after. (A common bug: kill-switch enables only on tunnel-up, leaving a window during connection where traffic leaks.)
If your VPN markets a kill-switch but does not document explicitly that it covers IPv6, assume it does not, and test.
The bottom line
A VPN that does not handle IPv6 is not a VPN, it is a vibes-based security feature. The correct posture is either tunnel both protocols cleanly or block IPv6 outright at the firewall layer; anything in between is a leak waiting to happen. Test your provider with test-ipv6.com and our DNS leak tool. If they fail, switch — including switching to us, which is the part of this article where I am supposed to be subtle and will not bother. The industry has had a decade to fix this. There is no excuse left.
Frequently asked
My VPN says it "supports IPv6". Does that mean it tunnels it?+
Not necessarily. Some providers use "IPv6 support" to mean their client correctly disables IPv6 on your local interfaces so it does not leak — which prevents the leak but does not give you IPv6 connectivity through the tunnel. Read the docs carefully or test with curl -6 to see if you actually get an IPv6 address from the VPN.
Is disabling IPv6 in my OS settings a good fix?+
It works, but it is a hammer where a scalpel is appropriate. You lose IPv6 even when you are not on the VPN, and on networks like Jio that are essentially IPv6-first, you may degrade your normal connectivity. Better to use a VPN client that handles this correctly so you do not have to think about it.
Why does my IPv6 address from my ISP look "random"? Is that already private?+
Modern operating systems use IPv6 privacy extensions (RFC 8981) which generate a temporary, randomised interface ID. That hides which specific device on your LAN is talking, but the /64 prefix is still your ISP-assigned prefix, which is roughly as identifying as your IPv4 address from a tracking standpoint. Privacy extensions are not a substitute for a tunnel.
Run PlanetProxy for seven days, on us.
Same purple tile cards you see on this page, plus the green lock and a 50 ms hop to wherever you want to be.
Start the trial →More from the dispatch
NetworkingPP · DispatchWireGuard vs OpenVPN in 2026: which one to useNetworking · 9 minWireGuard vs OpenVPN in 2026: which one to use
Two protocols with very different histories. One is from 1999 and weighs 70,000 lines of C. The other is from 2018 and weighs 4,000. Here's when to pick each.
- NetworkingPP · DispatchDNS-over-QUIC: the third generation of encrypted DNSNetworking · 7 min
DNS-over-QUIC: the third generation of encrypted DNS
Do53 was plaintext. DoT bolted on TLS. DoH hid queries inside HTTPS. DoQ skips the compromises and runs DNS directly over QUIC. Here is why that matters, and how to turn it on today.
- NetworkingPP · DispatchHTTP/3 and QUIC: why your browser already changed protocols and you didn't noticeNetworking · 8 min
HTTP/3 and QUIC: why your browser already changed protocols and you didn't notice
About a third of the web now runs over HTTP/3, which means it runs over QUIC, which means it runs over UDP. Your browser made the switch silently. Here is what changed mechanically, where it breaks, and what it does to VPN throughput.