OpenVPN/openvpn: the C daemon behind most self-hosted VPNs

What OpenVPN/openvpn actually is, and who compiles it

The repository describes itself in one line: "OpenVPN -- A Secure tunneling daemon". That word, daemon, is the whole scope. This is the C program that creates and terminates tunnels, plus the build system, tests, sample scripts and documentation around it. It is not the OpenVPN Connect client, not the Access Server product, and not the Windows GUI. Those exist, but they are distributed separately, and the README only points at the community download page for releases.

The people who need this repository are the ones who cannot use a packaged client: distribution maintainers, firewall and router vendors, platform engineers who need a tunnel inside a container or an embedded image, and administrators who want the tunnel under their own configuration management. If you want a VPN icon in a menu bar, this is the wrong entry point. The README explicitly separates concerns, noting that easy-rsa and tap-windows now live in their own subprojects, and that community Windows MSI and Debian packages are built from openvpn-build rather than from this tree.

How the daemon and its configuration model fit together

The layout tells you most of the architecture. src/ holds the daemon; ssl.h in the source distribution is described in the README as the description of the underlying protocol, which is a useful signal about where the interesting logic lives. The build is autotools-first (configure.ac, Makefile.am) with a parallel CMake path documented in README.cmake.md and CMakePresets.json. Cryptographic backends are pluggable enough to have their own top-level notes: README.mbedtls, README.wolfssl, README.ec, and README.awslc for AWS-LC.

Configuration is file-driven. The daemon reads a config file, and the sample/sample-config-files directory holds configs and scripts taken from the project's HOWTO. Identity and trust come from X.509 material, and the sample/sample-scripts/verify-cn script is documented as usable with OpenVPN's --tls-verify option to provide a customized authentication test on embedded X509 certificate fields. That combination, a text config plus a certificate chain, is why OpenVPN deployments tend to be reproducible and why they are also tedious to set up by hand.

One design note worth flagging: README.dco.md exists at the top level, which means data channel offload is a first-class topic in this tree rather than an afterthought. Offload moves packet handling into the kernel, and the trade-off is the usual one: throughput against portability, since it depends on kernel support that not every target has.

Building OpenVPN from source and running a first tunnel

The README gives the canonical build sequence for a release tarball. It assumes a working compiler toolchain and the usual autotools prerequisites; the INSTALL file is where the README sends you for anything beyond the happy path.

tar -zxf openvpn-<version>.tar.gz
cd openvpn-<version>
./configure
make
make install

After make install you get the openvpn binary on the system. On Windows the README directs you to README.cmake.md for MinGW or MSVC builds, which is a different path from the tarball flow above.

For a first real run, the repository supplies sample material rather than a turnkey server. The sample/sample-keys directory contains RSA keys and certificates, and the README is blunt about them: don't use these files for anything other than testing because they are totally insecure. The sample/sample-config-files directory holds configs and scripts from the project's HOWTO, and the man page at openvpn.net/man.html is where the README sends you for detailed information including examples. For production certificates the README points at the separate easy-rsa subproject, which is where you generate your own CA and client credentials.

Where OpenVPN/openvpn is the wrong tool

The most common mismatch is expecting this repository to be an end-user product. There is no installer here for macOS or iOS, no GUI, and no account system. The README's release pointer goes to a downloads page, and the Windows MSI packages it mentions are community-built from openvpn-build. If your requirement is "install and click connect", you are looking at the wrong layer, and no amount of reading this source tree will fix that.

A second failure mode is certificate handling. The sample keys are explicitly insecure, and the README says so in capitals. Teams that copy sample/sample-keys into a staging environment and forget about it end up with a tunnel whose trust anchors are public. The daemon will happily run with them.

Third, the pluggable crypto backends cut both ways. Having README.mbedtls, README.wolfssl, README.ec and README.awslc in the tree means you can match a backend to a constraint, but it also means the combination of backend, kernel and platform is a matrix you own. Nothing in the README claims every combination is equally exercised. If you need a single supported configuration with a vendor behind it, a managed VPN service is the honest answer, and the search results around OpenVPN versus commercial providers reflect exactly that confusion.

How it differs from WireGuard and from managed VPN services

WireGuard is the alternative most engineers weigh against OpenVPN, and the difference is architectural rather than cosmetic. WireGuard is designed around a small, fixed cryptographic surface with peers identified by public keys, and it is implemented in the kernel on Linux. OpenVPN carries X.509 certificate infrastructure, a config-file language with a long option list, and a userspace daemon that can be built against several TLS libraries. That makes OpenVPN heavier to operate and slower to configure, but it also means it fits environments that already have a PKI, need certificate-based revocation, or must run on a platform where the WireGuard kernel module is unavailable.

The other alternative is not a protocol but a service: a commercial VPN provider. The search data shows people asking whether NordVPN or OpenVPN is better, which conflates a subscription product with a daemon. The distinction matters because with this repository you are the operator. You own the server, the certificates, the routing and the upgrades. That is the point, and it is also the cost.

Maintenance, release lines and licence

The repository is not archived, and the last push was on 2026-09-21. Recent releases include v2.7.7 on 2026-09-03, v2.6.22 on 2026-08-06 and v2.7.6 on 2026-08-06. Two maintained lines, 2.6.x and 2.7.x, are receiving releases in the same window, so an upgrade plan has to decide which line you track rather than assuming there is only one. The ChangeLog, Changes.md and NEWS files at the top level are where the project records what moved between versions; the README itself does not document rollback, so plan your downgrade path from those files and from your own package snapshots.

Licensing is stated in the README header: GNU General Public License version 2, with COPYING and COPYRIGHT.GPL in the tree. The repository metadata reports the licence as NOASSERTION, which is a metadata artifact rather than a statement about the project. For anyone embedding the daemon in a product, the GPLv2 obligations are the thing to read before shipping, and that is a question for your own counsel, not for this article.

Upgrade cost is mostly operational. Because configuration is file-based and certificates are external, a version bump is usually a package change plus a daemon restart. The exceptions are the feature areas with their own README files, particularly DCO, where a new kernel-side path can change your deployment assumptions.

Editorial conclusion

Adopt OpenVPN/openvpn if you run your own server, are comfortable with PKI and want a daemon you compile and configure yourself; the repository ships sample-config-files, sample-keys and a man page, which is enough to stand up a tunnel. Do not adopt it if you want a signed installer, a GUI or a managed subscription: the README points Windows users at community-built MSI packages from openvpn-build and the GUI lives in a separate product. Before deploying, verify which release line you are on, since v2.6.x and v2.7.x are both receiving releases, and read the README.dco.md notes if you plan to use kernel data channel offload, because that changes which kernel and driver combination you need.

Frequently asked questions

Official sources

1. Issues
2. OpenVPN/openvpn on GitHub
3. Project website
4. README
5. Releases