An IPv6-only network breaks the VPN before the tunnel starts

The laptop joins a conference Wi-Fi that hands out only IPv6, the VPN client spins and fails, and the same profile worked in a hotel an hour earlier. Nothing about the credentials changed. What changed is that the client must now reach an IPv4 endpoint through a network carrying only IPv6, and not every client knows how to do that.

Walk the same five steps the packets walk.

Step 1: watch the name lookup

If the profile uses a hostname, the first question is what the resolver returns. dig AAAA vpn.example.com on the IPv6-only network returns a real AAAA record, a synthesized one from DNS64, or nothing at all. A synthesized answer encodes the IPv4 destination inside a translation prefix, and only then can a client with no IPv6 endpoint reach it. A profile with a hard-coded IPv4 address never gets this far, because there is no name to synthesize.

That single difference explains most works-there-fails-here reports, and it takes one command to see.

Step 2: see which family the client dialled

Watch the socket rather than the progress bar. A client that opens an IPv4 socket to an IPv4 address on an IPv6-only link has nowhere to send it, and the failure surfaces as a timeout rather than a name error. ss -tanp while the client is connecting shows the remote address and the family it attempted. Compare that with ip -6 route to confirm the default is a real IPv6 next hop.

The address family in the socket table is the fact. The progress bar is a summary somebody else wrote.

Step 3: separate translation from the tunnel

NAT64 and DNS64 are how the access network reaches IPv4 destinations, and they do nothing for the tunnel once it is up. A tunnel established over a translated path still negotiates its own inner addressing, and the inner IPv4 or IPv6 coverage is a separate policy question. If the client connects and then reaches nothing, you are past translation and into routing, which is a different investigation with different evidence.

Translation failing looks like never connecting. Inner coverage failing looks like connecting and reaching nothing.

Step 4: test the same profile on another network

Take the same profile, client version and credentials to a dual-stack network and repeat. If it works there and fails on the IPv6-only path, the variable is the access network rather than the profile. Record the client version and the network condition in the ticket, because the eventual fix is a client update or a different endpoint.

A report saying the VPN is broken is unactionable. A report saying it fails only on IPv6-only access is a bug report.

Step 5: fix the path, not the security settings

The tempting repairs all make things worse. Disabling IPv6 removes the only path the network offers. Pointing the client at a public resolver breaks DNS64 synthesis, because that synthesis has to come from the resolver behind the translator. Turning off certificate verification gets you a connection to something you cannot identify. None of those is a fix, and two of them are security regressions that will outlive the incident.

The real options are a client that supports the network translation model, or an endpoint with a reachable IPv6 address. Ask for one of those.