Vendor VPN App vs NetworkManager: Who Owns the State?
A profile names a plugin, not the vendor client's behaviour. Map who owns enrolment, DNS, blocking and updates before you switch a managed laptop.
Importing a profile is not the same thing as replacing a client. NetworkManager stores a plugin type together with plugin-specific data and secrets, and the plugin that owns that type decides what the connection can do. Everything the vendor's application layers on top, from enrollment to always-on blocking, lives outside the file. Whether the switch is safe depends on which of those layers you actually rely on.
The file names a plugin, not a feature set
NetworkManager's VPN settings reference describes a service type that selects the plugin, plus an opaque data dictionary and a secrets dictionary that only the plugin interprets. The profile is a contract with one implementation, not a description of behaviour that any client can reproduce. Two clients can speak the same protocol and still differ in what they negotiate and which data paths they enable. A protocol label tells you what the tunnel is, never what the surrounding client does with it.
Compare requirements rather than wrappers, then. The question is not whether the alternative connects, because it usually can; it is whether every requirement that made the original client acceptable survives the move. Write those requirements down before installing anything, or the comparison turns into a hunt for whatever breaks first.
What the vendor app adds around the tunnel
Vendor clients commonly bundle enrollment and device posture checks, a second-factor flow with its own interface, always-on blocking, an update channel and support tooling. Some of that sits next to the protocol, and some of it is a separate product that merely shares an installer. NetworkManager can replace the tunnel and its routing, and dispatcher scripts can fire actions when the connection changes state. It does not reproduce a blocking engine, a certificate renewal workflow, or an assumption about which user may bring the connection up.
More components does not mean safer, and fewer does not mean weaker. The question is which component enforces the policy you were told to follow. If an auditor asks what blocks traffic when the tunnel drops, the answer has to name something that actually does it, and a profile that only connects is not that answer.
Where ownership actually differs
Read this as an ownership map rather than a checklist, because the failures below are ownership gaps and no amount of client configuration closes them. Each row names the layer, the side that usually holds it today, and where the gap shows up first.
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
Pair every row with an observation you can repeat rather than a feeling about the client. A name resolved through the intended resolver, a route that disappears when the tunnel stops, and a blocked connection after a simulated drop are three observations that between them cover most of the table. Write the observation beside the requirement it proves, and keep the ones that failed, because a failed observation is the only part of the record that predicts the next incident.
Switching without overlapping ownership
Running the vendor client and a NetworkManager connection for the same service at once is the most common way these comparisons go wrong. Both install routes, both may set DNS, and both may touch firewall state. What you then measure is a third arrangement that matches neither client's documented behaviour.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"The first command tells you whether the profile is a VPN type at all. The second shows the plugin service type and which secrets are stored, which matters when a key is expected from an agent instead of the file. The journal is where a plugin that loaded but failed to negotiate will say so. If none of the three shows a problem, the gap sits in the policy layers above the tunnel rather than in the connection.
Disconnect the old client before enabling the new connection, keep endpoints and account identical, and write down which component owns routes, resolver settings and blocking. That note is what stops the next update from ending with two owners.