nmcli VPN List: Saved Profiles vs Active Tunnels

You run nmcli connection show expecting a list of VPNs and get every connection the machine has ever saved, including a bridge and a hotspot. The VPN you are looking for may be there, may be typed as something other than vpn, or may not be a NetworkManager connection at all. Knowing which of those three cases you are in takes two commands.

Two lists, two questions

connection show answers what NetworkManager has saved, and connection show --active answers what is currently attached to a device. The first list includes inactive profiles, which is deliberate: a saved VPN that is down is still a profile you may need to fix. Confusing the two produces the impression that a tunnel is running when only its configuration exists.

Pick fields rather than reading the default table, because the default output hides the type on narrow terminals and wraps long names.

NAME, UUID and TYPE are usually all you need for a first pass, and then you inspect the one entry you care about by UUID.

TYPE is where the surprises are

OpenVPN connections managed through the plugin show up as type vpn, because the plugin is a service inside the generic VPN framework. Native WireGuard support is a first-class connection type of its own, so filtering on vpn will not find it. A search for a WireGuard tunnel that returns nothing is usually a filter problem rather than a missing profile. That is an architectural difference, not a naming quirk.

The same applies to other tunnel types that NetworkManager learned to handle natively over time, so read the TYPE column before concluding anything is absent.

List everything and filter afterwards, and the profile appears.

Read the UUID, not just the name

Names are labels that people edit, and two profiles can share one after a careless import. The UUID is the identity that commands and files reference. When an entry looks duplicated, compare the UUID and the underlying settings before deleting anything.

Activation commands accept either, which is exactly why a name-based habit eventually modifies the wrong profile.

Copy the UUID into your notes when you change something you may need to undo.

What a saved profile does not tell you

A saved profile says nothing about whether its tunnel is up, and an active connection says nothing about whether the traffic inside it works. A tunnel started by wg-quick or by a service unit is not a NetworkManager connection at all, so it is missing from both lists while the interface is clearly passing traffic. Check the interface and the routing table before assuming the profile is absent. An empty list proves only that NetworkManager is not the owner.

Two managers for the same interface is the other version of this problem, and it produces a list that looks right while the kernel state is owned by something else.

One owner per interface keeps the list honest, and the nmcli reference documents which fields each view actually reports.

Report without leaking secrets

connection show with a name prints settings, and adding --show-secrets prints the private keys and passwords with them. A troubleshooting paste into a ticket does not need those. Report the type, the UUID, the state and the relevant routes instead, and redact anything that came from a secrets store.

Interactive activation with --ask is the supported way to supply a missing credential, and unattended automation needs a different approved arrangement rather than a stored plaintext password.

A short, redacted report is easier to review than a full dump.