A VPN Secondary Belongs to One Wi-Fi Profile, Not to All

Configure a VPN as a secondary of the home Wi-Fi connection and everything works, until the laptop joins a different access point and the tunnel stays down. The new connection is a separate configuration object with its own UUID, and it has no reason to know about the bond you created for its predecessor. Nothing malfunctioned; the association simply never existed.

NetworkManager's connection reference defines secondaries as UUIDs that activate together with a particular base connection. It also notes that ordinary VPN profiles do not implement automatic activation the way base connections do. Both statements point at the same conclusion: the association is per profile, and somebody has to create it for each new one.

What a secondary actually is

A base connection has an identity, a UUID, and a list of secondaries. When it activates, the manager also activates those secondaries in order, which is how a VPN ends up following a Wi-Fi network without a manual click. The relation lives on the base connection, written as UUID strings rather than names. That choice of representation is not incidental; it is what makes the association survive a rename.

That detail about names matters more than it looks. Renaming a VPN profile leaves its UUID untouched, so existing associations keep working. Deleting the old profile and importing a new one produces a new UUID, and every association that pointed at the old one now points at nothing.

Inspect the existing list before appending. A home profile carrying one secondary is not a rule that matches every SSID; it is one row in one object, and it will not be consulted when a different base activates.

Put the association where profiles are created

On a personal machine, make attaching the intended secondary part of adding each permitted Wi-Fi profile. That is a habit rather than a feature, but it is a habit that produces a consistent state, and it takes one command or two dialog visits per network. Keep a short note of which networks are supposed to carry the tunnel, because the list is the policy.

On managed devices, have the provisioning workflow create the Wi-Fi entry and its VPN association in the same step, and apply the same treatment to permitted profiles that already exist. Distributing a VPN profile on its own leaves the base relationships unspecified, which is how a fleet ends up with a tunnel that only half the laptops use.

Where users can still create profiles outside the managed path, decide explicitly what happens to those entries. Assuming they inherit an association is not a policy; it is a hope with a support cost attached.

Plan for the VPN's identity changing

The provisioning source needs the intended VPN's UUID, not a display name someone guessed. When maintenance replaces that VPN with a freshly imported object, update the provisioning template and the affected existing associations in the same change. A rename is not a replacement, and treating the two as equivalent is how a working rollout breaks a week later.

Store the UUID next to the reason it exists. A future engineer who finds a bare UUID in a secondary list has no way to tell whether it is current, and is likely to delete it while tidying up.

Activation is not enforcement

A secondary request happens at activation time. It does not block applications during the interval before authentication completes, and it does not stop traffic after the tunnel fails. Those are different properties, provided by different mechanisms, and conflating them produces a design that looks strict in the profile and is permissive in practice.

Blocking direct traffic is a separate feature with its own configuration and its own failure modes, and it must account for the traffic that has to reach the network before any tunnel can exist: captive portals, sign-in pages, the endpoint itself. A blocking policy that cannot be satisfied before authentication locks the machine out of the very network it needs.

Put that distinction into the instructions users actually read. A new Wi-Fi network can ask for the tunnel; enforcement decides whether anything may leave when it cannot connect. Users told only the first half will report the design as broken.

Test with a genuinely new profile

Use an approved test network and a newly created base profile, not the home entry that already works. Observe the base activation, the requested secondary UUID and any authentication prompt in sequence, and note which stage stalls when it stalls. A secret agent that becomes available after desktop login is not automatically there in every startup context, so a reboot belongs in the test plan. Then check the intended resource and the failure path: does the tunnel come up before the application needs it, and what happens to that application when authentication fails?

Then check the intended resource and the failure path: does the tunnel come up before the application needs it, and what happens to that application when the tunnel cannot authenticate? Those two observations are the acceptance criteria, and neither one is visible in the profile itself.