How to Test IPv6 Through a VPN With Your Own Resource

A public IP-check page answers one question, and usually not the one you asked. It tells you the exit address the page observed; it does not tell you whether the IPv6 route through the tunnel works, whether the host preferred IPv6 or fell back, or whether an excluded application took a different path. An authorised resource you control answers the narrower question properly, because you can see both ends. The runbook below is about getting a conclusion you can defend, not about getting a green result.

Step 1: state which IPv6 path you are testing

State it in one sentence. A request to the tunnel server's own IPv6 address tests the tunnel; a request to a host beyond the exit tests the exit's IPv6 egress; a request to a private IPv6 address tests an internal route.

Those are three different claims and a single successful request cannot support all of them. Pick the one that matters for the decision in front of you and write it down before you run anything. If the concern is whether IPv6 leaks around the tunnel, the question is about the host's route selection, not about the exit's reachability. If the concern is whether the far side can reach an internal service, the exit is irrelevant.

Step 2: confirm the host selects that route

ip -6 route get 2001:db8:1::10 prints the route, the source address and the interface the kernel would use, which is the fact the rest of the test depends on.

An interface existing is not the same as it being selected. Dual-stack hosts have a precedence table, and /etc/gai.conf on Linux can change which family wins for a name that resolves to both.

Step 3: use a destination and a name that are legitimate

If you are testing HTTPS, use the hostname the certificate was issued for and keep verification on; switching to a literal address to make the test pass disables exactly the check that proves you reached the intended host. A diagnostic service you control, answering on a known name with a valid certificate, is the cleanest target. It also gives you a server-side log line to correlate against, which a third-party checker never will.

Run the request in a form that shows the address it used: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. The -6 forces the family, which is how you separate IPv6 does not work from IPv6 was not preferred.

For a pure reachability check where ICMPv6 is permitted, ping -6 -c 3 2001:db8:1::10 is enough. It proves the path and nothing above it.

Step 4: correlate both ends

When you have access to both ends, run tcpdump -ni any ip6 and host 2001:db8:1::10 on the client and the equivalent on the resource, with timestamps, and confirm the same flow appears on both. That is what turns a plausible result into evidence: the client's view alone cannot distinguish a reply from the resource from a reply from something in between. Keep the capture narrow to the one destination so the output stays readable and nobody's unrelated session ends up in the file.

Repeat the test after a reconnect if the concern is whether policy survives a restart. Route and firewall state applied once at connect time can differ from state that is reapplied, and the difference only shows up on the second connection.

Test the failure case separately if you need it. A tunnel that blocks IPv6 when it drops and one that leaks it are different designs, and only one of them can be verified by a successful request.

Step 5: write down what the test did not prove

Step five is writing down what the test did not prove, and it is the part that gets dropped. A successful private endpoint test does not prove public IPv6 egress, does not prove DNS behaviour, and does not cover applications you excluded from the tunnel. Each of those needs its own destination and its own observation. A note that says IPv6 works after one request to one host is not a finding; it is a guess with a timestamp.

The record worth keeping is short: the destination, the name, the source address the host selected, the observed remote address, and the time. RFC 7359 discusses how to test that a relevant IPv6 path is actually usable, which is the standard this runbook approximates with simpler tools. If the conclusion needs a public checker to be true, the test was not specific enough.