the brief
OpenVPN Inc., the company behind OpenVPN, builds its commercial products on the same protocol as the open-source project, and it needed new features in that protocol on a steady schedule. Building them privately wasn’t an option, so every feature had to be designed, reviewed and merged in the open-source OpenVPN project first.
That’s the work we do for them, and it sits on a long history with the project: we’ve been contributing to OpenVPN since 2016, with hundreds of commits merged, from the networking layer and data channel offload to six of the new features listed in the OpenVPN 2.7 release notes.
why not a fork
OpenVPN is an ecosystem as much as a protocol: clients and servers from many vendors and communities have to keep talking to each other. A proprietary extension would have split the client’s products off from that ecosystem, with every future OpenVPN release becoming another merge to fight through. Upstream was the only route that kept the protocol whole and the client’s products compatible with it.
the networking layer
Until OpenVPN 2.5, configuring a tunnel on Linux meant OpenVPN launching external commands, ip, or even the older ifconfig and route, for every address and route it set up. That was slow, it depended on tools outside OpenVPN’s control, and it forced OpenVPN to keep root privileges, or to work around them, just to be able to run those commands.
We replaced it with a platform-generic networking API, so that OpenVPN’s tunnel and routing code no longer calls tools directly, and with sitnl, a small netlink implementation built for OpenVPN’s needs that talks to the Linux kernel directly. OpenVPN no longer spawns processes to configure its interfaces, the whole setup is much faster, and OpenVPN can keep working with just the network administration capability after dropping root privileges.
It shipped in OpenVPN 2.5 as the default on Linux, and we’ve kept building on it since, adding new operations as OpenVPN needed them and hardening it along the way, most recently by validating every netlink reply against the request that produced it.
data channel offload
The largest single piece of work is OpenVPN’s support for data channel offload, which lets the kernel move VPN traffic while OpenVPN handles the control plane. We designed it as a platform-generic API with a Linux implementation behind it, covering client and server modes, key installation and rotation in the kernel, and checks on which options DCO can handle. It shipped in OpenVPN 2.6 in January 2023, in about 60 commits, and the same API now carries the Windows and FreeBSD implementations as well.
The networking layer made this possible: DCO interfaces are created through sitnl, using an API we extended for the purpose. When the ovpn kernel module was merged into Linux 6.16 with a new interface, we moved OpenVPN onto it for the 2.7 release. How ovpn got into the kernel >
multi-socket servers
An OpenVPN server used to listen on exactly one socket: one address, one port, one protocol. Operators who wanted to accept both UDP and TCP, for example UDP for performance and TCP on port 443 for clients behind restrictive firewalls, had to run separate OpenVPN instances side by side, each with its own configuration and address pool.
Multi-socket support removes that limit: a single server can now listen on several addresses, ports and protocols at once, simply by listing more than one --local in its configuration. It’s a simple idea with deep consequences, because OpenVPN’s connection handling had been written around a single socket, and UDP and TCP clients had always followed separate paths through the code. The feature had been attempted before by other developers, and more than once the work had stalled and been set aside.
Gianmarco De Gregori on our team picked it up and started where the difficulty really was, by moving the event handling into shared code that both protocols could use, before adding simultaneous UDP and TCP sockets on top of it. The core series was merged in early 2025.
Getting it merged was only the start, since the feature touches almost every other part of the server. Over the following year he made it work with data channel offload on Linux, Windows and FreeBSD, with explicit exit notifications, with port sharing and with peer ID reuse, and it shipped as the first new feature listed in the OpenVPN 2.7 release notes. We still maintain it, most recently by moving its UDP handling onto the event engine’s own read and write flags.
what else shipped in 2.7
Client floating with DCO. Ralf Lici made clients that change IP address keep their session even when the data channel runs in the kernel.
PUSH_UPDATE. Marco Baffo added a way for servers to update settings on connected clients, a new DNS server for example, without forcing a reconnect, on both sides of the connection.
User-defined routing tables. Gianmarco added support for installing OpenVPN’s routes into a routing table of the user’s choice on Linux.
All of them are listed in the OpenVPN 2.7 release notes.
from start to merge
Each feature starts with the client’s engineers, where we work out together what the product needs and how it should fit the protocol. From there we implement it, submit it for public review, and stay with it until it’s merged: keeping contact with the community behind the project, answering review, and supervising every patch through its lifecycle, so that nothing is left waiting in a queue.
results
Features in the official releases. A new networking layer in OpenVPN 2.5, DCO support in 2.6, and six headline features of 2.7, all part of the open-source project that every OpenVPN user runs.
No divergence to carry. Everything the client needed lives upstream, so its products stay compatible with the wider OpenVPN ecosystem and every new release comes without a private patch set to rebase.
A lasting relationship. Hundreds of merged commits since 2016, and a presence in the project that has grown from one engineer to a team of four.
what it took
Writing a feature is only half the job in an open-source project the size of OpenVPN. The other half is fitting it into a codebase with many platforms and many users, earning the trust of its maintainers, and carrying the work through review without letting it stall. That’s the part where features like multi-socket had stopped before, and it’s the part we’re good at.
if this sounds familiar
If your product depends on an open-source project and you need features in it rather than in your own fork, we can design them, get them merged, and keep them there.
Just book a call and let’s discuss.
More about our networking and kernel work · Our open-source contributions