Learn OpenVPN - DCO (Data Channel Offload) & Performance

#Introduction

For years, OpenVPN processed every packet in userspace: packets arrive in the kernel, get copied to user space, get encrypted, then get copied back to the kernel for sending. This back-and-forth consumes CPU and limits throughput on servers serving many clients.

Episode 14 covers the solution: Data Channel Offload (DCO). The core idea is simple — move data channel processing into the kernel with the ovpn-dco module, so packets don't need to shuttle back and forth to userspace. You will learn the concept, the benefits of zero-copy and multiqueue, how to set it up on Linux, and compatibility with the DCO driver on Windows.

DCO is the future of OpenVPN. Version 2.7 marks the maturity of this feature, and understanding how it works will equip you for high-capacity deployments.

#The DCO Concept

#The Traditional Architecture Problem

In the classic architecture, one VPN packet passes through four space transitions: kernel to userspace, encryption in userspace, back to kernel, then out through the interface. Each transition adds overhead — syscalls, data copies, and context switches.

DCO eliminates these transitions for the data channel. Encryption and encapsulation happen in the kernel, in a module that handles traffic directly to and from the network interfaces.

#--data-channel-offload and ovpn-dco

Enabling DCO in OpenVPN 2.7 involves the --data-channel-offload flag and the ovpn-dco kernel module. When both are active, the control channel stays in userspace, but the data channel is processed in the kernel:

data-channel-offload
dev tun
proto udp
port 1194

data-channel-offload tells OpenVPN to use the DCO path. If the kernel module isn't available, the daemon falls back to the old userspace mode — so it's important to always check whether DCO is actually active.

#dco and dcoV2 Modes

OpenVPN 2.7 introduces two DCO modes. The dco mode uses a generic architecture with broad compatibility. The dcov2 mode is a development that offers newer features and deeper kernel integration. For distributions that support it, enable DCO and watch the module version in the log at startup.

#DCO Benefits

#Zero-Copy and Multiqueue

DCO's two main benefits are rooted in how the kernel handles packets. Zero-copy means packets aren't copied repeatedly between memory spaces — data moves by reference, not by copy. Multiqueue allows packets to be processed in parallel across many CPU cores, breaking the single-core bottleneck.

Both dramatically raise throughput. A server that previously topped out at a few hundred Mbps in userspace can exceed 1Gbps throughput when DCO is active, depending on hardware and configuration.

#Hardware Offloading

On supporting network cards, the kernel can offload part of the processing to hardware — checksum offload and segmentation offload work alongside DCO. This combination reduces CPU load even further.

#Real Benchmarks

The figures OpenVPN cites: on the right hardware, DCO can push into the 10Gbps throughput class with a few cores, compared to a userspace architecture that needs many cores for far lower numbers. This is why DCO is a major focus of OpenVPN 2.7.

#Setting Up DCO on Linux

#Loading the Kernel Module

The first step is ensuring the ovpn-dco module is available and loaded:

modprobe ovpn-dco
lsmod | grep ovpn_dco

lsmod | grep ovpn_dco verifies the module is loaded. If the module isn't found, install the appropriate kernel package or use a distribution that already includes ovpn-dco. Some distributions package it separately under a name like ovpn-dco-dkms.

#Running the Server with DCO

Start the server and make sure the log confirms the DCO path:

systemctl start openvpn-server@server
journalctl -u openvpn-server@server -n 50

In the log, look for a line mentioning DCO or data channel offload during initialization. If it's absent, the daemon may be running in userspace mode — check the module and the data-channel-offload directive.

#Verifying the Packet Path

To make sure data really flows through the DCO path, check the counters on the kernel side:

cat /proc/net/dev
ethtool -S tun0 | grep -i dco

The output of ethtool -S tun0 shows counters indicating DCO traffic is being processed. Numbers that keep increasing mean the kernel path is working.

#DCO on Other Platforms

#Windows with dco-win

OpenVPN 2.7 brings DCO to Windows via the dco-win driver. Modern Windows clients running OpenVPN GUI 2.7 and above will use DCO automatically when the server supports it:

data-channel-offload

With this flag in client.ovpn, a Windows client uses the DCO driver if available. The resulting experience: higher throughput and lower CPU usage on the client side.

#DCO on macOS and BSD

DCO support on macOS and BSD systems is still limited compared to Linux and Windows. On those platforms, OpenVPN continues using the stable userspace path. This isn't a problem — DCO is a performance optimization, not a functional prerequisite.

#Conclusion

Key takeaways:

• DCO moves data channel processing from userspace into the kernel.
• Zero-copy and multiqueue eliminate space-transition overhead.
• --data-channel-offload enables DCO in OpenVPN 2.7.
• The ovpn-dco module must be loaded on Linux.
• Windows uses the dco-win driver with the same flag.
• 10Gbps-class throughput is achievable with supporting hardware.

In the next episode, episode 15, we will discuss site-to-site and point-to-point VPN — connecting two offices with static routing and server-bridge, and a simple 2-node topology with --dev tun, --ifconfig, and --route. After this episode, you can connect office networks without requiring a central server.