ConnMan VPN: The Missing Menu Is a Daemon, Not a Protocol

The belief is that a ConnMan system without a VPN entry in the desktop has no VPN support installed. It usually has support for Wi-Fi and none for the VPN daemon, the provider configuration or the authentication agent, and those are three separate absences. The menu is a view onto those components, not the feature itself. Checking the version and the packaging tells you more in one command than any number of desktop bug reports.

The myth: the menu is the VPN feature

Start with the installed ConnMan version and the packages that came with it. A bug report from an older release describes a different feature set, and quoting it usually ends with someone reinstalling a network manager they did not need to replace.

Write down what you actually have before changing anything: the daemon binary, the provider directory, and whether an agent is present.

Which daemon owns the tunnel

In Debian bookworm's ConnMan 1.41 documentation, connman-vpnd is the daemon that manages VPN connections alongside connmand. It lists integrations for named VPN helpers, including OpenVPN and OpenConnect. That list is a statement about helpers, not a promise that every protocol or authentication workflow will work. Read it as a menu of what to check, not as a compatibility guarantee.

Then match the integration to the gateway's approved protocol. The word Cisco does not tell you whether you need a legacy vpnc-style connection or an AnyConnect-compatible workflow, and choosing wrong produces an authentication failure that looks like a credential problem.

If both a standalone helper and ConnMan can bring the tunnel up, decide which one owns routes, DNS and lifecycle before either starts.

Daemon settings are not provider settings

The daemon's general configuration and an individual provider's configuration are different files with different formats. In the documented bookworm arrangement the daemon reads /etc/connman/connman-vpn.conf, while provider provisioning files live under /var/lib/connman-vpn/ with a .config suffix. Dropping an OpenVPN profile into that directory does not turn it into a ConnMan provisioning file. The versioned provider manual describes the provider sections and the type-specific fields those files actually need.

Translate only through the installed integration's supported mapping. Certificate trust, private key references, gateway identity, routes and authentication inputs each keep their own role, and a sample for a different provider type is not interchangeable just because both need a server address.

When a provider fails to load, compare its fields against the manual for the installed release rather than against a blog example.

The authentication agent is a separate dependency

A provider definition can still need an agent to obtain credentials or finish an authentication exchange. For its OpenConnect integration, the same manual explains that missing authentication-related values can be requested through the VPN Agent API, and that a short-lived cookie is not generally suitable as a permanent configuration secret. That mechanism does not guarantee support for every browser login, MFA prompt or gateway posture check. Confirm the whole workflow with whoever owns the deployment.

Do not compensate for an absent agent by writing a password or a session token into a broadly readable file. That converts a missing integration into a credential exposure, and the second problem outlives the first.

If the gateway needs an interactive login, the agent is part of the design rather than an optional extra.

Verify four outcomes, not one

After authorized provisioning, check four things separately: the provider is selected, the connection authenticated, the effective routes are the ones you intended, and the resolver behaves as expected. A running daemon, a listed provider and an application reaching its resource are three different outcomes, and only the last one is the user's actual goal. Recording them separately tells you which stage to fix.

Include reconnection behaviour and the required unavailable-state policy in that check, because a tunnel that comes up once and never recovers is not deployed. Keep the working base-network configuration recoverable while you change the VPN integration.

Replacing the Wi-Fi manager to obtain a button is a much larger change than the missing operation required, and it is usually the myth winning.