nmcli keeps asking for the VPN password: store the secret locally

Same profile, two sessions: it connects from the desktop and hangs over SSH on a prompt that nothing can answer. Nothing is broken and no setting was lost. NetworkManager is asking a secret agent for the credential, and a secret agent is a desktop component that does not exist in the session you are using.

Run the sequence below and the tunnel comes up headless, with the caveat that storing a secret changes who can use that profile.

Confirm the diagnosis before editing anything

The difference between interactive and non-interactive activation is the whole diagnostic. If nmcli --ask connection up succeeds while a plain activation stalls, the profile is correct and the secret source is missing. That single comparison saves you from rewriting a working configuration.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags

Read the flags rather than guessing at them. Values that mean "ask an agent" are what you are looking for, and the exact key names differ between VPN plugins because they live in the plugin's own data dictionary. A FortiSSL profile and an IPsec profile do not necessarily use the same names, so work from the output of your own profile.

Also confirm the plugin package for that protocol is installed. A missing plugin shows up as an unknown connection type or an activation error that says nothing about passwords, and chasing the secret in that state wastes the same hour twice. One package query is cheaper than an afternoon of editing keyfiles.

Move the secret into the keyfile

The connection file lives under /etc/NetworkManager/system-connections/. Secrets are not kept there by default, which is the point of the flags you just read. Changing a flag to zero tells NetworkManager the value is stored with the profile instead of requested at activation time.

[vpn]
password-flags=0

[vpn-secrets]
password=YOUR-VPN-PASSWORD

For a profile with two secrets, the pattern repeats: one flag per secret in the [vpn] section, and the values in [vpn-secrets]. An IPsec profile typically carries a pre-shared key alongside the user credential, and the plugin names them differently from a plain password field, so copy the key names from the vpn.data output rather than from a blog post that used another plugin. Getting one key name wrong produces a profile that loads and then fails at authentication, which reads exactly like a bad password. Diff your file against a working profile from the same plugin before you connect again.

Quote values that contain spaces, quotes or a dollar sign. An unquoted value with a $ in it will be read literally or expanded depending on where it is parsed, and the resulting authentication failure looks like a wrong password.

Then fix the file's ownership and mode. These keyfiles are read by a privileged service and a file that other users can read is treated as untrustworthy, which is the usual reason an edited profile appears to be ignored. Owner root, mode 600, no exceptions.

Reload, then activate

The file is read when the connection is loaded, so editing it is not enough. Reload the profiles and then bring the connection up explicitly.

sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"

If the reload does not pick the change up, a full service restart does, and there are reports of exactly that. Prefer the reload when other links matter, because restarting the service bounces every managed connection, and on a remote host that can end your session before the tunnel you wanted is up.

Use the UUID when names are ambiguous. Machines with several customer profiles accumulate near-duplicates, and activating the wrong one produces a failure that looks like a credential problem.

When the stored secret is not the problem

A FortiSSL profile can fail even with a correct stored credential because the client never trusts the gateway's certificate. That setting is not on the main dialog; it lives behind the advanced options for the VPN, where the trusted certificate digest is entered. If the log mentions the certificate rather than the password, you are in this branch and no amount of editing [vpn-secrets] will help.

Two more checks belong here. Confirm the profile was not imported from a file that still points at a path the plugin cannot read, and confirm that the profile is the active one rather than a stale duplicate. Both produce activation failures that read like authentication errors.

Decide whether storing is acceptable

A stored PSK and password are readable by anything running as root on that machine. On a box you control that is a reasonable trade for a headless service. On a shared host it deserves a conversation, because the profile now contains a credential that was previously protected by the desktop keyring. Ask who else can reach root on that host before you decide, not after the change is in place.

If policy forbids stored VPN secrets, do not weaken the profile to make a cron job work. Run the connection from a session that has an agent, or use a different mechanism for the automation.

Finally, record which profiles carry secrets so nobody copies one to a laptop without noticing. A comment above the secrets section with the date and the reason is enough, and it will save somebody an awkward review later.