No VPN button on the desktop: is the profile still there?
A missing panel is an interface question, not proof the protocol vanished. List saved profiles by UUID, then activate one with nmcli before reinstalling.
Reinstalling packages rarely brings back a VPN entry that the desktop network menu never drew. The panel and the connection are two objects with two owners: the desktop frontend draws what its plugin exposes, and the networking service holds the profile. One can vanish from the menu while the other keeps working, which is why the menu is the wrong place to start. Check the profile first, then decide whether the desktop or the connection is what is actually broken.
The button and the profile are owned by different things
A desktop network page renders whatever the installed frontend and its VPN editor components know how to render. NetworkManager, or whatever service owns networking on that machine, keeps the connection definition and decides whether it can be brought up. Nothing forces the two views to agree, and after a desktop change, a distribution upgrade or a run against a development release they frequently do not. The panel can therefore be incomplete without the tunnel being missing. Reading that as a protocol problem leads straight into the reinstall loop that fixes nothing.
| What the screen shows | Check it against | What the answer rules out |
|---|---|---|
| No VPN section at all | nmcli connection show | Whether any profile exists |
| A VPN section with an empty list | The editor or plugin package for that VPN type | Whether the frontend can draw it |
| The same profile listed twice | Both UUIDs | Whether an import loop made copies |
Work the table from the top, because each row answers a different question and the first row is the cheapest. A profile that exists moves the problem to the frontend, while no profile at all moves it to provisioning. Guessing which of the two you have is what turns a ten-minute check into an afternoon of reinstalls.
Ask NetworkManager what it has saved
Ask the service directly instead of reading the menu, because two commands separate what exists from what is running. Run them on the machine itself, and run the second one before and after any activation attempt. The lists are not interchangeable, and the difference between them is the diagnosis.
nmcli -f NAME,UUID,TYPE,DEVICE connection show
nmcli connection show --activeA saved profile can be inactive, which is normal and says nothing about the desktop. Two entries with similar names are common after an import loop, and only the UUID tells them apart. A tunnel that another service owns directly may never enter this list, so an empty result is not automatically a NetworkManager defect. Select by UUID from here on, because names are labels people edit and identifiers are not.
Inspect the profile instead of re-importing it
When the profile exists, read its details without asking for stored secrets. When it does not exist, use the provisioning or import workflow the plugin documents, once, and confirm what it created. Repeating an import because the menu stayed empty is how a machine ends up with four competing copies of one connection.
Those copies are drift with a paper trail nobody reads: the desktop user cannot say which one would have been used, and neither can the next administrator. Delete the duplicates deliberately, after recording their identifiers, rather than letting the import loop decide. Keep a note of the UUID that survives, because that value is what the terminal activation needs. A profile that was imported twice under different names is usually one working definition and one artifact of impatience. A profile list is configuration, and it deserves the same care as the connection itself.
Activate the saved profile from a terminal
The nmcli documentation covers activating a selected profile interactively, which makes the command line a supported second interface rather than a workaround. Replace the example identifier below with the UUID you kept. Understand what the command does before running it, because it changes network state. Routes and DNS can move, and a remote session over the interface being reconfigured will not survive.
Run it from a local console, or with a plan for getting back in when the change goes wrong. The --ask option collects inputs the profile is missing; it does not bypass system authorization. Nor does it guarantee that every plugin authentication prompt works in a terminal, since some expect a dialog you cannot reach there.
nmcli --ask connection up uuid 11111111-2222-4333-8444-555555555555Read the result before blaming the desktop
If the profile comes up, the saved connection works and this management path works. That narrows the complaint to the frontend, which is a different component list and often a different team. If it does not come up, the failure sits in the profile or the tunnel, and the desktop was never the problem.
A successful activation still says nothing about whether the frontend's editor component is present, or whether the panel itself misbehaves. Those remain questions for the distribution's supported frontend and its matching plugin packages. Bundling them into a reinstall usually leaves the panel exactly as it was and adds a reboot to the story.
A useful report names the desktop release, the connection type, the panel operation that is missing, and whether the profile is visible or activatable through the supported interface. Describing a missing menu requires neither a private key nor a profile that carries credentials. That is enough for a maintainer to reproduce the panel state without touching any credential.