A global IPv6 address does not mean the traffic skips the tunnel

A test page reports a global IPv6 address and the conclusion jumps straight to traffic bypassing the VPN. That conclusion needs two facts the page never showed: which application made the request, and which route the kernel chose for it. Address scope describes how far an address may be routed. It says nothing about where this particular packet went.

Scope and role are different questions with different evidence.

Scope answers who can route it, not who does

Global unicast addresses are routable on the public internet in principle, unique-local addresses are meant for internal topology, and link-local addresses exist only on one link. Those are properties of the address block. Whether a packet to a given destination leaves through the tunnel is decided by the routing table and by the policy attached to the interface, and both can point either way.

An address can be globally scoped and still be carried inside a tunnel, because the tunnel is a path rather than an address plan.

Read all the addresses on the interface, not the web test

Interface output shows several addresses at once: the outer address on the physical link, the tunnel address, and a link-local address per interface. The web test shows only the source address of one request. Start with ip -6 addr show and note which interface owns each address and what prefix length it carries, then ask which interface the request actually used.

Compare that with ip -6 route get 2606:4700::1111, which prints the interface and source the kernel would select for a destination.

How a global prefix ends up inside a tunnel

Two designs produce a global address on a tunnel interface. The provider may delegate a prefix routed to the client over the tunnel, which makes the address global while the path is still the tunnel. Or the client keeps its native global address and the tunnel carries it as inner traffic while the outer header does the work. Neither design requires translation, and treating IPv4 NAT habits as an IPv6 requirement is where the confusion starts.

Ask the administrator which of the two applies. The answer determines what a server on the far side sees as your source.

Why a private-looking address is not a trust signal

A unique-local address says the operator intends it for internal routing, and nothing more. It does not prove the device is managed, the software is trusted, or the traffic is encrypted. Conversely, a global address does not prove the traffic escaped the tunnel, which is the assumption this whole article exists to dismantle.

Judge trust from policy, authentication and encryption. Address appearance is a weak heuristic that fails in both directions.

Test route and policy as two questions

First, route: run curl -6 https://ifconfig.me over the tunnel and again over the physical interface, and compare the answers. Second, policy: confirm which prefix the tunnel actually carries and whether the far side has a return route for it. A successful request to a public site proves neither, because that destination is reachable from anywhere. Use an internal destination for the policy test.

Record the source address each path produced. That is the evidence a claim about bypassing actually needs.