OpenVPN 3 Linux client - v3 beta release


As some of you know, I've been involved with the OpenVPN packages for some
time as well as being an upstream OpenVPN developer and maintainer. Now we
have released the third beta release of OpenVPN 3 Linux.

This new client shares the same code base the OpenVPN Connect (proprietary)
clients uses as well as the OpenVPN for Android when switching to use the
OpenVPN 3 backend. The OpenVPN 3 code base is a rewrite in C++ and makes use
of the more modern features of C++11.

The Linux version is also very different from the OpenVPN 2.x generation, as
it is now D-Bus based. We have done this to allow easier integration with
other users and front-ends on Linux as well as having a better privilege
separation. Once all the backend pieces of OpenVPN 3 Linux has settled non of
them runs with more privileges than absolutely needed and there are several
services running which is responsible for only a subset of the features. This
is probably the least privileged OpenVPN implementation available today. On
top of that, we have also tried to make DNS configuration work out-of-the-box
as well (but here we need much more work to be really complete).

Part of this project we're also trying to get some kind of equivalent of the
Android VPN API in place on Linux. We have our own D-Bus service which
provides the needed functionality and can hopefully work as a stepping stone
towards something which can also be used outside OpenVPN alone too. The
current implementation should already provide all the needed features to
create and configure TUN devices (including IP addresses, routing and DNS) for
unprivileged users.

I'm announcing this here now as we also have Fedora Copr builds available for
EPEL-7, Fedora 28, Fedora 29 and Rawhide. In not too far future I would like
to get the process running to get the openvpn3 package into the mainline
Fedora repositories as well.


Our main source repositories can be found here:

We would be very much interested to get more users to try this out and to move
this project forward. The current codebase is in a reasonably good shape. It
is a bit rough around the edges when it comes to the DNS configuration and
/etc/resolv.conf handling, but otherwise it is fairly production ready.

This project aims to have good and reasonable documentation. I'm not saying
we're perfect in this regards, and we're open to improve here too. All D-Bus
services should be fairly well documented and we should have man pages for
most of the binaries we provide.

* D-Bus details

* man pages:

Feel free to reach out if you have some questions or good ideas.


Re: OpenVPN 3 Linux client - v3 beta release

By Tom Hughes at 01/31/2019 - 18:01

So what does this mean for the server? Currently client and server
are the same program but it sounds like this is a pure client so does
that mean client support will be removed from the current program to
make it server only? or that there will be a new server?


Re: OpenVPN 3 Linux client - v3 beta release

By David Sommerseth at 01/31/2019 - 18:14

On 01/02/2019 00:01, Tom Hughes wrote:
Yes, this is a pure client. But it is mostly backwards compatible with
OpenVPN 2.x servers. The most noticeable missing features are support for TAP
devices and the lack of --fragment. TAP support is not planned, as all VPN
APIs on mobile devices and even the Unified Windows Platform (UWP) API does
only support TUN mode.

Users depending on TAP may continue to use OpenVPN 2.x for a long time
forward, but should start considering to switch to routed TUN in the future.

The --fragment features is troublesome. It is unfortunately needed in some
networks, but it is a quite heavy feature to implement - especially when this
is not too often needed. This feature basically needs to do a lot of a
similar task you'll find in the TCP stack, and in particular packet reassembly
and keep track of packets received - and then the chunking of packets into new
sizes. We are investigating better solutions to --fragment, both in the
company and within the community. Our ideal goal would be that --fragment
would no longer needed and the OpenVPN protocol itself would figure out how to
solve this issue when it occurs.

There are more options which are unsupported (if you test your configuration
with the openvpn2 front-end provided in the openvpn3 package, you'll notice
soon enough). We will backport those options which makes sense and has a real
use case (like --verify-x509-name). But the overall idea is to try to reduce
the quite enormous amount of options available in OpenVPN 2.x.