Learn OpenVPN - Control Channel & Data Channel

#Introduction

In episode 2, you were introduced to the concepts of control channel and data channel. Episode 6 explained where packets get sent. Now it's time to understand how those two communication paths work down to the protocol level.

The division of labor is clear: the control channel handles all negotiation — who you are, which cipher is used, and which session keys are agreed upon. Meanwhile the data channel carries the traffic load — HTTP, SSH, database — already encrypted and wrapped. Both run over the same single UDP or TCP connection, separated by marker bits in the header.

Episode 7 covers the parameters that control both paths. You will understand the tls-version-min, tls-cipher, and remote-cert-tls directives for the control channel, then cipher, auth, and ncp-ciphers for the data channel. This is the foundation that will be matured in episode 13 on hardening.

#Control Channel

#The TLS Handshake Flow in OpenVPN

When a client first connects, what happens is a TLS handshake inside the control channel. Client and server exchange certificates, verify the CA signatures, agree on the TLS version, and produce session keys. All of this happens before a single byte of VPN data is sent.

OpenVPN wraps this handshake in its own datagram packets. Because UDP doesn't guarantee ordering, OpenVPN handles retransmission of handshake packets at its upper layer. This is why a high verb level in the logs shows the complete handshake sequence even though the path is UDP.

#Renegotiation and Key Rotation

The handshake doesn't stop at the first connection. By default OpenVPN performs renegotiation periodically to rotate the data keys. This preserves forward secrecy: if a session key leaks, the impact is limited to a short time window, not the entire session.

The renegotiation frequency is set with reneg-sec. Its default value is 3600 seconds. For environments demanding stricter security, the value can be lowered:

reneg-sec 1800

reneg-sec 1800 forces the session keys to rotate every 30 minutes. The trade-off: renegotiation consumes a little CPU and can be noticeable during heavy traffic, so don't lower it without reason.

#tls-version-min and tls-cipher

To enforce a minimum TLS version and an allowed cipher list, use tls-version-min and tls-cipher:

tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384

tls-version-min 1.2 rejects handshakes below TLS 1.2, while also contributing to compliance with RFC 7525 guidelines. tls-cipher restricts the TLS cipher suites that may be negotiated. A single line like this can reject old clients that use weak ciphers.

#remote-cert-tls server

The remote-cert-tls server directive on the client side ensures that the certificate received is truly a server certificate, not just any certificate that happens to be signed by the same CA. This prevents attacks where an attacker with a client certificate tries to impersonate the server.

remote-cert-tls server

#Data Channel

#cipher and auth

After the handshake completes, actual traffic is encrypted in the data channel. Encryption uses the algorithm agreed via the cipher directive, and integrity is maintained by the HMAC from the auth directive:

cipher AES-256-GCM
auth SHA256
ncp-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305

cipher AES-256-GCM uses authenticated encryption in GCM mode, which guarantees both confidentiality and integrity. auth SHA256 is kept for compatibility, although GCM ciphers already carry their own authentication.

#ncp-ciphers: Cipher Negotiation

Since OpenVPN 2.4, the list of negotiable ciphers is managed through NCP (Negotiable Crypto Parameters). The ncp-ciphers directive on the server defines the preference list offered to clients:

ncp-ciphers AES-256-GCM:CHACHA20-POLY1305:AES-128-GCM

The server will choose the first cipher that the client also supports. The order in the list is the priority order, so put the strongest cipher first. If a client doesn't support NCP, it falls back to the declared cipher.

#Understanding Cipher Choices

• AES-256-GCM: industry standard, hardware-accelerated on almost all modern CPUs, and widely supported on every platform.
• ChaCha20-Poly1305: the choice when the CPU lacks AES acceleration, e.g. ARM devices without AES instructions. Its performance is consistent without hardware support.
• AES-128-GCM: higher speed with security still adequate for general needs.

GCM and ChaCha20 are both authenticated encryption, so both are immune to the padding oracle attacks that affected older CBC-mode ciphers. For modern security practice, avoid CBC-mode ciphers in new deployments.

#Seeing the Two Channels in Action

#Logging with verb 4

The easiest way to see both channels working is through a log with verbosity level 4:

openvpn --config client.ovpn --verb 4

The log will show the TLS: Initial packet from ... phase for the control channel, then Peer Connection Initiated after the successful handshake, and finally Initialization Sequence Completed when the data channel is ready. Understanding this log sequence is very helpful when troubleshooting in episode 8.

#Verifying the Active Session Keys

To see session negotiation details, enable verb 5 and observe the Data Channel: cipher ... and Control Channel: TLSv1.3, cipher ... blocks in the log. This information shows the cipher actually selected after negotiation, not just what was configured.

#Conclusion

Key takeaways:

• The control channel handles the TLS handshake and renegotiation.
• tls-version-min and tls-cipher restrict TLS negotiation.
• remote-cert-tls server verifies the server certificate role on the client side.
• The data channel uses cipher and ncp-ciphers for traffic encryption.
• AES-256-GCM and ChaCha20-Poly1305 are the recommended modern choices.
• reneg-sec governs session key rotation and preserves forward secrecy.

In the next episode, episode 8, we will discuss logging, monitoring, and troubleshooting — how to read status and log files, enabling the management interface for runtime inspection, analyzing TLS handshake failures, and using tcpdump and --verb 6 to trace problems down to the packet level. After this episode, you'll have the tools to debug almost any VPN issue.