Keyfile or Netplan: where is the VPN profile really stored?

Finding the file you imported is the easy part and often the wrong start. What matters is which file NetworkManager reads as the saved connection today, and that depends on a connection identifier plus whichever configuration backend the installed packages actually use. Editing the import before answering that question is how a working VPN becomes two half-correct configurations.

The imported file is not the saved profile

Three names float around every VPN problem: the connection name, the filename you imported, and the virtual interface that appears when the tunnel comes up. None of them identify the stored configuration, and a connection name can be edited while the file behind it keeps its original identifier.

Start with a read-only inventory and pick the intended VPN by identifier rather than by label:

nmcli -f NAME,UUID,TYPE connection show

Keep endpoint hostnames and identity labels out of any inventory you paste into a ticket. The useful part is the type and the identifier; the rest is context a stranger does not need. Redact the rest before sharing, and say that you did, so nobody wonders what the blanks mean.

Keyfile locations do not mean the same thing

With the native keyfile plugin, connection files can appear in three directories, and the difference between them is persistence rather than convenience.

Editing the runtime copy looks successful until the next start, at which point the change evaporates and the file looks mysteriously reverted. Editing the package-supplied copy works until an upgrade replaces it, which is a slower and more confusing version of the same lesson.

The keyfile documentation adds a detail worth respecting: those files can contain private keys and passphrases, and NetworkManager ignores any keyfile that users other than root can read or write. Widening directory permissions to browse for a setting breaks the loading behaviour you were trying to inspect.

When Netplan owns the persistence

On Ubuntu, the NetworkManager integration described in Netplan's documentation, available from 23.10 onward, changes where the durable copy lives. For non-temporary connections it writes /etc/netplan/90-NM-<connection UUID>.yaml and generates an ephemeral NetworkManager profile under /run/NetworkManager/system-connections/.

That is a distribution integration, not a rule for every NetworkManager installation. Confirm that the installed packages actually use it before you go looking for a YAML file. Remember also that a runtime profile may be a generated representation of something else rather than the source worth editing. Two commands of checking saves an hour of editing the wrong file.

The documented example stores an OpenVPN connection through the Netplan nm-devices type with NetworkManager passthrough data. The fact that Netplan has no dedicated interpretation of a particular VPN field does not mean your saved VPN has been lost; it means the field travels as opaque data.

Transient interfaces are not profiles

Activation creates temporary virtual connections and interfaces that were never meant to persist. The integration deliberately does not write a new YAML file for each one, so their absence from /etc/netplan says nothing about whether the parent profile is stored.

If you are hunting for a file that appears and disappears, you are probably looking at one of these rather than at your configuration. Check whether it survives a restart before drawing any conclusion from its contents. A runtime file that vanishes on reboot tells you it was never the source, and that single observation redirects the whole investigation. It also explains why an edit looked successful at the time.

Secrets and ownership

A profile can reference a certificate or key stored somewhere else entirely, and a password can belong to NetworkManager, be supplied by a user-session secret agent, or be deliberately unsaved. Locating a single file therefore settles very little about what unattended startup will require.

Inspect the references and the secret flags without printing secret values. A desktop login can make an agent available that was absent during boot, and copying a generated runtime file does not reproduce that agent. The practical symptom is a tunnel that connects when a person logs in and fails when the machine starts alone. That pattern points at secret ownership, not at routing.

Make approved changes through the manager that owns the connection, then verify both the saved identifier and the effective connection afterwards. Keep a single persistent owner, because editing the import, a generated keyfile and a YAML source independently leaves three competing explanations of what the next reconnect will use. Pick the one that actually persists, edit only that, and note in the ticket which file you treated as authoritative. The next person will thank you for one line of provenance.