Migrate One Subnet to a New VPN Tunnel Without an Outage

Bring up the new tunnel, move one subnet, and that subnet now fails intermittently while everything else is perfectly fine. Half-migrated VPNs fail exactly this way, because the tunnel was never the hard part. The path also includes which route wins, which selectors match, what the access rules allow, how replies come back, and any translation the old design applied. Move the tunnel alone and you have moved none of that.

A tunnel is the easy half of the path

Intermittent failure after a partial migration normally means two paths are both plausible. Some flows pick the new tunnel, some keep the old, and a stateful device then sees a reply arriving on a path the request never used. Two paths are not automatically safer than one; they are two things that can disagree. Watch the flap reports rather than the tunnel counters, because the counters will look healthy the whole way through.

The useful first question is not which tunnel is better. It is which flows select which path today, and whether the request and the reply get the same answer.

Build the destination before you prefer it

Confirm the peers are compatible and that the new tunnel carries the address scope you intend. Add the forwarding and service permissions it needs while it is still the unpreferred path, so the cutover itself changes selection and nothing else.

Ask the remote site how it will return traffic. If replies still leave through the old tunnel, a new local route produces asymmetry or fails a stateful filter. Translation belongs in the design for the same reason: a changed source address changes the return path too.

Cut over narrowly, and know the way back

Name the exact subnet and the platform-supported mechanism that prefers its new route or selector. Policy-based definitions do not always behave like route metrics, so read the overlapping-policy rules for your implementation before assuming the more specific match wins.

Move one subnet, not one site. Keep management access on a path you are not touching, and write the rollback down before you apply anything: which route or policy reverts, who does it, and how they stay connected while they do it.

Asymmetry and stale state

Firewalls and NAT devices remember the interface a flow used. When request and reply take different tunnels, the device can drop the reply even though either path works on its own. Test with a flow you open after the change, because an established session may keep using the old path for hours.

If the observed source address moved, find every policy that names the old one. A migration that quietly changes the source breaks rules nobody classified as part of the VPN design.

Prove both answers, then retire the old policy

From an ordinary host on the migrated subnet, reach the intended service and check the observed source and the reply interface. Then test a network that is supposed to stay on the old tunnel, since a migration is only finished when both answers are right. The second test is the one people skip, and it is the one that catches a selector broader than you meant.

Retire the obsolete policy only once no remaining subnet depends on it, and record the final route with its owner in the selector inventory. Completion is not the new tunnel reporting up; it is every network following its intended path.