Back to Blog

pfSense

Building a Site-to-Site VPN with OpenVPN DCO

Written by: Jim Pingle

Date: November 21, 2024

Building a Site-to-Site VPN with OpenVPN DCO

pfSense® Plus software includes several methods to achieve high-speed VPN throughput accelerated by hardware, with IPsec and WireGuard typically leading the conversation. In pfSense Plus software version 22.05, Netgate® added support for OpenVPN Data Channel Offload which greatly increases the speed of OpenVPN® to approach the speeds of IPsec and WireGuard®. DCO accomplishes these gains by moving most data handling operations into the kernel, which increases efficiency by reducing context changes and also allows OpenVPN to take advantage of hardware encryption offloading support in the kernel.

OpenVPN DCO is exclusive to pfSense Plus software. See our previous posts about OpenVPN DCO for additional background information:

We have just added a new recipe, OpenVPN Site-to-Site Configuration Example with SSL/TLS and DCO. This new recipe guides administrators through the configuration process for a site-to-site OpenVPN DCO link between two peers. DCO impacts how OpenVPN itself behaves, which can make configuring some roles such as a site-to-site VPN using DCO a challenge. Netgate provides a variety of pfSense® software Configuration Recipes including recipes for site-to-site VPNs using IPsec, WireGuard, and OpenVPN. 

Due to differences in how OpenVPN DCO works in the kernel compared to traditional OpenVPN in user space, there are OpenVPN options which are either not supported with DCO, or behave in different ways with DCO enabled. This complicates building a new VPN with OpenVPN DCO or when attempting to enable DCO on an existing OpenVPN configuration. For a list of differences and limitations, see the OpenVPN DCO documentation for pfSense software.

The most significant difference in OpenVPN server behavior is how DCO impacts routing for site-to-site VPNs. In this type of configuration OpenVPN servers using SSL/TLS typically rely on internal routing in OpenVPN to determine how to map networks to specific clients. However, DCO is not compatible with internal routing in OpenVPN as it wants to handle these routing decisions in the kernel -- not in OpenVPN. As a consequence, OpenVPN DCO can only handle a single client for each server, similar to an IPsec tunnel. This can be an advantage, too. Since routing is handled in the kernel, it also means the OpenVPN tunnel interface can operate like a typical interface in other ways. This includes allowing OpenVPN DCO to easily work with dynamic routing protocols such as BGP or OSPF using the FRR add-on package for pfSense software. Basic static routing in OpenVPN can also be easier as it does not require a client-specific override. Since there can be only one client, there is no internal routing decision for an OpenVPN server to make, so administrators only have to set the local and remote networks the server configuration.

Since OpenVPN DCO can only have one site-to-site client per server, there is more overhead for multiple sites. Each remote site requires a separate OpenVPN server instance, which consumes more memory and requires more administrative work. The additional OpenVPN server instances can share a certificate structure, but they each require unique tunnel networks and port numbers. The tunnel networks must use a /29 size IPv4 subnet or larger (e.g. /28, /24) as OpenVPN handles /30 subnets in a different manner internally which is not compatible with DCO.

For many administrators who prefer to use OpenVPN, these differences are well worth the extra effort to achieve the performance gains without switching to a completely different VPN protocol.

 

All trademarks are the property of their respective owners.