OpenVPN Missing From Ubuntu 18.04's VPN Menu: What to Install

GNOME's VPN list can offer nothing that matches the profile you were handed, and the usual conclusion is that the desktop cannot do OpenVPN. It can. What is missing is a plugin package, and the command-line client sitting on the same machine has nothing to do with the menu. That is the myth worth killing first, because it sends people to reinstall the wrong thing.

The menu lists plugins, not protocols

GNOME renders connection types that the network manager reports, and the manager reports plugins that are installed. An empty list therefore describes the installed plugin set rather than the protocol's capabilities. That is why a working openvpn binary changes nothing in the panel.

The distinction matters because the two failures look identical from the panel. A missing plugin and a broken plugin both produce a dialog that cannot help, and only the first is fixed by installing something. Asking the manager what it knows separates them before you install anything. That question costs one command and replaces an hour of guessing.

Which package owns the dialog

On Ubuntu 18.04 the packages have specific names, and newer releases kept the same split. Read them as roles rather than as alternatives, since installing one rarely solves the problem on its own. One package holds the daemon plus the command-line client, and neither is aware of any settings dialog.

The plugin package is what lets the network manager create, store and start an OpenVPN connection. The editor package supplies the form, its fields and the save path the panel calls. A machine with the plugin and no editor shows a type it cannot configure, while a machine with the editor and no plugin shows nothing at all. Install the set together and the ambiguity disappears.

sudo apt install openvpn network-manager-openvpn network-manager-openvpn-gnome
nmcli --version

On 18.04 those are the real archive names rather than stand-ins. A KDE desktop needs its own editor package and still needs the plugin, which is the part a GNOME-only guide leaves out.

A restart is part of the install

The panel asks the manager for its supported types at service start, and a list already rendered is not refreshed by an install. Installing while the service runs therefore produces the frustrating combination of a successful install and an unchanged dialog. Restarting is not optional housekeeping; it is the step that makes the install visible.

Restarting cuts connectivity for several seconds, and any SSH session riding the same interface goes with it, so plan for that if the machine is remote. Then reopen the panel and ask the manager directly what it supports. A direct query is better evidence than a menu that may be cached.

sudo systemctl restart NetworkManager
nmcli -f NAME,TYPE connection show
nmcli connection add type vpn

The last command is the discriminating test. Given the plugin, it fails on missing arguments; without it, it reports an unknown VPN type. One outcome is a form waiting to be filled in, and the other is still a packaging problem. Run it before and after the install if you want the contrast to be obvious.

Let nmcli read the .ovpn

Nothing forces you to rebuild a supplied profile control by control. The manager reads .ovpn files directly and turns their directives into a stored connection, inline certificates included. Importing also beats transcription for accuracy, because a mistyped cipher or a truncated key produces a failure that looks like a server problem.

Leave the profile next to any key or certificate it references until the save completes, because a connection that stores only file paths breaks when those files move. Then test the connection by name, and answer any credential prompt in the foreground so you can see what it wants. A saved connection that has never been activated is not evidence of anything.

nmcli connection import type openvpn file ~/Downloads/office.ovpn
nmcli --ask connection up office
nmcli -f NAME,TYPE,STATE connection show --active

That third command confirms the tunnel is up under the name you expect. It also separates a connection that failed from one that was never activated.

What the menu cannot tell you

An absent type says nothing about the gateway, and it does not mean the server refuses OpenVPN. It is not a reason to install an unrelated protocol plugin so that a menu entry appears. That second mistake has a name in practice: people end up aiming a PPTP or AnyConnect profile at an OpenVPN service because those were the entries on offer.

Repair the packaging first; the server question comes afterwards. A profile that imports cleanly and never authenticates is failing on a certificate, TLS or credential question rather than an editor one. Each of those leaves different evidence behind, and none of it appears in the dialog. Read the client log before you reopen the settings panel.

Prove it with a resource you actually use

Once the type exists and the connection is saved, dial it and open a resource you actually use. Activation alone proves only that the two ends agreed on a tunnel. A tunnel that comes up and carries nothing is the next failure mode, and the panel cannot see it.

Write down which resource you tested, so the next person repeats that check instead of starting over. When the tunnel is up and the resource still fails, the investigation moves to routes and DNS rather than back to the dialog. That note is the difference between a fix and a story.