openvpn3-linux moves configuration and session management into six D-Bus services

The change from 2.x is process architecture, not the protocol

OpenVPN 3 Linux is described as an OpenVPN platform which builds on capabilities available on newer Linux distributions, and the README compares it with the more classic OpenVPN 2.x generation in terms of how much of the VPN life cycle is covered. In the older generation, OpenVPN 2.x provides a single executable which is responsible for a single VPN session. There is no configuration or session management in OpenVPN 2.x itself, and it depends on the systemd [email protected] and [email protected] unit files, the Network Manager OpenVPN plug-in, or other third party management tools to do that work. OpenVPN 3 Linux provides full configuration and session management in addition to providing the VPN tunnel itself. That is the whole difference in one sentence, and it is a process architecture difference rather than a change to how the tunnel is established, which is why the same OpenVPN 3 Core library used in the OpenVPN Connect clients is used here too.

Network configuration is split into its own low privilege process

The privilege separation model is the part of the design that most changes what a deployment looks like. Through it, the network configuration aspect of the VPN tunnel is split out into its own process which runs with as few privileges as possible. In practice that means it can only do network configuration changes. This process knows nothing about the connection to the VPN server; it just facilitates creating the virtual network adapter and configuring it with network routes. The service is also capable of setting up the DNS resolver out of the box, which the README contrasts with OpenVPN 2.x, where the same result would need additional scripts or specific plug-ins to trigger such updates on the system. The user visible consequence is that an unprivileged user can start their own VPN sessions and manage them themselves, and VPN configuration profiles can be shared with other users on the system or kept private, all without installing anything additionally.

Six background services, all of which idle out

The architecture is based on splitting the functionality into several independently running services, referred to as backend services, and the interaction with them happens through a user front-end. The README warns that there are six services, which is good to beware of, and that all of them will normally start automatically, and that when they are idle for a while with no data to maintain, they will shut down automatically. Four of them are named in the visible documentation: The configuration manager, openvpn3-service-configmgr, takes all configuration profiles and manages them before a tunnel is started, and it also ensures that only users granted access to imported VPN profiles have the proper access to them, and it runs as the openvpn user. The session manager, openvpn3-service-sessionmgr, manages all VPN tunnels which are about to start or have started, communicates with the backend processes, and ensures only users with the right access levels can manage the various tunnels. The backend starter, openvpn3-service-backendstart, is a helper available only to the session manager, whose only task is to start new VPN client backend processes. The client service, openvpn3-service-client, must be started by that helper, one process per VPN client, and it registers itself with the session manager once running.

* `openvpn3-service-configmgr`
* `openvpn3-service-sessionmgr`
* `openvpn3-service-backendstart`
* `openvpn3-service-client`

Three command line utilities, and the D-Bus API underneath

To interact with the services running in the background, three utilities are provided: The first is openvpn2, an interface which tries to look and behave more like the classic OpenVPN 2.x versions. It only allows options which are supported by the OpenVPN 3 Core Library, plus a handful of options which are ignored since a connection can be established without them, and only client side options are supported. When running openvpn2 with the daemon flag it returns a D-Bus session path to the VPN session, and that path can be used by the openvpn3 utility to manage the session further. The second is openvpn3, a brand new command line interface which does not look like OpenVPN 2.x at all, which can start, stop, pause and resume tunnels, retrieve tunnel statistics, act as import, retrieve and manage configurations in the configuration manager, and handle access control lists for VPN configuration profiles and running sessions. The third is openvpn3-admin, which will mostly only work when run as root, and is used to adjust settings or retrieve information for the backend services and other system administration tasks. Underneath all three, the integration between the user front-end and the backend services is built on D-Bus, which the README points at as the extension point: any programming language supporting D-Bus can be used to extend and implement richer functionality.

* `openvpn2`
* `openvpn3`
* `openvpn3-admin`

The same core library as OpenVPN Connect, with a narrower option set

One paragraph in the README covers the compatibility question directly. The same OpenVPN 3 Core library which is used in the OpenVPN Connect clients is also used in this project, but the implementation does not support all options OpenVPN 2.x does. The practical guidance is that if you have a functional configuration with OpenVPN Connect, typically on Android or iOS devices, it should work with this client. In general OpenVPN 3 supports routed TUN configurations, while TAP and bridged setups are not supported and will not work. That last sentence is the boundary to hold on to. It is not a caveat about untested configurations, it is a statement that a whole class of deployment, the layer two bridged setups that some sites still rely on, is out of scope for this client. If your existing setup is bridged, this is the wrong tool regardless of how the option coverage compares.

Packages come from the wiki, and Python is a first class front-end

The install story is deliberately thin in the repository. Pre-built binaries are handled by the community wiki, with instructions on how to install pre-built OpenVPN 3 Linux packages on Debian, Ubuntu, Fedora and Red Hat Enterprise Linux, and getting started is covered by the QUICK-START document. The repository itself is a Meson build, with meson.build, meson_options.txt, a src directory, an openvpn3-core directory, and the supporting pieces a project of this size accumulates: addons, contrib, distro, docs, doxygen, m4, subprojects, vendor, scripts, a bootstrap.sh and the usual meta files including BUILD.md, CLA.md and COPYRIGHT.md. The front-end story is the other half. The project ships with a Python 3 module which can be used to implement your own OpenVPN front-ends, so an organisation that wants a custom interface, a desktop panel, or a scripted wrapper can write one against the same D-Bus API the shipped utilities use.

This GitHub repository is a mirror, and the licence is AGPL

Two facts about the repository itself matter for anyone adopting it. The description says it plainly: this is a mirror of the Codeberg project at codeberg.org/OpenVPN/openvpn3-linux, and the homepage points at the Codeberg URL rather than at GitHub, and the default branch is master. So the source of truth for issues, commits and releases is elsewhere, and the GitHub copy exists for people who look there first, which is a reasonable thing to want but it does mean that reading the commit history here is reading a copy. The licence is AGPL-3.0, which is the significant legal difference between this and most VPN clients, because it reaches a modified version offered over a network. The repository is not archived and the last push was on 2026-10-14, and there are no GitHub releases, since the releases are published from the Codeberg side.

Editorial conclusion

Adopt openvpn3-linux if you are on a modern Linux distribution, want unprivileged users to start and manage their own tunnels, and need the network configuration and DNS setup handled without extra scripts or a Network Manager plug-in. Do not adopt it if you need TAP or bridged configurations, because the documentation says plainly that those are not supported and will not work, and do not adopt it on the assumption that the GitHub copy is the source of truth, since it is a mirror of the Codeberg repository. Before you deploy, read the QUICK-START document, check that the pre-built package exists for your distribution, and confirm that a configuration which works with OpenVPN Connect on Android or iOS is acceptable to you, since the option coverage is narrower than OpenVPN 2.x.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. OpenVPN/openvpn3-linux on GitHub
4. Project website
5. README