OpenVPN Caught Up on Speed. Is That Enough to Switch Back?

OpenVPN got faster. OpenVPN with Data Channel Offload (DCO) now matches WireGuard’s throughput on the same hardware: up to 680 Mbps on both protocols on a GL.iNet Flint 3 router. Those figures come from OpenVPN’s own benchmarks, not independent tests, but they line up with what VyOS and IPFire have reported. For years the short answer to “why not OpenVPN?” was “it’s slow.” That answer no longer holds.

If you run OpenVPN today, this is a free upgrade. You don’t migrate anything. Move the server to Linux 6.16 or later and OpenVPN 2.7, use an AEAD cipher, and the data channel moves into the kernel. Your certificates, user auth and client configs stay the same. We have a stake in this too: every Cycle environment ships with a built-in OpenVPN-based VPN, so the speedup matters to us as well.

WireGuard users mostly shrugged. We wanted to know whether faster OpenVPN would change anyone’s mind, so we posted the news on LinkedIn, which drew 88 comments. We read every one and grouped them by the main reason given. Most people agreed the speed gap had closed, but almost nobody thought speed was why they’d picked WireGuard. They chose it for simple configuration and a codebase small enough to audit, and none of that changed.

The real lesson is re-evaluation. Infrastructure decisions get made for a reason, and the reason often expires long before anyone revisits the decision. We see this all the time with Kubernetes: teams adopt it because they think they have to and then fail to re-evaluate that layer in their stack. That’s a big part of why we built Cycle, giving teams an option that's simpler with a better developer experience. A faster OpenVPN might not be enough reason to switch from WireGuard but it is a good practice to look at why you chose what you’re running and whether that reason still holds.

What happened

On October 2, 2026, OpenVPN announced that VyOS now ships OpenVPN 2.7 built against the Linux kernel's ovpn module, with DCO enabled per tunnel. The kernel work behind it is older. Linux networking maintainers accepted the ovpn module in April 2025, and it shipped in Linux 6.16 in July 2025. What's new is that it's now reaching distributions and appliances by default.

DCO has existed since 2023. The kernel module landed in mid-2025, but the matching OpenVPN release, working distro packages and appliance support took another 14 months.

How it works

Classic OpenVPN runs everything in userspace, so every packet is copied between the kernel and the OpenVPN process. DCO splits the work:

• Kernel (ovpn module): the data channel. Encryption, decryption and encapsulation of every packet, spread across CPU cores.
• Userspace (OpenVPN 2.7): the control channel. The TLS handshake, authentication, key negotiation and pushing configuration to clients stay where they were.

Removing the per-packet copies and context switches is where the speed comes from. OpenVPN's DCO guide reports an internal iperf3 test going from about 3.61 Gbps to 7.15 Gbps on the same hardware. IPFire reported 1 Gbit/s to 10 Gbit/s per tunnel. These are vendor and partner numbers, not independent tests.

What DCO doesn't do (from the project's README.dco.md):

• AEAD ciphers only: AES-GCM and ChaCha20-Poly1305.
• Layer 3 only (dev tun). TAP and layer 2 bridging are not offloaded.
• No compression, no --shaper, subnet topology only for servers.
• The mainline module needs OpenVPN 2.7 or later. Older kernels can use the ovpn-backports project.
• If a config uses an unsupported option, OpenVPN turns DCO off and logs a warning instead of failing.

Why it matters for teams already on OpenVPN

For teams running OpenVPN, this is a free performance upgrade with no migration. The tunnels, certificates, user auth and client configs stay the same. The server gets a kernel at 6.16 or later, OpenVPN 2.7, and an AEAD cipher, and the data channel moves into the kernel.

• The speed tax is gone. Teams that stayed on OpenVPN for its features no longer pay for them in throughput. Those features include username and password auth, RADIUS or LDAP plugins, pushed routes and TCP fallback.
• Less CPU per gigabit on concentrators. The encryption work runs in the kernel and across cores instead of one userspace process. That matters most on a central server terminating many clients.
• Clients benefit without changing. OpenVPN notes that clients on any platform see the gain when the server runs DCO. Windows clients also have a DCO driver (ovpn-dco-win) for client and peer-to-peer mode.
• Appliances are shipping it. VyOS, IPFire and GL.iNet routers already support it, so many teams get it through a normal firmware or OS update.

The one group left out is layer 2. Teams bridging Ethernet over TAP don't get DCO, because only TUN is offloaded.

What the discussion said

The engineers who responded mostly agreed the speed gap had closed. They disagreed that speed was ever the reason to pick WireGuard. Across 88 comments on a LinkedIn thread about the news, the reasons people gave fell into a few groups.

We definitely saw some trends forming in the comments. Most people agreed the speed gap had closed, but almost nobody thought speed was ever the real reason to pick WireGuard. The biggest group, around 18 comments, talked about simplicity. People called OpenVPN setup “convoluted” and “a total faff,” and one summed up WireGuard’s lesson as “the less buttons, the better.” About 10 pointed to auditability. The most-liked reply said WireGuard was chosen because its code “could be audited and trusted,” and that performance was a bonus.

A smaller group, around seven, made the point this post is built on: infrastructure choices tend to be defended by the cost of revisiting them, not by fresh data. A handful made the case for OpenVPN, citing built-in user management and MFA, pushed configs, layer 2 bridging, running over TCP/443, and compliance rules that require specific crypto or PKI. Others raised topology: OpenVPN is hub and spoke, while WireGuard fits a decentralized mesh. One suggested combining them, with OpenVPN for coordination and key distribution and WireGuard for transport. A few noted that WireGuard is easier to automate but leaves key distribution and fleet tooling to you. The rest asked questions nobody can answer yet: does connection setup get faster, what happens to CPU and memory, and do real-world speeds match the benchmarks?

The auditability points have a long history. When WireGuard was heading for the kernel in 2018, Linus Torvalds wrote that "compared to the horrors that are OpenVPN and IPSec, it's a work of art." The WireGuard paper puts its Linux implementation at under 4,000 lines of code.

How the pieces fit. Almost every point lands in one of two layers. DCO only changed the data plane, which is where speed lives. Every remaining difference people raised sits in the control plane or in how much code you have to trust.

The green row is what DCO changed. The amber rows hold every remaining difference respondents raised: identity, config, transport and the code each team has to trust.

Side by side

On throughput the two are now even. Most of the other rows still differ. The rows follow what respondents raised most.

Throughput figures are OpenVPN's published router tests (source), not independent benchmarks. Neither project publishes a head-to-head CPU or memory comparison with DCO enabled, which leaves one of the open questions from the discussion unanswered. Other sources: README.dco.md, WireGuard formal verification, WireGuard and OpenVPN on Wikipedia.

Is it enough to migrate?

For most teams, no. DCO is a reason to upgrade OpenVPN, not to switch to it. It removed the one disadvantage that was easy to measure. The reasons people gave for choosing WireGuard (simplicity, a small audit surface, easy config) didn't change, and neither did the reasons some teams need OpenVPN.

The broader lesson from the discussion: infrastructure choices often outlive the reason they were made. When the original reason expires, it's worth asking whether the choice still holds. In this case it mostly does, because the reasons were never only about speed.