Hello everyone,

I’d like to optimize the network design and separate core and edge routing.

So far, I’ve been using three routers that handle both inter-VLAN routing and edge routing and are part of a VRRP cluster.

Now I’d like to deploy a core router running VyOS that acts as the default gateway for all networks and initially handles inter-VLAN routing. The three edge routers will be connected to this core router, with each one connected to a different Internet line or provider.

The core router should use policy-based routing to determine which networks, clients, or services are routed to the Internet via which edge router or WAN connection. Additionally, failover should still be available in the event of an Internet connection failure (as has been the case with VRRP).

My question is: what is the best way to set up this configuration? On the one hand, I could set up a transport network containing the three edge routers and use VRRP again. In that case, I would likely need a transit switch between the core router and the edge routers so that the VRRP cluster’s traffic does not have to pass through the core router’s CPU.

On the other hand, it would certainly also be possible to connect the edge routers directly to the core router’s interfaces and operate without VRRP. Which protocol could I then use to implement both policy-based routing and failover?

Which network design would you recommend for my situation? I’d appreciate any tips and assistance.

Thank you in advance for your tips, and best regards

Regina (she/her)

Key takeaways

• VyOS OpenVPN tunnels can now use OpenVPN Data Channel Offload (DCO). VyOS Rolling ships OpenVPN 2.7 built against the Linux kernel's ovpn module.
• You turn it on per tunnel with one command: set interfaces openvpn vtun0 offload dco.
• VyOS joins a growing list of DCO platforms, including pfSense Plus, DD-WRT, GL.iNet routers, and several consumer VPN providers.
• On GL.iNet's own spec sheets, OpenVPN with DCO keeps pace with WireGuard on the same hardware: 680 Mbps for both on the Flint 3, and 700 Mbps versus 600 Mbps on the Mudi 7.
• DCO works with TUN interfaces, subnet topology, and AEAD ciphers. TAP, static keys, compression, and CBC ciphers aren't compatible.

VyOS, the open source network operating system used for routers, firewalls, and VPN gateways, now supports VyOS OpenVPN tunnels with Data Channel Offload. The change arrived in the VyOS Project September 2026 Update, and it mean3s VyOS users can move OpenVPN's encrypted data path out of userspace and into the Linux kernel with a single configuration line.

It's good news for anyone who runs OpenVPN on VyOS, and it's part of a wider trend: DCO is now showing up across router operating systems, consumer hardware, and VPN services. Here's what changed, why it matters, and what to check before you turn it on.

How do you enable OpenVPN DCO on VyOS?

VyOS Rolling now builds OpenVPN 2.7 against the in-tree Linux ovpn kernel module. DCO is off by default, and you enable it per tunnel:

set interfaces openvpn vtun0 offload dco

