Disable VPN Autoconnect Without Deleting the Profile

Every boot the tunnel comes up before anyone decided to use it, and the checkbox that looks responsible does nothing when cleared. That is not a bug in the interface. NetworkManager does not autoconnect VPN profiles on their own; a VPN is started because a base connection names it. The fix sits on the other profile, and it is one property.

The flag you are clearing is not consulted

The VPN profile has its own autoconnect property, and for VPN connections the manager does not use it to start anything. Clearing it makes the profile read consistently and changes no behaviour, which is exactly why the surprise survives the edit.

The documented mechanism is a list of secondary connections on the base profile. When the Wi-Fi or Ethernet connection activates, the manager activates the VPN UUIDs listed there as well. Only VPN connections are supported in that list today, and if it holds several entries, an edit affects all of them.

Autoconnect priority ranks candidates; it is not an off switch either.

Read the two profiles before editing

Record names, UUIDs and types first, because display names repeat and the base connection is easy to confuse with the VPN. Then read the properties that matter on each side.

nmcli -f NAME,UUID,TYPE connection show
nmcli -f connection.secondaries connection show "Wired connection 1"
nmcli -f connection.autoconnect,connection.autoconnect-priority connection show "Work VPN"

In the graphical editor the same values appear under different labels. The base connection's General tab holds the automatic-connect setting and, when the plugin is installed, the option to bring up a VPN with it. A translated desktop may label the priority field as automatic connection with priority, which is not the enable switch. Confusing the two produces a cleared checkbox and an unchanged boot.

Remove one entry, not the whole list

The property is a list, so assigning a new value replaces everything in it. Use the leading minus to remove a single UUID and leave the rest of the list intact.

nmcli connection modify uuid BASE_UUID -connection.secondaries VPN_UUID
nmcli -f connection.secondaries connection show "Wired connection 1"

Check the list before and after, especially on a machine that depends on a second VPN.

Profiles can be scoped to particular users. When one is, the account you edit from has to appear on that list; otherwise the command may be refused, or the manager may write a separate per-user profile that the original owner never sees. Check the owner before concluding that an edit did nothing, because a silent per-user copy explains a lot of confusing results.

Test a real transition, not a manual restart

Reconnecting the base profile is the meaningful test. Bring it down and up, or reboot, then look at the active list, the interface list and a route lookup for an internal address.

nmcli connection show --active
ip -brief address
ip route get 10.8.0.1

If the tunnel still appears, the remaining owner is usually a script. The manager's journal shows which profile was activated and when, and the dispatcher directory is where a hook that calls nmcli connection up on an interface event would live. A hook is invisible in the profile editor, which is why it survives every checkbox experiment.

Keep the manual path working, because that is the actual requirement.

What good looks like

The profile stays installed with its gateway, certificate and credentials. It does not activate at boot, and it does come up when you ask for it. Those three statements are the acceptance test.

Write the base connection's UUID into the runbook, since that is the profile you will edit next time.

A VPN that is available but not automatic is a configuration choice rather than a missing feature, and it is one property away.