Moving a NetworkManager VPN profile to another desktop

Two machines can show the same VPN name in the menu and hold nothing else in common. The settings page is the part that travels worst, because the profile's real content is spread across a keyfile, a keyring, a plugin and a handful of absolute file paths. Three questions decide whether you should export, copy, or enrol again. Ask them before you copy anything.

Start from the profile that actually works

List the connections and read the UUID rather than the name. nmcli connection show prints both, and the UUID is the only field that distinguishes the working entry from an older import with an identical label. Rename or delete the stale duplicate on the source machine before you begin, so the thing you copy is unambiguous. Then record the plugin and connection type, because those two determine what export even means. A profile you cannot identify precisely is one you should not be migrating.

This step costs a minute. It prevents the most common failure, which is moving the wrong profile and then debugging the destination.

Export, or copy the keyfile?

NetworkManager can export some VPN profiles to a file when the installed plugin implements export, and for OpenVPN the result resembles a standalone configuration. Copying the native keyfile is the other route: it preserves every setting, but it expects the same plugin and a permitted owner on the destination. Neither is universally better, and neither is a backup. Choose by asking what has to stay identical.

Export suits a move to a machine that will run the same plugin, especially when you want one artefact you can inspect. The keyfile suits a restore onto an identical distribution where permissions and paths can be reproduced exactly.

What the profile still points at

A profile is not self-contained just because it exported cleanly. The CA, the client certificate, the private key and any additional TLS material are usually separate files referenced by path, and those paths exist on the machine you are leaving. List every referenced file before transferring anything.

Then decide whether the same credential should be used at all. A file with the same name on another machine is not the same identity, and some deployments expect a fresh enrolment instead.

Secrets are not in the file

Passwords and passphrases may live in the keyfile, in a user keyring, or nowhere at all because the user is prompted each time. Only the first of those travels with a file copy.

Check the password flags on the source profile before assuming the move will need no attention. A profile configured to ask, or to store the secret with a session agent, arrives on the new machine with no credential and a connect attempt that fails without explaining why. Reproduce the approved secret workflow there instead of exporting a plaintext password into a file to make the move easier. That shortcut turns a migration into a disclosure.

Retire the old copy properly

Accept the new setup by using the intended application through it, and keep the old path available until then. Import, read back the endpoint, authentication, routes and DNS, then connect and confirm the private resource. An import that produces a green icon is not acceptance.

Deleting a local profile revokes nothing. The certificate and the credentials stay valid until the operator withdraws them, so retirement is a separate request to whoever issued them. Remove the old files, remove the keyring entry, and record which identity was withdrawn and when. If the old machine is being handed on, that record matters more than the deletion.