Does Your VPN Carry IPv6, or Just Reach the Server?

An IPv4-only leak test comes back clean, an IPv6 test shows your home address, and the tunnel is nominally connected. That combination is common on dual-stack networks, because the VPN changed one family's path and left the other alone. The outer tunnel and the traffic inside it are separate addressing decisions. Testing one of them says nothing about the other.

Check both what the client reports and which family the request actually used, because a hostname can return both kinds of answer.

Two Families, Two Different Routes

The operating system keeps a routing table per address family. Installing a default route for IPv4 does not install one for IPv6, and a tunnel endpoint reachable over IPv4 says nothing about whether IPv6 traffic enters it. When no IPv6 default exists through the tunnel, the host uses whatever IPv6 path it has, which is often the physical link. From the application's point of view the connection is simply direct.

A hostname returning both A and AAAA records makes this harder to see, because applications may try the families in different orders. A request that succeeds does not prove which path it took. Use a test that names the family it exercised.

Reaching the Server Is Not Carrying the Traffic

Providers use the phrase IPv6 support for several different capabilities. The endpoint may accept a connection over IPv6 while the tunnel still carries only IPv4. The tunnel may carry IPv6 inner packets while the outer transport stays IPv4. Or the client may block IPv6 entirely so nothing escapes outside the tunnel. Those are three distinct behaviours, and a page that says only IPv6 supported does not distinguish them.

Ask which one the design needs. A network that must reach IPv6-only services needs carriage. A network that must prevent direct IPv6 traffic needs blocking or full carriage, not a label on a marketing page.

Decide Between Carriage and Blocking

Carriage means the tunnel has an IPv6 address, a default route inside it, and policy permitting the traffic at both ends. Blocking means the client deliberately stops IPv6 from leaving outside the tunnel, which is safe and useless for reaching IPv6 destinations. Both are legitimate; neither is a default you can assume. Pick the requirement first, then verify the client actually implements it.

An IPv4-only guest network cannot exercise an IPv6 path, so a test performed there says nothing about the home network where both families exist. Test where the relevant family is actually offered.

The Kill Switch Needs the Same Coverage

A kill switch covering only IPv4 leaves the other family free to leave directly, which is exactly the leak it was meant to prevent. Review its rules for both families and for the transition moments, while the tunnel is coming up or going down. Turning IPv6 off system-wide is not a substitute: it can break unrelated services and hides a client-policy problem behind a machine-wide change.

Keep DNS separate from all of this. DNS concerns who answers the query and how the query travels; the application connection that follows has its own route. One can be correct while the other is not, and diagnosing them together produces confused conclusions.

Record which family each test exercised and which capability the client claims. That pair of facts answers the question a support label never will.