decision: stay on OpenVPN 2.x, no openvpn3-linux migration #92

New issue

Closed

opened 2026-08-20 13:04:30 -04:00 by mysticalsoap · 1 comment

mysticalsoap commented

2026-08-20 13:04:30 -04:00

Owner

What openvpn3-linux would offer

Native D-Bus API (sessionmgr/configmgr signals) — no management-socket text protocol, no parse_event. Structurally aligned with aqomui's existing GUI ↔ root-service D-Bus split.
Real privilege separation out of the box: netcfg holds CAP_NET_ADMIN, sessions are owned by the unprivileged user. Could shrink aqomui's root service surface.
Same DCO kernel module, actively developed by OpenVPN Inc.

Why it loses anyway

openvpn3-service-netcfg owns tun creation, routing and DNS by design. aqomui's reason to exist is owning exactly that layer itself (cgroup-v2 split tunnel, table 11 bypass, fwmark pins, route-noexec + route-up scripts). The whole fork would be fighting a component built to do its job for it. 2.x's dumb-process model — OpenVPN as a subprocess you hand --route-noexec and orchestrate — is the right substrate for a split-tunnel manager.
No --up/--down script hooks in the 2.x sense: double-hop (hop.sh) and bypass (bypass_up.sh) would need rearchitecting against the D-Bus session model.
Routed tun only — tap configs stop working entirely (2.x at least runs them).
Reduced option compatibility with the 2.x configs every provider ships; custom user configs are a supported aqomui feature.
2.x is not legacy: 2.7 shipped DCO, new DNS handling, ISO logging. The text protocol that remains (management interface) is documented, stable, and now fixture-pinned by the capture lab — the risk it once posed is handled.

Re-evaluate if: OpenVPN Inc deprecates the 2.x branch or its management interface, or netcfg grows a supported "hands-off, app owns routing" mode.

Decision record: evaluated while retiring the last log scraping (#26, #91). Recording why aqomui stays on OpenVPN 2.x rather than migrating to openvpn3-linux, so the question doesn't get re-litigated from scratch each time text parsing annoys someone. **What openvpn3-linux would offer** - Native D-Bus API (sessionmgr/configmgr signals) — no management-socket text protocol, no `parse_event`. Structurally aligned with aqomui's existing GUI ↔ root-service D-Bus split. - Real privilege separation out of the box: netcfg holds CAP_NET_ADMIN, sessions are owned by the unprivileged user. Could shrink aqomui's root service surface. - Same DCO kernel module, actively developed by OpenVPN Inc. **Why it loses anyway** - `openvpn3-service-netcfg` *owns* tun creation, routing and DNS by design. aqomui's reason to exist is owning exactly that layer itself (cgroup-v2 split tunnel, table 11 bypass, fwmark pins, route-noexec + route-up scripts). The whole fork would be fighting a component built to do its job for it. 2.x's dumb-process model — OpenVPN as a subprocess you hand `--route-noexec` and orchestrate — is the right substrate for a split-tunnel manager. - No `--up`/`--down` script hooks in the 2.x sense: double-hop (hop.sh) and bypass (bypass_up.sh) would need rearchitecting against the D-Bus session model. - Routed tun only — tap configs stop working entirely (2.x at least runs them). - Reduced option compatibility with the 2.x configs every provider ships; custom user configs are a supported aqomui feature. - 2.x is not legacy: 2.7 shipped DCO, new DNS handling, ISO logging. The text protocol that remains (management interface) is documented, stable, and now fixture-pinned by the capture lab — the risk it once posed is handled. **Re-evaluate if**: OpenVPN Inc deprecates the 2.x branch or its management interface, or netcfg grows a supported "hands-off, app owns routing" mode.

mysticalsoap commented

2026-08-20 14:05:34 -04:00

Author

Owner

Follow-up question worth recording: could aqomui just be a frontend for openvpn3-linux, and does its service have legitimate features beyond it?

Overlap is one thin slice. What openvpn3-linux provides — launch one OpenVPN tunnel, track its state over D-Bus, DCO, store imported profiles — corresponds to mgmt.py plus the process-spawn part of tunnel.py. Everything else aqomui-service does has no openvpn3 counterpart:

WireGuard tunnels (openvpn3 is OpenVPN-only, categorically)
kill-switch firewall / leak protection (iptables, per-server allows)
app-level split tunnel: cgroup v2 classification, table 11, fwmark pins, bypass-over-a-second-VPN
double-hop across providers (chained processes + hop routing scripts)
obfuscation transports (OpenVPN over stunnel/SSH)
provider integration: server-list/config/cert fetching, latency, server browser
DNS policy (alt servers, dns-off, pushed-DNS read-back)
tap configs (2.x runs them; openvpn3 is routed-tun only)

So "just a frontend" is not available as an architecture. The firewall, cgroup, routing and WireGuard work all need a privileged agent regardless — aqomui-service survives any migration; openvpn3 could only replace the small slice, while adding three daemons and the netcfg ownership conflict noted above.

Does an openvpn3 frontend already exist? No official GUI ("OpenVPN Connect" does not ship for Linux; the client is CLI/D-Bus only). The only notable community frontend is openvpn3-indicator, a tray toggle for already-imported profiles, self-described as a stopgap until NetworkManager grows openvpn3 support. Nothing in that space touches aqomui's actual feature set — a thin openvpn3 frontend would be a different, much smaller product.

Follow-up question worth recording: could aqomui just be a *frontend* for openvpn3-linux, and does its service have legitimate features beyond it? **Overlap is one thin slice.** What openvpn3-linux provides — launch one OpenVPN tunnel, track its state over D-Bus, DCO, store imported profiles — corresponds to `mgmt.py` plus the process-spawn part of `tunnel.py`. Everything else aqomui-service does has no openvpn3 counterpart: - WireGuard tunnels (openvpn3 is OpenVPN-only, categorically) - kill-switch firewall / leak protection (iptables, per-server allows) - app-level split tunnel: cgroup v2 classification, table 11, fwmark pins, bypass-over-a-second-VPN - double-hop across providers (chained processes + hop routing scripts) - obfuscation transports (OpenVPN over stunnel/SSH) - provider integration: server-list/config/cert fetching, latency, server browser - DNS policy (alt servers, dns-off, pushed-DNS read-back) - tap configs (2.x runs them; openvpn3 is routed-tun only) **So "just a frontend" is not available as an architecture.** The firewall, cgroup, routing and WireGuard work all need a privileged agent regardless — aqomui-service survives any migration; openvpn3 could only replace the small slice, while adding three daemons and the netcfg ownership conflict noted above. **Does an openvpn3 frontend already exist?** No official GUI ("OpenVPN Connect" does not ship for Linux; the client is CLI/D-Bus only). The only notable community frontend is `openvpn3-indicator`, a tray toggle for already-imported profiles, self-described as a stopgap until NetworkManager grows openvpn3 support. Nothing in that space touches aqomui's actual feature set — a thin openvpn3 frontend would be a different, much smaller product.

mysticalsoap closed this issue

2026-08-20 14:12:25 -04:00