OpenVPN Data Channel Offload (DCO)¶
OpenVPN Data Channel Offload (DCO) allows for huge performance gains when processing encrypted OpenVPN data by reducing the amount of context switching that happens for each packet. DCO accomplishes this by keeping most of the data handling tasks in the kernel rather than repeatedly switching between kernel and user space for encryption and packet handling. This makes the overall processing of each packet more efficient while also potentially taking advantage of hardware encryption offloading support in the kernel. DCO also adds support for multi-threaded encryption, allowing for even more performance gains.
Netgate worked with OpenVPN to develop and integrate support for OpenVPN Data Channel Offload (DCO) into FreeBSD and pfSense® Plus software version 22.05 and later.
pfSense® Plus software version 22.05 or later is required to use OpenVPN DCO. OpenVPN DCO is not available on pfSense CE Software.
DCO is not a change to the protocol, it is a change in how an endpoint processes encrypted data. Thus, DCO is beneficial even when only one endpoint is capable of DCO. That said, tunnels employing DCO on all peers will see the most benefit. With DCO on only one peer the performance improvement can still be notable but not as significant as the gains with DCO support on both endpoints.
OpenVPN DCO is considered experimental at this time.
While testing has been successful in many scenarios during development, there is still a potential for instability or undesirable behavior. Additionally, some OpenVPN features and use cases are still not compatible with DCO. See Limitations for a list of known DCO limitations.
If a problem occurs with DCO, start a thread on the Netgate Forum to discuss and diagnose the issue.
Using OpenVPN DCO¶
DCO support is a per-tunnel option and it is not automatically enabled by default for new or upgraded tunnels. Existing tunnels will continue to function as they have in the past.
DCO can be enabled for both new and existing tunnels by using a simple checkbox option on OpenVPN server and client instances. The current best practice is to create a new tunnel with DCO to minimize the chance of problems with existing clients.
There are a few limitations in OpenVPN DCO generally and in the current DCO implementation on FreeBSD/pfSense software, including:
Encryption is limited to AES-256-GCM.
Future versions will support other AEAD ciphers such as ChaCha20-Poly1305.
DCO support requires a TLS-based tunnel, such as SSL/TLS, SSL/TLS+User Auth, or User Auth.
DCO support is only present in OpenVPN 2.6.0 which is still in development.
OpenVPN 2.6.0 has been stable enough in testing for general use, however.
DCO is not yet able to utilize internal routing in OpenVPN (
iroute). This means that although remote access use cases work, and site-to-site setups with one client per server work, it does not yet function with multiple site-to-site clients on a single server which require LAN-to-LAN routing.
/30or smaller tunnel network for peer-to-peer tunnels (one server with one client) is not compatible with DCO. There are problems with the code for this mode in OpenVPN which can lead to failed connections and instability.
Some features are not compatible with DCO or are not relevant with DCO. These options include:
Explicit exit notify
UDP fast I/O
Send/receive buffer sizes
Per-peer data usage is not tracked properly.
Until this is resolved peer data usage on the OpenVPN status page will not reflect the actual amount of data transferred between peers.
DCO and Routing¶
DCO does not currently honor internal routes from client-specific overrides
iroute) for multiple site-to-site clients on a single server, but it
does honor kernel route destinations that would normally be ignored by non-DCO
Assign clients static addresses in overrides (after patching #13274) and then setup custom routes in OpenVPN custom options with complete destinations defined or even setup FRR and exchange routes via BGP.
DCO and Hardware Cryptographic Acceleration¶
For optimal performance with DCO, ensure a hardware cryptographic accelerator is present and enabled.
QAT currently offers the highest performance for AES-256-GCM. If the hardware supports QAT, enable QAT.
If the hardware does not support QAT but it does support AES-NI, ensure the AES-NI kernel module is loaded for optimal performance with AES-256-GCM. Though OpenSSL can utilize AES-NI without the module loaded, performance is poor in that state and can even be slower than with DCO disabled.
Though future versions of pfSense Plus software will support ChaCha20-Poly1305 with OpenVPN DCO, neither AES-NI nor QAT can currently accelerate ChaCha20-Poly1305. Some newer QAT hardware may be capable of accelerating ChaCha20-Poly1305, the current QAT drivers do not yet include support for that encryption algorithm.