Settings Will Not Import the .ovpn That the CLI Accepts

The same file connects from a shell and refuses to import in the desktop panel. That rules out the server, the credentials, and the profile syntax, because the command-line client already parsed all three. What remains is the desktop path itself: the packages it needs, the subset of directives it understands, and the object it writes to disk. Each of those fails differently, and the messages rarely point at the right one.

Three things the dialog needs before it parses anything

The import runs with your user's permissions, so a file under a root-only directory is rejected before its contents matter. The panel also lists only VPN types whose NetworkManager plugin is installed; without the OpenVPN plugin, the option is absent rather than broken. Finally, the network device must be managed: an interface marked unmanaged can accept a saved connection that will never activate. Check all three before editing the profile.

Two commands settle the first pass: dpkg -l network-manager-openvpn-gnome for the plugin and nmcli device status for the device state.

What the importer quietly throws away

The desktop translation targets a fixed property set. Lines outside that set are discarded silently, which is why the tunnel can come up with parts of the intended configuration missing. Scripts declared with up, down, and script-security usually disappear, as do management-interface options and additional remote blocks. A route written with the vpn_gateway keyword is the exception: the importer wants a literal IPv4 gateway there and aborts with an error rather than dropping the line.

A dropped route has a recognizable shape. The connection activates, the interface gets an address, and one specific subnet is unreachable because the route never made it into the profile.

Read the stored connection, not the source file

The authoritative result of an import is the keyfile, not the .ovpn you selected. sudo cat /etc/NetworkManager/system-connections/office.nmconnection shows what the panel actually saved. If a route is present there but missing from the live table, the import succeeded and activation is the problem. If it is absent from the file, the importer dropped it and no amount of reconnecting will restore it.

Two alternate paths avoid the translation layer. nmcli connection import type openvpn file ./office.ovpn writes the same object and reports errors the panel hides.

The older editor, started with nm-connection-editor, exposes route fields the panel does not. For profiles that depend on scripts or unsupported directives, keep the command-line client and supervise it with a service instead, after disabling the desktop connection so only one component owns the tunnel.

When the import works but activation does not

The advanced tab retains whatever transport was imported or last chosen. A server listening on UDP fails fast when TCP is selected, and the message seldom says so. A connection that must start without a logged-in user needs its secret stored for all users, which is a different setting from storing it for this session only.

With nothing useful in the dialog, journalctl -u NetworkManager -b shows why activation failed. The shell client never touches that path, which is why it keeps working while the desktop copy does not.

As a final check, compare the plugin version with the distribution release. A mismatched plugin can install cleanly and still refuse to activate a profile that nmcli imports without complaint.