OpenVPN: TLS-Based VPN Architecture

OpenVPN uses two separate channels: the control channel and the data channel. The control channel handles authentication, session establishment, and configuration exchange using TLS. The data channel carries actual VPN traffic encrypted with a symmetric cipher negotiated through the control channel. This separation allows OpenVPN to leverage the full TLS ecosystem for key management.

The OpenVPN control channel runs a full TLS session. Both sides authenticate using X.509 certificates signed by a shared CA. TLS provides the key exchange, certificate validation, and negotiation of data channel cipher parameters. Because TLS supports ECDHE, the control channel provides perfect forward secrecy: data channel keys cannot be recovered from a captured session even with the CA key.

Data channel encryption is negotiated through the TLS control channel. OpenVPN 2.4 and later default to AES-256-GCM, an AEAD cipher that provides both confidentiality and integrity in a single operation. Earlier versions used AES-256-CBC with HMAC-SHA256 separately. AEAD modes are preferred because they eliminate the need for separate MAC verification and resist padding oracle attacks.

The tls-crypt option wraps the entire TLS session, including the client hello, inside a symmetric HMAC authenticated envelope using a pre-shared key. This means unauthenticated clients cannot even begin a TLS handshake; their initial packets are silently dropped. This protects the OpenVPN server from TLS-based DDoS amplification attacks and hides the fact that a VPN server is running.

The older tls-auth option adds an HMAC tag to TLS control channel packets but does not encrypt them. This prevents packet injection but still reveals the TLS handshake to observers. tls-crypt encrypts and authenticates the control channel wrapper, providing both DoS protection and traffic analysis resistance. tls-crypt is the recommended modern option; tls-auth is deprecated in favor of tls-crypt-v2.

OpenVPN authenticates clients using X.509 certificates signed by the VPN's Certificate Authority. Each client receives a unique certificate and private key. The server verifies the certificate chain and optionally checks a Certificate Revocation List (CRL) to reject revoked certificates. Revoking a certificate immediately removes a client's access, unlike PSK-based systems where changing a key affects all clients.

OpenVPN can run over UDP (default, recommended) or TCP. UDP avoids the TCP-over-TCP problem where packet loss causes double retransmission at both the TCP layer and the VPN application layer, degrading performance significantly. However, some networks block UDP. Running OpenVPN on TCP port 443 can bypass firewalls that only permit HTTPS traffic, at the cost of performance under packet loss conditions.

OpenVPN operates in tun (routing) mode or tap (bridging) mode. tun mode creates a point-to-point IP network interface, routing IP packets between the client and the VPN network. tap mode creates an Ethernet bridge interface, passing Ethernet frames including broadcast and non-IP protocols. tun mode is more efficient and suitable for most VPN use cases; tap mode is needed for bridging network segments or non-IP protocols.

OpenVPN servers can push configuration directives to connecting clients automatically. Common push directives include push "route 10.0.0.0 255.0.0.0" (add a route on the client), push "dhcp-option DNS 10.0.0.1" (set DNS server), and push "redirect-gateway def1" (route all client traffic through the VPN). This centralizes client configuration management without modifying individual client config files.

OpenVPN achieves perfect forward secrecy through TLS ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) in the control channel. A new ephemeral key pair is used for each TLS session, so the session key cannot be derived from the server's long-term certificate private key. Capturing encrypted traffic today and later obtaining the server certificate still does not allow decryption of past sessions.

OpenVPN 2.5 deprecated the Blowfish cipher (BF-CBC), which was historically the default. BF-CBC uses a 64-bit block size vulnerable to SWEET32 birthday attacks in long sessions. Modern OpenVPN defaults to AES-256-GCM. OpenVPN 2.5 also deprecated non-AEAD ciphers in the data channel and tightened TLS minimum version requirements, dropping TLS 1.0 and 1.1 support.

What is the primary function of the OpenVPN control channel?

OpenVPN recap: control channel uses TLS for authentication and cipher negotiation, data channel uses negotiated AEAD cipher (default AES-256-GCM), tls-crypt wraps TLS to prevent unauthenticated handshakes, ECDHE provides forward secrecy, certificate-based client authentication with CRL revocation, UDP preferred over TCP for performance, and tun mode preferred for IP routing use cases.