NM OpenVPN: the saved profile is not your .ovpn file

The same .ovpn file connects from a shell and times out after import into NetworkManager. The natural conclusion is that the VPN is broken. The more likely explanation is smaller: NetworkManager did not keep the file, it imported some of it into a saved connection, and the running tunnel uses that saved data instead. Whatever the file says now is irrelevant to what the profile holds.

The file is not the profile

Import is a translation, not a mount. Options the plugin understands become keys in the connection's vpn.data dictionary; options it does not understand are dropped or recorded elsewhere, and the original path is only a reference. Editing the source file afterwards changes nothing about the connection that is already saved.

That gap explains a whole family of reports: the shared key was rotated, the file was updated, and the tunnel still fails. The saved profile still points at the old path or the old value, and the command line keeps working because it reads the file you edited. Two clients, two sources of truth, and only one of them was updated.

Read the saved profile, not the dialog

nmcli -f connection.id,connection.uuid,vpn.service-type,vpn.data connection show office-vpn

Use the UUID when two profiles share a name, and confirm the service type is the OpenVPN plugin you expect rather than a different VPN type that happens to be installed. Then compare the endpoint, the transport, and the certificate references with the working invocation.

A value visible in a graphical editor is not proof that it was persisted. Save, reopen, and read it back through the command line; historical save defects are a reason to check the stored data rather than evidence that every current build has the same bug. The check costs one command.

Two keys, and a direction that matters

For a connection using TLS authentication, the plugin stores the shared key path in ta and the direction in ta-dir when the deployment uses one. Both live in the profile's data dictionary, and both must match what the server expects.

Direction is a server-side decision expressed on the client. Choosing one because a neighbouring profile has it is how a working key ends up failing a handshake. If the server configuration is non-directional, the client should not invent a direction.

The key file itself must be readable by the plugin in the context it actually runs in. A confined package has a different filesystem view from an ordinary desktop install, so a path that exists in your shell may be invisible to the service.

Update one entry, not the dictionary

nmcli connection modify office-vpn +vpn.data 'ta=/etc/NetworkManager/certs/office-ta.key'
nmcli connection modify office-vpn +vpn.data 'ta-dir=1'

The leading plus updates individual dictionary entries. Assigning vpn.data without it replaces the whole dictionary, which is how one missing key turns into five broken settings. Read the profile back after the change and confirm the other entries survived. A dictionary that lost its remote endpoint and its certificates is a much longer afternoon than the one you started with.

Reconnect through the normal controls and watch the stage that fails. If the shared-key gate now passes and the client reports a certificate or user-authentication error, you have moved forward and the next investigation is a different one.

Do not conflate the control-channel modes

tls-auth, tls-crypt, and tls-crypt-v2 are different arrangements. A key file that looks similar does not make them interchangeable, and populating the TLS-Auth fields because another profile contains a formatted key produces a profile that fails in a way resembling a wrong key.

Use the plugin mapping that matches the mode in the server's configuration. When the mode is unclear, ask the server owner rather than guessing from the file's first line.

Keep a recovery path when the tunnel carries your management session. A saved change is not necessarily an applied change, and a successful import is not proof that every source option was supported. Both gaps are worth knowing about before you reconnect the link you are working through.