IPv6 Through an IPv4 VPN Server Still Needs an IPv6 Exit

The tunnel comes up, the client receives an IPv6 address from the pool, and every IPv6 destination times out anyway. Nothing is broken in the tunnel: IPv6 rides inside the IPv4 transport perfectly well, and that was never the hard part. The address you handed out is a promise the server cannot keep, because the exit has no IPv6 upstream to send it into. The repair belongs at the exit, not in the client profile.

The symptom: an address and no path

A client-side check shows a global-looking IPv6 address on the tunnel device and a route pointing into it, which is why this gets misread as a client bug. Traffic enters the tunnel, the server decapsulates it, and then the packet lands on a host whose routing table has no IPv6 default route to anywhere real. Depending on the stack you get an immediate unreachable or a silent drop, and in either case the client sees a timeout that looks identical to a firewall.

Read the server's own routing table before touching the client, because that is where the missing half of the path lives. A server with one IPv4 default route has told you the answer already.

Follow the packet after decapsulation

Inside the tunnel the packet is ordinary IPv6 with the client's address as its source. The server strips the transport encapsulation and is then holding a native IPv6 packet that must be forwarded to an IPv6 next hop. An IPv4 default route cannot carry it, and translating it into IPv4 is a different function that nobody deployed. That is the whole failure, and it has nothing to do with whether the VPN listener answered over IPv4.

IPv6-over-IPv4 encapsulation mechanics are described in RFC 4213, and the important detail there is that the endpoints still need real IPv6 connectivity on the far side of the tunnel. Wrapping a header does not conjure an upstream.

Two tunnel layers, two independent checks

Verify each layer separately, because a working outer tunnel hides a broken inner one. Check the outer path with an IPv4 ping from the client to the server and confirm the port you use. Then check the inner path on the server, where ip -6 route must show a default or a specific route learned from an actual upstream, and ip -6 addr must show a source prefix the upstream accepts. Anything less is decoration on the interface.

A unique-local address, or a global-looking prefix that nothing routes back to, will happily appear on an interface and go nowhere. Public reachability is granted by the upstream, not by the shape of the address.

The same applies at the client: ip -6 route get 2001:4860:4860::8888 should name the tunnel device, and if it names the physical one, the client is not using the VPN for IPv6 at all.

Source prefix, size and ICMPv6

Ask the upstream which source prefixes it will accept for forwarding, and use one of them for the client pool. A provider that hands you a /64 for the server's own interface is not necessarily routing a second /64 or a larger block to you, and the difference is an afternoon of debugging that a support ticket settles in one question. Ask in writing and keep the answer with the configuration.

Budget for the extra encapsulation your stack actually uses, and keep ICMPv6 working, including Packet Too Big. A second header shrinks the usable payload, so a path that answers small pings can still fail on a file transfer, and a firewall that drops all ICMPv6 turns a recoverable size problem into a black hole. Test one large transfer before you announce the service.

What is a different problem entirely

Reaching an IPv4-only application from an IPv6-only client is translation, not tunneling, and needs something like a deliberately deployed NAT64 arrangement. The destination will not understand an extra tunnel header just because you added one. Historical transition services deserve the same care: RFC 7526 deprecated the 6to4 anycast relay model, so a how-to written around it describes something that no longer has a maintained public relay.

If the server has no usable IPv6 upstream, the choices are a supported upstream, a different exit, or a documented decision that IPv6 stays outside the tunnel. What is not acceptable is telling clients that IPv6 service exists while their ordinary IPv6 connection quietly bypasses the VPN.