Wi-Fi connects itself; the VPN needs a secondary association

The laptop joins Wi-Fi before you sit down, and the VPN still waits for a click. Setting autoconnect on the VPN profile changes nothing, because that switch governs the profile's own activation and NetworkManager treats a VPN as a companion to a base connection. The documented mechanism is the base connection's secondary list, and it is a different property in a different place.

Autoconnect is not the VPN switch

A Wi-Fi or Ethernet profile can activate on its own because it owns a device. A VPN plugin profile does not own a device in the same sense; it is started alongside a connection that does. That is why the autoconnect flag on the VPN looks right, saves correctly, and produces no tunnel. The flag answers a question about the profile, not about the network it needs.

Reading the model this way also explains the failure mode. The base connects, nothing asks the VPN to start, and the desktop shows a disconnected VPN beside a connected network. Nothing is broken; the association was never made.

Identify both profiles by UUID

nmcli -f NAME,UUID,TYPE connection show

Pick the Wi-Fi or Ethernet profile that should trigger the tunnel, then the intended VPN profile. Use UUIDs rather than names, because a name is a label that can be duplicated or edited, and a UUID is what the activation path actually resolves.

Do not confuse a profile name with an interface name or an address the machine currently holds. Those are three different identifiers that happen to look similar in a terminal, and mixing them produces a modification aimed at nothing.

Append the VPN to the base connection

nmcli connection modify uuid "PRIMARY_UUID" +connection.secondaries "VPN_UUID"

The plus form appends to the existing list; omitting it replaces the list, which silently removes any other secondary that was already configured. Inspect the current value first and keep a note of it before you change anything.

NetworkManager's connection settings describe secondaries as VPN connections started together with the base connection. Whether a native WireGuard profile is the same kind of object depends on how NetworkManager manages it, so the same command may be the wrong tool for a tunnel that appears as an interface rather than as a VPN plugin.

This is a connection policy change, not a runtime toggle. Apply it through whatever reconnect process the deployment approves, and expect the first activation after the change to behave differently from the session you are sitting in.

Secrets are not part of the association

A secondary entry says "start this with that". Nothing in it hands over a password, unlocks a keyring, or answers a prompt. A profile that authenticates happily after a desktop login can still fail when it is activated in a context where the secret agent is not available.

Use the supported system or secret-agent arrangement for the actual deployment. Storing everyone's password in a script so the tunnel can start unattended converts an authentication design into a file that outlives its owner's employment.

Read both events, then check the resource

Watch the base connection and the VPN activation during one attempt. A missing VPN event means the trigger was never configured or the UUID is wrong. A VPN event followed by an authentication failure means the trigger ran and the remaining problem is the credential, which is a different fix.

After activation, request the resource that motivated the setup rather than trusting the icon. Then disconnect deliberately and watch what happens next, because an automatic-start association is not a kill switch and does not promise endless retries. If the requirement is "no traffic without the tunnel", that is a separate policy needing its own configuration and its own test. Confusing the two is how a machine ends up reconnecting in a loop while the user believes it is protected.