IPv6 ULA in a VPN: Private Addressing, Not Privacy

Private-looking addresses are not private in the sense most people mean, and IPv6 unique-local addressing is the clearest case. A ULA prefix gives a VPN a stable internal plan for resources behind it. It does not encrypt anything, does not authenticate a peer, and does not decide which services a client may reach. Treating the prefix as a security control is the mistake this article is built to remove.

What the Prefix Actually Provides

RFC 4193 sets aside fc00::/7 for local use, with the L bit distinguishing locally assigned space from the reserved form. In practice that means fd00::/8 is what you generate. The specification also defines how the 40-bit global ID should be derived, so that independent sites do not pick the same prefix by accident. That space is designed to stay off the public internet, which is a routing property rather than a protection.

Within a site, the usual layout is a /48 global ID split into subnets: one for tunnel clients, one for the server side, one for each remote LAN. That structure is the whole benefit, and it is an addressing benefit. Every packet still needs a route and still needs a policy that permits it.

Confusing the prefix with a tunnel is how a design ends up documenting fd00 addresses and assuming the traffic between them is protected. It is not, unless something else is doing the protecting.

Why Copying the Example Prefix Bites

Every tutorial uses a memorable prefix, and every reader who copies it inherits the same collision risk. Two sites that later connect over a site-to-site tunnel with identical ranges produce exactly the ambiguity known from overlapping private IPv4 space. Neither side is wrong on its own, and the combined network has no way to tell which destination is meant.

Generating the global ID from the documented process takes a minute and removes the question. Record the prefix, the generation input and the date beside the address plan.

The risk is not theoretical for anyone who merges networks after an acquisition or joins two labs over a VPN. It is also not urgent for a single site, which is why it gets postponed until the merge is already scheduled.

Scope and Access Are Separate Questions

ULA is not intended for ordinary globally routed internet addressing. That does not make every host using it trusted, and it does not make those hosts unreachable from other connected private networks. Firewalls and application permissions still decide what a peer may use, and the tunnel still supplies whatever authentication it was configured with.

An internet exit needs its own IPv6 egress design. Assigning a ULA address to a client does not create access to arbitrary global destinations, and a client that receives one should not be expected to browse the public internet over it.

Two sites with different prefixes still need return routes for each other's ranges, and both firewalls need matching rules. None of that follows from the address family. What follows is documentation work: a table of prefixes and the systems allowed to answer on each one.

Check the Plan on Both Endpoints

Confirm the prefix appears where you think it does, then confirm a destination is actually reachable over it.

ip -6 address show
ip -6 route show
ping -6 -c 3 fd12:3456:789a:1::1

The address listing shows which interface holds which subnet, and a client that received the wrong one usually shows it here. The route listing shows whether the remote prefix has a path through the tunnel instead of being dropped. The probe answers the only question that matters, which is whether a packet makes the round trip.

Repeat the check after a reconnect, because a client that keeps its address but loses the route produces a connection that looks up and forwards nothing. The address is the easy part, and the route is what disappears. Save both outputs beside the connection profile name so the next comparison starts from evidence.