IPv6 Traffic Bypassing the VPN: Find the Leaking Route

Two test pages disagree: one reports the provider's address through the tunnel, the second reports your home prefix, and the obvious conclusion is that the VPN leaks. That conclusion skips a step, because the two reports exercised two different routing decisions and only one of them was supposed to enter the tunnel. The gap is usually real, and it is a coverage problem rather than a broken tunnel. Three questions settle it: which flow actually left, which route the kernel chose for it, and which behaviour the client intended.

Work in that order. Answering them out of order produces a long argument about whether the client is faulty when the real answer is that nothing ever installed an IPv6 route.

Which flow actually left, and on which adapter

Begin with a test that names the family it used, then write down the application, the access network, the profile in force and whether the connection offers IPv6 at all. Those four facts are what make two runs comparable, and the fourth is the one people forget: a network with no v6 prefix cannot leak v6, and a network that adds one later changes the answer.

Send one request per family rather than loading a page and reading its result. A single page can mix v6 and v4 resources, a background process may behave differently from the tab in front of you, and a cached answer can outlive the network change you are trying to test. Fix the destination you test and note it, so a repeat run measures the same thing.

Reading the route the kernel picked

The route table answers the question the browser cannot. Ask the system where a specific destination would go, and include policy rules as well as the visible default, because either can override it:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

A more-specific prefix is the usual reason one destination sits outside the tunnel while everything else stays inside, and a policy rule can do the same thing at a higher priority than any route. Read the metric as well, since two entries for the same prefix resolve by metric rather than by their order on screen. On Windows the equivalent listing is Get-NetRoute -AddressFamily IPv6, sorted by metric to match the decision order. A rule that looks correct in the table can still lose to a lower-numbered policy rule, which is why the rule listing belongs in the same breath as the route listing.

Where the client's IPv6 policy comes from

A client can be built to carry v6 through the tunnel, to refuse it, or to permit a named exception, and those three intentions produce three different correct results. Read the profile and the client's own documentation before calling an observation a leak, because a client that blocks v6 while the operating system still sends neighbour discovery on the physical link is behaving as designed.

An application deliberately excluded from the tunnel is a different case from a family the tunnel never carried. The first is a decision about one program, the second is a gap in coverage, and the repair differs accordingly. Read the client's list of excluded programs before hunting for a route that was never meant to exist.

Narrow observation, when the table disagrees

When the route lookup is ambiguous, one interface observation on the host can settle it, but only if it is aimed at the question. Traffic to the VPN endpoint itself will cross the physical adapter by design; what matters is whether the application flow, addressed somewhere else entirely, also appears there. Filter the capture to the destination you are testing rather than collecting everything.

A broad capture exposes far more personal traffic than the one question requires. It also answers the question less clearly, because the flow you care about arrives buried in a stream of unrelated connections. Filter to the tested destination, stop after a handful of packets, and delete the capture.

Three ways to close the gap

Carry the family through the tunnel, block it at the client when the tunnel cannot carry it, or record a deliberate exception with an owner and a review date. Each is defensible, and the one thing that is not defensible is leaving the choice implicit, because an implicit choice is what the leak actually is. If the tunnel has no v6 exit at all, refusing v6 at the client is both honest and testable. What matters is that the choice is written where the next person will find it, not inferred from behaviour six months later.

Repeat the check after a reconnect and after moving between networks, since a route installed for the previous link can survive the change. Then record the destination, the route selected, the client policy and the family the test used, so the next person reads a decision instead of re-deriving it. RFC 7359 documents dual-stack leakage as a design problem rather than a bug, and it is the reference to cite when someone claims a working v4 tunnel covers everything.