OpenVPN

Description

James Yonan is the author of the first version of OpenVPN and was released in 2001 under the GNU General Public License version 2. OpenVPN Inc. now maintains the project and releases two separate products in addition to the community codebase: OpenVPN Connect, the official end user client, and Access Server, a self-hosted enterprise VPN platform. The name covers three related but separate things — the open source protocol, the client software, and the commercial company — which often leads to confusion in documentation and reviews.

Unlike IPsec, L2TP or PPTP, OpenVPN constructs its tunneling on top of SSL/TLS instead of working at the IP layer. This design choice implies that OpenVPN operates completely in userspace instead of within the operating system kernel, and that a single binary can perform both client and server functions based on how the administrator has configured it.

THE PROTOCOL

OpenVPN wraps traffic inside a custom security protocol which utilizes TLS for the control channel — which is responsible for authentication and key exchange — and a separate data channel which carries the actual user traffic. The two channels are over either UDP or TCP on one configurable port. UDP provides lower latency due to the lack of retransmission overhead of TCP, so it is the choice for most deployments. TCP is appropriate for situations where a firewall or restrictive network is blocking UDP but allowing outbound TCP on standard ports such as 443.

Perfect Forward Secrecy is supported by the protocol. Each session uses new encryption keys, so even if the server’s private key is compromised in the future, it cannot decrypt previously recorded traffic. The data channel supports AES-256-GCM, AES-128-GCM, and ChaCha20-Poly1305 as cipher options, with the choice depending on the configuration of the server and the capability of the client.

From version 2.3 onwards, OpenVPN supports IPv6 both within the tunnel and on the outer connection, so IPv6-only network deployments require no workarounds.

AUTHENTICATION METHODS

OpenVPN supports three types of authentication that administrators can use in combination or separately. Pre-shared keys provide the easiest configuration — both endpoints use the same secret file — however, this approach does not scale very well beyond two-party connections and does not provide any per-user identity. Certificate-based authentication employs a PKI, which has a certificate authority that issues individual certificates to each client, and to the server. Each side authenticates the other’s certificate before the tunnel is complete, which prevents any unauthorized party from posing as either endpoint. Username and password authentication, which is available starting in version 2.0, adds a layer of credentials on top of the certificate exchange; OpenVPN leaves the actual credential check to third-party modules, which allows administrators to plug in PAM, LDAP, RADIUS, or SAML as the credential backend.

Access Server includes native support for TOTP-based multi-factor authentication, as well as support for Duo Security and LastPass via post-authentication plugins. It also supports MAC address locking which associates a particular client certificate with the hardware addresses of the device that registered the certificate, preventing that certificate from connecting from any other machine.

NAT AND FIREWALL TRAVERSAL

OpenVPN is able to negotiate through NAT and most firewalls without forcing the administrator to open dedicated ports or configure port forwarding at each client site. Because the protocol provides multiplexing of the entire VPN connection on a single TCP or UDP port, a single firewall rule is required at server side to cover all client traffic. The server configuration is capable of pushing routing table entries, DNS server addresses, and other network settings to connecting clients automatically at the time of tunnel establishment, eliminating the need for manual client-side configuration beyond the initial profile.

NETWORK MODES

OpenVPN has two network modes. TUN mode is used to create a routed layer 3 IP tunnel and is appropriate for most remote access and site-to-site use cases. TAP mode establishes a bridged layer-2 Ethernet tunnel that carries broadcast traffic in addition to regular IP packets, which are necessary to some applications, but which incurs overhead relative to TUN. Both modes allow for full-tunnel routing, in which all client internet traffic is routed through the VPN, and split-tunnel routing, in which only traffic destined for specific subnets uses the tunnel, while everything else is routed directly to the internet.

SECURITY HARDENING OPTIONS

The daemon may drop root privileges after it initializes, so that the damage that an attacker could do by exploiting a bug in the running process is limited. mlockall prevents the operating system from swapping memory pages containing cryptographic material to disk. A chroot jail restricts the process to a limited directory after it is started, isolating it from the rest of the file system. On systems that support the mandatory access control policy, context assignment applies this policy to the process. TLS authentication includes a pre-shared key (HMAC) in each TLS handshake packet, meaning that the server will drop any packet without the proper signature in a silent manner before the TLS negotiation even starts; this provides protection from denial-of-service attacks against the TLS stack.

OPENVPN CONNECT (CLIENT, end-user)

OpenVPN Connect is available for Windows 10 and 11, macOS, iOS, and Android. The user imports a connection profile — an .ovpn file which bundles the server address, certificates and configuration options into a single file — or enters the address of an Access Server instance directly. The client then takes care of the authentication and tunnel setup and reconnection automatically. It has multiple saved profiles, which means that users connecting to different servers can switch from a profile list without re-importing files.

ACCESS SERVER (Enterprise Edition)

Access Server runs on Linux and can be installed on bare metal, virtual machines or cloud instances on AWS, Azure, and Google Cloud. It adds a web-based administration panel on top of the community daemon, exposing user management, group policies, certificate provisioning and connection monitoring via a browser interface instead of text-file configuration. The free tier includes 2 simultaneous VPN connections; paid licensing adds connections in blocks. Access Server automates the process of issuing and renewing certificates for all clients enrolled, and creates downloadable installers of OpenVPN Connect, pre-populated with the correct profile for each user, eliminating the need to manually distribute profiles as part of the deployment process.

ROUTER and EMBEDded INTEGRation

Several open source router firmware projects, such as DD-WRT, OpenWrt and pfSense, have OpenVPN built in. A router that is running OpenVPN in client mode extends the VPN tunnel to all devices on its local network and does not need any VPN software on individual devices. SoftEther VPN and VyOS both use the OpenVPN protocol support, allowing their users to connect from standard OpenVPN clients without having to deploy a separate server.

COMMUNITY EDITION VS. THIRD-PARTY CLIENTS

The Community Edition client is available for all major platforms, and it accepts the same .ovpn profile format as all other OpenVPN compatible clients. Third-party clients like Tunnelblick on macOS and a number of clients on Linux wrap the same underlying OpenVPN binary with a different graphical interface. Commercial clients from VPN providers which use OpenVPN as their protocol — NordVPN, ExpressVPN, CyberGhost, and many others — embed or bundle the OpenVPN daemon internally and expose their own interface, such that the end user interacts with the provider’s app, rather than OpenVPN directly.