NetworkManager Will Not Import Your OpenVPN Profile? Read This

Profiles that connect fine in another OpenVPN client can refuse to import into NetworkManager, and the dialog blames the plugin's import capability. That sentence is about your machine, not about the file or the server. Importing is a local operation performed by the manager's VPN plugin, and at the moment it fails nothing has been sent anywhere. Treat it as a packaging question first and a parsing question second.

Read the message as a local statement

The phrase describes the plugin's feature set. Either the plugin that provides OpenVPN support is missing, or the component that offers the import action is older than the format you are feeding it. Both cases are local to the machine in front of you.

Notice what the message does not say. It does not say the certificate is wrong, the password expired, or the server is down, so a restart or a credential change cannot fix it. Read it as a statement about installed software.

That distinction saves the most time in this whole article, because the reflex is to look outward at the gateway when the failure is entirely on the desktop.

Step 1: confirm the plugin and the editor

Two packages matter and they do different jobs. One provides the NetworkManager VPN plugin that owns the connection; another provides the desktop editing and import front end. Installing only the runtime, or only the editor, gives you half a feature.

nmcli --version
nmcli connection show
rpm -q NetworkManager-openvpn NetworkManager-openvpn-gnome 2>/dev/null

dpkg -l | grep -i network-manager-openvpn

Use the packaging command your distribution actually has; the two lines above are alternatives, not a sequence. Also confirm you are in the NetworkManager flow at all, because a different OpenVPN client with its own importer will not respond to any of this advice.

Installing the plugin usually restarts or reloads NetworkManager, which briefly drops existing connections. Do it deliberately rather than in the middle of a support call.

Step 2: import with nmcli and get a real message

The graphical dialog tends to collapse several failures into one sentence. The command-line importer is more specific, and it is the same operation:

nmcli connection import type openvpn file /path/to/client.ovpn
nmcli connection show --active

Read the response carefully. A complaint about a missing plugin is a packaging problem. A complaint about a specific directive is a parser problem. A complaint about a referenced file is a path problem, and the three have nothing in common beyond the word import.

Remember that success here creates a stored profile. It does not connect, and it does not prove that the profile kept every feature the original had.

Step 3: leave inline certificates where they are

Older advice tells you to strip every inline certificate and key block before importing. That advice is stale. The current importer handles inline objects, and deleting them removes the identity the connection needs while producing a profile that imports and then fails to authenticate.

If you do need to split material out for a specific reason, keep the original file and record which block went where. A profile that has been edited three times by three people is not a configuration you can reason about later.

The same caution applies to vendor directives. A client-specific option may be outside one plugin version's feature set without being invalid OpenVPN syntax, and removing it to make the dialog close can change behaviour quietly.

Step 4: check what the profile now means

After a successful import, inspect the endpoint, the authentication arrangement, the file references and where secrets are stored before you activate anything. Those four are where import and intent most often diverge.

Then check the behaviour you actually care about: routes, DNS and whether the original profile's features survived. Those are the three places where a successful import can still disappoint the person who asked for it. An import that succeeds and a connection that behaves correctly are two different results, and only the second one matters to the user.

If the imported profile behaves differently from the original client, compare the two configurations rather than rebuilding from memory, because the difference is usually one line.

Step 5: let one manager own the tunnel

Once the profile lives in NetworkManager, let it own the connection. Starting a separate OpenVPN process as a workaround creates a second management path with its own resolver behaviour, its own credentials and its own lifecycle.

Two tunnels that both believe they own the default route produce symptoms that look like a broken provider, and the fix is to remove one of them rather than to tune either.