Support NetworkManager-managed OpenVPN profiles, alongside the existing wg-quick and NM WireGuard paths

[yoann54]

First, thanks for the privilege boundary section in the README — the setresuid-around-the-read on import and the reasoning about why the setup script goes through a terminal rather than pkexec are the most careful writeups I've read in a bar widget. It's why I'm filing this rather than just moving on.

The gap

OpenVPN is driven exclusively through openvpn-client@ with profiles in /etc/openvpn/client. WireGuard already gets two routes, one of them NetworkManager, which the README rightly points out needs neither the root helper nor wireguard-tools. OpenVPN has no equivalent.

Why that matters

Corporate OpenVPN with a one-time password (static-challenge, or a dynamic challenge from the server) cannot work through a systemd unit. There is no tty and no dialog in which to type a code that rotates every 30 seconds, and the stored-credentials model can't hold one by definition. So the whole class of 2FA work VPNs is out of reach of the OpenVPN backend today, even though the widget is otherwise exactly what I want.

NetworkManager handles this case: its secret agent prompts interactively at connect time, per connection, with a field for the challenge response. That's the same mechanism that makes it work on Ubuntu out of the box.

What I'm asking for

List and control OpenVPN connections from nmcli the way WireGuard ones already are — connections of type vpn with vpn.service-type ending in openvpn, brought up and down with nmcli connection up/down. No root helper, no /etc/openvpn/client, polkit governs activation. If it's useful, nmcli connection import type openvpn file <path> would slot in as a third option under Add config, next to the two WireGuard ones.

One question while I'm here

Does unified mode currently notice a tun interface that NetworkManager brought up on its own? I'd expect the interface-derived parts (address, routes, uptime, throughput) to work since they come off the interface, but there'd be no profile row to attribute it to. If it does show up, a partial view might already be closer than I think.

Happy to test patches — I have a static-challenge config to hand.

Environment: Omarchy 4 (Quattro), MultiVPN via omarchy plugin add, OpenVPN profile imported into NetworkManager with networkmanager-openvpn.

[robinnepomukmai]

Thanks for this — both the privilege-boundary note and the 2FA case. static-challenge through a systemd unit really is a dead end, and filing it instead of walking away is how the widget gets the missing route.

Your tun question: unified mode did not notice a tun that NetworkManager brought up on its own. Interface stats only attach to a connection the probe can name, and the NM loop only listed type=wireguard. An NM OpenVPN tunnel was invisible; if gpclient happened to be running, the leftover-tun fallback could even attribute it to GlobalProtect. So it was worse than a partial view.

That is on main now (plugin 1.2.0). OpenVPN in NetworkManager is listed and switched the same way WireGuard already was: connections of type vpn whose vpn.service-type ends in openvpn, up/down/delete/autoconnect via nmcli, no root helper. Add config offers NetworkManager as a third destination for an .ovpn file, next to OpenVPN 3 and openvpn-client@.

The interactive part is the reason this exists, so it is explicit: Omarchy does not ship a NetworkManager secret agent. A profile that needs a challenge (or any “ask every time” secret) opens a terminal with nmcli --ask connection up. Stored secrets still use a silent nmcli up; if that comes back with “no valid secrets”, it falls through to the same prompt. The widget does not store the OTP.

To pick it up:

omarchy plugin update io.github.nepomuk-software.multivpn
omarchy restart shell

If you still have that static-challenge config to hand, I would love to know whether the --ask prompt is enough on Omarchy 4, or whether a session secret agent still gets in the way. Happy to iterate from there.

[yoann54]

Works on Omarchy 4.0.2, plugin 1.2.0.

Profile: OpenVPN in NetworkManager, connection-type=password-tls,
password-flags=2, inline ca/cert/key/tls-auth extracted on import.
Auth is username + TOTP in the password field — no static-challenge,
and the server sends no dynamic challenge either.

The --ask terminal is enough. No session secret agent installed
(no nm-applet), the terminal opens, the code goes in, the tunnel
comes up and the row picks up address, uptime and throughput.
Nothing got in the way.

Two things worth knowing for the challenge case you were worried about:

• NetworkManager set challenge-response-flags=2 by itself at import,
  even though the .ovpn has no static-challenge. It never prompted
  for it — only the password field appeared. So that flag alone isn't
  a reliable signal that a profile needs a second field.

• Renegotiation is a non-issue on this profile: reneg-sec 2592000
  (30 days). So I can't tell you what happens if a server re-asks for
  an OTP mid-session with no terminal open. Someone with a shorter
  reneg-sec would need to test that.

Also: username is not in the secret store, so the profile fails
with nothing useful in the log until you set it by hand
(nmcli connection modify <conn> +vpn.data username=<user>).
Might be worth surfacing in the panel when an NM OpenVPN row has no
username — it's the one thing no prompt can fill in.