Which IPv6 Source a VPN Request Picks, and Why It Matters

You added a VPN address and expected the request to use it, and the server still logged the old prefix. Nothing about the tunnel failed; the host made a source-address choice before it ever consulted the route you were staring at. IPv6 source selection is a separate ordered competition among the host's candidate addresses, and the longest matching prefix is only one rule near the end of it. Getting the outcome you want means knowing which rule already won. The rules themselves are dull and precise, which is the point of reading them in order.

Two lookups, not one

Destination selection picks the next hop and the outgoing interface. Source selection then picks which of the host's addresses appears in the header, and the two questions are answered by different machinery even though both use prefixes. A host with a physical address, a temporary address and a VPN address has three candidates for any given destination, and the route toward the VPN does not automatically nominate the third.

This is why a correct route and an incorrect source coexist so easily, and why the same request can behave differently from a browser and from a forced binding. Treat the two lookups as separate until you have evidence that links them.

Read the rules as an ordered competition

RFC 6724 lists the rules in order, and each only breaks a tie left by the ones before it. Outgoing-interface preference and label matching appear well before the prefix comparison, so an address on the interface the route uses has already gained an advantage that a better prefix match cannot erase. Deprecation and scope also participate, which is why a stale address sometimes stops being chosen without anyone changing policy.

The practical reading is that you cannot reason about the winner from the destination alone. List the candidates, walk the rules in order, and see where the decision was actually made.

Note also that this is the source half of the problem. Conflating the two prefix comparisons produces explanations that sound rigorous and predict the wrong address. Say which comparison you mean whenever you use the word prefix in a ticket.

An application binding changes the question

An application can ask for a specific source address, and a valid explicit choice moves the question from "which address would the host prefer" to "can that address reach the destination and come back". Tools that bind to a source, or that request ancillary data about the chosen address, expose this directly, and they are the fastest way to prove which address a connection really used. That experiment beats reading the routing table for the third time, because it reports what the kernel decided rather than what you configured. Repeat it after the change and compare the two answers.

That makes source binding a diagnostic tool as well as a workaround: bind the VPN address and watch whether the request succeeds. If it does, the path is fine and the selection was the problem. If it fails, the return path or the remote policy was the problem all along.

Check that the far side accepts that source

Whatever the host picks has to fit the VPN's protected scope and the remote end's return route and access rules. A source outside the selectors can travel into the tunnel and be dropped at the far end, which reads as a one-way failure and gets blamed on routing. Compare the selected inner source with the protection scope before you touch the encryption settings, because changing mode does not choose among candidate addresses.

Keep the outer endpoint address separate in your reasoning too. It identifies transport between the VPN participants and is not the source of the application packet inside.

Decide with four observations

Record the destination used, the eligible local sources, the source actually selected and the effective outgoing path. Four lines are enough to explain almost every case, and they can be compared across a working and a failing host without re-litigating the theory. Use the operating system's own supported view for the selection step rather than a name from the standard, since implementations add local preferences of their own.

When the answer still surprises you, the ordering is doing something your mental model does not, and the fix is to change the inputs rather than to argue with the algorithm. Write the four observations into the ticket and the next reader can reproduce your conclusion.