According to Mandelbit, the team that maintains the upstream ovpn module and contributed the integration, the work landed in three merged pull requests (vyos-build #1281, vyos-1x #5435, and vyos-1x #5441), and existing OpenVPN configurations move to 2.7 and keep working as before. VyOS also checks compatibility when you commit a configuration, so an unsupported cipher or option is reported up front instead of failing once the tunnel is running. VyOS tracks the change in issues T8264 and T9330.

The VyOS team noted that roughly a third of September's work came from the community, and the OpenVPN 2.7 and DCO work was contributed by an upstream OpenVPN developer. That's how open source is supposed to work: the people who build a feature help bring it to the platforms that need it.

What is OpenVPN Data Channel Offload (DCO)?

OpenVPN Data Channel Offload (DCO) is a kernel module that encrypts, decrypts, and forwards OpenVPN tunnel traffic inside the operating system kernel, while the OpenVPN process in userspace keeps handling authentication and key negotiation.

An OpenVPN connection has two parts. The control channel handles the TLS handshake, authentication, and key exchange. The data channel carries your actual traffic, encrypting and decrypting every packet. Traditionally, OpenVPN processed both in userspace, so every packet had to cross from the kernel to the OpenVPN process and back, and encryption ran on a single thread. With DCO, packets no longer make that round trip, and encryption can use multiple CPU cores.

Linux netdev maintainers accepted the ovpn module into the mainline kernel in April 2025, and it shipped with Linux 6.16 in July 2025. OpenVPN 2.7.0, released in February 2026, is the first OpenVPN version built to work with that in-tree module. Because DCO is now part of the kernel itself, Linux-based platforms like VyOS can adopt it without maintaining a separate out-of-tree driver. FreeBSD has its own DCO module, which is how pfSense Plus supports it.

How much faster is OpenVPN with DCO?

The clearest comparison comes from GL.iNet, which ships both OpenVPN with DCO and WireGuard on the same hardware and publishes the throughput for each:

GL.iNet router	OpenVPN with DCO	WireGuard
Mudi 7 (GL-E5800)	Up to 700 Mbps	600 Mbps
Flint 3 (GL-BE9300)	Up to 680 Mbps	Up to 680 Mbps

Same vendor, same product line, same testing approach. With DCO, OpenVPN's speed is no longer a reason to choose one protocol over the other, and teams can decide on authentication, identity integration, and access policy instead.

Consumer VPN providers that run OpenVPN at scale report similar gains from their own testing:

• IPVanish added DCO to its Windows app. TechRadar reports download gains of 131% on TCP and 196% on UDP. TechRadar also notes that IPVanish's high-speed DCO mode can't be used together with its Scramble obfuscation feature.
• Norton VPN reports that connection speeds more than doubled and latency fell by 15% in internal testing.
• Windscribe published a speed test showing 801 Mbps down and 701 Mbps up with DCO on Windows.

Our own engineering benchmarks point the same way. In tests by ovpn developer Antonio Quartulli, OpenVPN without DCO reached about 3.61 Gbps, and the same setup with DCO reached about 7.15 Gbps. Our definitive guide to OpenVPN DCO covers those tests in detail.

Your results will depend on your hardware, cipher, and network. DCO helps most when the CPU, not the internet link, is the bottleneck. For a VyOS deployment, that means more throughput from the same hardware and more CPU headroom for routing, firewalling, and other services on the router.

Which VyOS OpenVPN settings work with DCO?

DCO is built for modern, secure configurations, so a few older options don't carry over. Most of them have been discouraged for years. Here's what VyOS and the upstream OpenVPN documentation list for Linux:

Setting	Works with DCO?	What to do
TUN (layer 3) interfaces	Yes	No change needed.
TAP (layer 2, bridged) interfaces	No	Keep bridged tunnels on the userspace data path.
UDP and TCP transport	Yes, on Linux	No change needed.
Subnet topology	Yes	No change needed.
net30 or p2p topology	No	Switch to subnet topology.
TLS-negotiated keys	Yes	No change needed.
Shared-secret (static key) tunnels	No	Move to certificate-based TLS.
AEAD ciphers (AES-GCM and ChaCha20-Poly1305)	Yes	VyOS documents AES-GCM support.
CBC ciphers	No	Switch to AES-GCM.
Compression	No	Remove it. Compression inside an encrypted tunnel is discouraged for security reasons.
OpenVPN fragmentation (--fragment)	No	Let the kernel handle outside fragmentation.
MSS clamping (--mssfix)	No	Clamp MSS with firewall rules (nftables) instead.
Peers on OpenVPN 2.4.0 or newer	Yes	Upgrade older peers.

 

On a standard OpenVPN install, an incompatible option makes OpenVPN quietly fall back to the slower userspace path. VyOS reports the conflict when you commit instead, so you know where you stand. DCO is available in VyOS Rolling, and the VyOS OpenVPN documentation notes that enabling it resets the interface, so plan the change for a maintenance window or create new tunnels with DCO enabled.

Which routers and VPN services support OpenVPN DCO?

VyOS is one of several platforms that now ship DCO:

• pfSense Plus. Netgate sponsored the FreeBSD DCO module, and pfSense Plus 22.05 and later support DCO. It isn't available in pfSense CE.
• DD-WRT. DD-WRT includes DCO in builds 53787 and later on kernel 4.4 and newer.
• GL.iNet. GL.iNet routers, including the Mudi 7 and Flint 3, use OpenVPN with DCO and publish the speeds above.
• IPFire. IPFire reported throughput rising from 1 Gbit/s to 10 Gbit/s per tunnel after adding DCO.
• Consumer VPN providers. IPVanish, Norton VPN, and Windscribe have all added DCO to their apps, as covered above.

How does OpenVPN help router makers add DCO?

The OpenVPN Connect Certified program is for router manufacturers and OEMs. Certified equipment is compatible with CloudConnexa and Access Server, uses DCO for high-performance connections, and runs the most recent version of OpenVPN software at the time of certification. We work with manufacturers to get DCO running well on their hardware as part of the process.

GL.iNet's Flint 3 (GL-BE9300) was certified in January 2026. If you build routers and want to add DCO or certify a device, apply through the program page and our team will reach out.

Where else can you use OpenVPN DCO?

If you want the same kernel-level performance without building it yourself, it's already part of our products:

• Access Server. DCO is supported in Access Server 2.12.0 and newer and is on by default in Access Server 3.x. Access Server 3.2.0 and newer use the updated ovpn module aligned with Linux 6.16 and later. Refer to the tutorial to install, verify, and troubleshoot DCO for setup steps, and to the DD-WRT tutorial to connect a DD-WRT router.
• CloudConnexa. You can enable DCO on Linux Connectors and Windows Connectors. Refer to the tutorials for connecting GL.iNet and DD-WRT routers.
• OpenVPN Connect. OpenVPN Connect for Windows supports DCO, but it's off by default. Turn on DCO in OpenVPN Connect so the client side of the tunnel gets the same benefit.

DCO needs to be active on both ends of a tunnel to deliver the full speedup. If one side isn't using DCO, that side stays on the userspace path. A DCO-enabled VyOS router connecting to a DCO-enabled Access Server, for example, keeps the fast path in the kernel from end to end.

The bigger picture

DCO started as an OpenVPN project to make the protocol faster without giving up the security of TLS. Getting the ovpn module into the mainline Linux kernel made it available to every Linux distribution and every Linux-based appliance. Now it's reaching the routers, gateways, and VPN apps that carry business traffic every day.

We're glad to see VyOS bring OpenVPN 2.7 and DCO to its users, and we're grateful to the community contributors who made it happen. If you're running OpenVPN on VyOS, it's worth testing DCO on your next tunnel.