IPv6 Branch Prefix: iroute-ipv6 or route-ipv6 on the Server?

Two directives with nearly the same name appear in every working example, and copying one without the other produces a tunnel that looks correct and silently drops the branch prefix. They do different jobs on different sides of the same boundary: one teaches the server's kernel where a prefix lives, and the other teaches OpenVPN which authenticated client carries it. Get both right and the prefix flows; get one right and the packets have a route but no owner.

Two directives, two different jobs

route-ipv6 is an ordinary route installation: the server adds a kernel route pointing the prefix at its tunnel interface. iroute-ipv6 belongs to a client-specific context and declares internal ownership, so the daemon knows that traffic for that prefix should be sent to a particular client rather than to whichever peer a kernel route happens to name.

One is about the kernel's forwarding table, the other about the daemon's internal routing model. Keeping them apart explains why a configuration that looks complete can still drop the prefix. It also explains why the same network appears twice in every working example. Neither line is redundant.

In the traditional userspace setup both are needed and they complement each other. A kernel route alone leaves the daemon unable to pick a peer. An iroute alone leaves the kernel without a path to the tunnel. This is also where most confusion about per-client files comes from: the file is not a route table entry, and the route entry is not an ownership statement.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Where each one belongs

The route goes in the server's managed configuration, where it applies to that server process. The iroute goes in the client-specific file named for the authenticated identity of the branch device.

A filename that does not match the effective identity is never read, and the symptom is identical to a missing iroute. Check the identity the server authenticated, then check the file name character by character.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Keep the pool and the branch prefix distinct, because overlapping them creates a puzzle no directive can solve.

What another client needs

A second client that should reach that branch needs an advertisement, not ownership. Push the prefix to the clients you intend, in the client or group context that fits your configuration.

Do not send it to the branch itself, since that device already has the prefix as a connected network.

Sending it to everyone is a choice with consequences: every client then believes the branch is reachable through the tunnel, including clients you never intended to grant that access. Advertising is an access decision in practice, even though the directive looks like plumbing. The server options reference documents iroute-ipv6 as client-specific ownership, which is the distinction worth keeping.

The return path on the branch device

Ownership only helps if the branch forwards packets and its LAN knows how to answer. Enable IPv6 forwarding on the branch device, and confirm that hosts on its LAN send traffic for the VPN pool back toward the branch rather than toward a default route that does not know the pool.

That return path is the IPv6 equivalent of the missing-route problem people hit with IPv4.

Check it from a LAN host with a lookup for the VPN pool address, not from the branch itself. A lookup performed on the router answers a different question from the one your users are asking, and the two disagree often enough to be worth the extra command.

When the pair is still not enough

Some deployments do not use this path at all. The kernel data path and product-managed servers have their own supported route handling, and a userspace example may not translate directly.

Confirm which data path your build uses before copying directives from a tutorial written for the other one.

Finally, remember the address scope: a unique local prefix like fd00:7a::/64 is private by design and says nothing about public IPv6 reachability. Treat it as internal access, and keep internet egress a separate question with its own policy.