OpenVPN's split layout: two release lines, five build commands, three repositories doing the work

Two release lines ship in parallel, so the version number alone is not enough

OpenVPN does not advance a single line. Recent tags include v2.7.8 dated 2026-10-07, v2.6.23 dated 2026-09-23, and v2.7.7 dated 2026-09-03, so two series receive builds within weeks of one another and the lower number is not the staler one. The default branch is master, and the most recent push landed on 2026-11-02, which means fixes are landing on more than one line at once. For you that makes version pinning a real decision rather than a formality: a 2.6.x install and a 2.7.x install can both be current, and nothing in the tag dates tells you which one carries a fix you need. The in-tree records of what changed are ChangeLog and Changes.md at the repository root, along with NEWS, so start there before comparing builds.

The documented build is four shell lines and a pointer to INSTALL

Building from a release tarball takes five commands, exactly as written in the project README:

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

Everything past that is delegated: the file INSTALL carries the usage information, and configure.ac is the script that regenerates the configure script and makefile when you change them. The repository root also carries CMakeLists.txt and CMakePresets.json, but the top-level file gives no CMake command sequence, so a CMake based build is something you assemble from those files yourself. Windows is routed to a second document, README.cmake.md, which covers MinGW and MSVC builds. Sibling files named README.mbedtls, README.wolfssl, README.ec, and README.awslc sit alongside it; mbedtls, wolfssl and awslc are crypto libraries, which suggests the crypto library is a build time choice rather than a fixed dependency.

sample/sample-keys ships RSA keys the project calls totally insecure

The repository contains sample RSA keys and certificates under sample/sample-keys, and the warning attached to them is blunt: do not use these files for anything other than testing because they are totally insecure. That is the project's own text, not a third party warning, and it is easy to miss because the files sit next to genuinely useful material such as sample/sample-config-files and sample/sample-plugins. The consequence for a reader who copies the tree as a starting point is concrete: a deployment built on those keys has a private key that is published in a public repository, so the tunnel can be intercepted by anyone who downloads the same file. Generate your own material instead, which in a fresh clone means going outside this tree, as described next.

Certificate generation left the tree entirely, and nothing here replaces it

easy-rsa is no longer part of this source distribution. It is maintained as its own subproject at github.com/OpenVPN/easy-rsa, and the top-level file says so in a single line next to the other departure. The consequence is that the README sends you to a separate project, easy-rsa, for certificate tooling rather than to anything in this tree. Anyone setting up a deployment has to install a second tool, learn its command line, and keep its output compatible with what the daemon expects. Readers who assume the daemon repository is self sufficient will find the PKI half of the work described only by an external URL, and the sample keys are the only substitute on offer, which is precisely what the warning tells you not to use.

The Windows tap driver and every client front end live somewhere else

tap-windows6 is also maintained outside this repository, at github.com/OpenVPN/tap-windows6, alongside the easy-rsa note in the same breath. That matters because a Windows deployment needs the tunnel device driver, and the driver version now has to be tracked separately from the daemon version you compile. The same split applies to everything people type into search engines as OpenVPN Connect, OpenVPN GUI, or an OpenVPN build for macOS or iOS: none of those front ends exist in this repository, which contains a daemon and its library code. If you need a point and click client, this source tree is the wrong starting point.

The installers most people run come from a different repository than the source

Community-provided Windows MSI installers and Debian packages are built from github.com/OpenVPN/openvpn-build, not from the tree you are reading. That is a build pipeline maintained beside the daemon rather than inside it, and the top-level file points you there for the packaging story. The consequence is an audit gap. When a packaged client reports a version, the commit that produced it lives in the build repository's history, and reconciling it against the daemon's ChangeLog is manual work. For distributions that ship a distro package, the same split applies. It also means security review of the source tree is not a review of the artifact: a packaging script can change what ends up on a user's disk without touching any file under src/.

Configuration syntax is documented on a website, not in the repository

The README routes configuration questions mostly to the project website. The man page at openvpn.net/man.html is named as the detailed reference, the sample configuration at openvpn.net/howto.html is where you find working examples, and the newest release tarball is fetched from openvpn.net/community-downloads/. The repository also holds doc/, a forked-test-driver, a tests/ directory, and a debug/ directory. For a description of the underlying protocol, the README points to the file ssl.h in the source distribution, so that reference is a header file rather than prose.

One sample hook exists for embedded certificate checks, and it needs perl

The authentication extension point that ships with the source is narrow and specific. sample/sample-scripts/verify-cn is a sample perl script intended for use with OpenVPN's --tls-verify option, and its job is to provide a customized authentication test over fields embedded in an X509 certificate. That means the daemon exposes a hook where a script of your own decides what to check, and the project supplies one example that requires a perl interpreter on the host to run. If your policy is expressed as a certificate attribute check, this file is the starting point you have to extend yourself.

Editorial conclusion

OpenVPN suits people who need a tunnel daemon they can read, patch, and build from an autotools source tree, and it does not suit anyone expecting a turnkey client, a GUI, or bundled certificate tooling. Before you start, decide which release line you are pinning, confirm that the keys you ship are yours rather than the test files under sample/sample-keys, and check which repository the binary on your machines was actually built from.

Frequently asked questions

Official sources

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