Data-channel Encryption Cipher Negotiation on Access Server | OpenVPN
Understand the data-channel encryption cipher negotiation that encrypts communication between Access Server and VPN clients.
Introduction
The data-channel encryption cipher encrypts and decrypts the data packets transmitted through the OpenVPN tunnel. This documentation provides an overview of data-channel ciphers for OpenVPN Access Server and the differences between versions.
Access Server 2.9 and newer provides data-channel cipher configuration in the Admin Web UI and the command-line interface. For details, refer to this tutorial: Change the Data-channel Encryption Cipher.
Default data-channel ciphers
Access Server and OpenVPN clients have default data-channel ciphers, but determining these depends on various factors. Use the following information to find the scenario that most closely matches your server-client setup. And, if you prefer, you can change the default values using the Admin Web UI or command-line interface, as detailed in this tutorial: Change the Data-channel Encryption Cipher.
Over time the cipher used for the data-channel has changed. Far in the past with the initial release of Access Server 1.0 the default was BF-CBC, but this has long since been deprecated. Since Access Server 2.5 and OpenVPN client 2.4 the default is now AES-256-GCM. So if your Access Server is 2.5 or newer, and your OpenVPN client is 2.4 or newer, you will almost certainly be using AES-256-GCM for the encryption cipher now. You can verify this in the logs using the instructions in this document.
If your server or client is older, it cannot use AES-256-GCM but AES-256-CBC would then be an acceptable alternative. CBC is slightly slower than GCM but equivalent in encryption strength. If your setup is still using BF-CBC you should see the section in this document about migrating away from BF-CBC.
AES-256-GCM default for Access Server 2.5 and newer
AES-256-GCM is the default since Access Server 2.5, with AES-256-GCM preferred for newer OpenVPN clients (2.4 and above). For backward compatibility older clients are using AES-256-CBC. They have the same level of security, but more recent OpenVPN versions use the faster GCM method to combine the encryption and authentication steps into one. In CBC mode the packet authentication is done using SHA1 HMAC. In the specific use-case of using it for HMAC, SHA1 is still considered secure. So in either case, with older and newer clients, you are secure.
Configurable data-channel cipher for Access Server 2.9 and newer
On Access Server 2.9.0 and newer, you can configure the data-cipher string in the Admin Web UI and the command-line interface. This allows setting a number of ciphers in order of priority. The first cipher the client can do will be the one used for the VPN connection, so the server is in control of deciding which cipher is preferred.
For details on configuring this, refer to Change the Data-channel Encryption Cipher.
BF-CBC default for old Access Server versions
If you use a version of Access Server before 2.5, the cipher is BF-CBC by default. And if you don't upgrade your Access Server, it will continue to use BF-CBC only. This is considered insecure today.
If you upgrade such an old installation of Access Server to version 2.5 or newer, AES-256-GCM will be preferred for newer OpenVPN clients (2.4 and above) while older clients use BF-CBC to retain backward compatibility. In this situation you should verify if you still have older VPN clients that use BF-CBC, and if so, look at our BF-CBC cipher deprecation recommendations.
Verify what data-channel cipher is actually used in the log file
To see exactly what cipher is used with a VPN connection, you can check your log entries.
Log entry in openvpnas.log showing AES-256-GCM data-channel encryption:
2022-01-01 12:00:00 User/192.0.2.22:12345 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key 2022-01-01 12:00:00 User/192.0.2.22:12345 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
BF-CBC cipher deprecation recommendations
The Blowfish cipher, or BF-CBC as used in OpenVPN, is not considered secure anymore. Should you find yourself in the situation that you have an OpenVPN setup that still uses BF-CBC, you should consider moving away from that. There are 3 main reasons to move away from using the BF-CBC cipher:
BF-CBC is vulnerable to the SWEET32 vulnerability. There is a mitigation in place in OpenVPN that rotates the encryption key used automatically based on how much data was encrypted with the same key. This is to prevent being able to gather enough data encrypted with the same key to perform a so-called birthday attack. You should however still move away from BF-CBC cipher.
Support for the BF-CBC cipher is being phased out. It is already noticeable on modern Linux operating systems where the default OpenSSL configuration does not allow the use of the Blowfish cipher. While it may be possible to reenable support, this is not recommended.
The Data Channel Offload (DCO) kernel module for faster handling of encryption and decryption of OpenVPN data channel traffic only supports AEAD type ciphers such as AES-256-GCM and CHACHA20-POLY1305. If you use a CBC cipher like BF-CBC then DCO will automatically be disabled, so you cannot benefit from the speed enhancement that DCO offers.
If you still find evidence of BF-CBC being used for VPN connections in your Access Server logs, then most likely you are using an older client (OpenVPN 2.3) that can not automatically negotiate for a better cipher like AES-256-GCM, or you are using an Access Server older than 2.5 that is configured to use BF-CBC, or both.
If your Access Server is from before version 2.5, you should upgrade to the latest version and verify that clients now negotiate to AES-256-GCM. In this situation it is recommended that you stand up a new Access Server next to the old one and run tests first, as it would be a very significant upgrade step which may require some testing and configuration adjustments. If after the upgrade the OpenVPN client(s) that previously connected using BF-CBC cannot connect anymore, it is most likely because it is an older client (OpenVPN 2.3 or older) that cannot automatically negotiate to the AES-256-GCM cipher. In that case it is recommended to update the client so it can support modern ciphers. Alternatively, at the very least, consider switching older clients to AES-256-CBC.
Should you be in a situation that you must continue to support OpenVPN 2.3 and older clients, we recommend that you get in touch with our support personnel. It is then recommended that you at least work towards using the AES-256-CBC cipher. This is equivalent in encryption strength to AES-256-GCM which is the current standard cipher for Access Server, but is of the CBC type which is slightly slower but still supported by older clients. If you must support older OpenVPN clients, you can still at least move away from BF-CBC to AES-256-CBC. To continue to support older clients but using a secure AES-256-CBC cipher here is a checklist:
Ensure that TLS control channel security is set to TLS-auth (or none but that is not recommended).
Change the data-cipher to include AES-256-CBC at the end of the cipher string list.
Set vpn.server.cipher and vpn.client.cipher configuration keys both to the value AES-256-CBC.
Enable cipher fallback by setting vpn.server.enable_cipher_fallback configuration key to true.
Provision your older OpenVPN clients with a new connection profile, so they can connect using AES-256-CBC.
Warning
Using older OpenVPN clients even with AES-256-CBC is still not recommended as they may contain known vulnerabilities that were solved in later releases. We recommend that you use up-to-date software.
If you insist on continuing to use BF-CBC cipher we caution you of the security risk of using a deprecated cipher, and the problems going forward with maintaining an outdated cipher.
Compatibility notes for older clients
The cipher negotiation documentation in the OpenVPN repository describes in technical detail how cipher negotiation works and how different versions and configurations interact.
In general if your OpenVPN client is 2.3 or older, it cannot do cipher negotiation so it will not be able to automatically negotiate for a more modern cipher on Access Server 2.5 or newer, and therefore will continue to use whatever older cipher it was configured to use like BF-CBC or AES-256-CBC. It is recommended to keep both Access Server and the OpenVPN client up-to-date to ensure the best security.
OpenVPN 2.3 and older clients configured with the --enable-small flag, which is something you may encounter on embedded devices, are not indicating what ciphers they are capable of. On Access Server 2.9.0 and newer, you will then have to enable the data-ciphers-fallback option to support these type of older clients that don’t announce ciphers. This option can be found on the Configuration > Advanced VPN page in the Admin Web UI. This will then be set to the cipher defined in the vpn.server.cipher configuration key, and if that key is not set, it defaults to BF-CBC.