OpenVPN has released OpenVPN 2.7.0, the latest feature update to its widely used virtual private network (VPN) software for building secure point-to-point and site-to-site connections. While OpenVPN remains a familiar workhorse in many organizations, version 2.7 is not a routine incremental refresh: it introduces changes that speak directly to modern operational pain points—performance, live configuration updates, DNS behavior across platforms, and a more opinionated Windows architecture.
At the headline level, OpenVPN 2.7 adds support for the new upstream OpenVPN DCO (Data Channel Offload) Linux kernel module, expands server flexibility with multi-socket support, and moves forward on cryptography and transport with mbedTLS 4 support and TLS 1.3 support when paired with bleeding-edge mbedTLS builds. But the release is equally notable for the “plumbing” improvements that administrators often care about most: fewer forced reconnects when policies change, better DNS integration out of the box, and a clearer driver direction on Windows.
Linux DCO: a performance track that’s moving upstream
OpenVPN DCO is one of the most strategically important items in 2.7. The idea behind DCO is to offload parts of the data channel to the kernel—reducing overhead and improving efficiency, especially where throughput and CPU cost matter. With OpenVPN 2.7, the user-space daemon supports the new ovpn DCO Linux kernel module, which has been merged upstream (meaning it is available directly in newer kernel versions). For organizations that cannot jump to the newest kernel immediately, the project also points to backports via ovpn-backports, a pragmatic path for testing and early adoption.
In practical terms, DCO is not a one-click upgrade for every environment; it’s a performance lane that depends on kernel availability, distribution packaging, and operational comfort with a newer data-path architecture. Still, OpenVPN 2.7 makes the DCO story feel less experimental and more like the direction of travel.
Multi-socket servers: fewer instances, cleaner deployments
OpenVPN 2.7 introduces multi-socket support for servers, enabling a single OpenVPN server instance to handle multiple addresses, ports, and protocols. This matters in real deployments where a service may need to listen on different interfaces (IPv4/IPv6, multi-homed hosts) or provide alternative entry points for compatibility, resilience, or network policy reasons.
Historically, this type of requirement often led to duplicated configs and extra service instances. Multi-socket reduces that operational sprawl and makes it easier to evolve an existing deployment without piling on parallel processes.
PUSH_UPDATE: policy changes without forcing reconnects
Configuration drift and mid-day changes are normal in enterprise networks: routes are adjusted, DNS rules evolve, split-tunnel policies change, and new internal domains appear. Until now, many of these changes often implied one blunt tool: force a reconnect.
OpenVPN 2.7 adds client-side support for the PUSH_UPDATE control-channel message, allowing servers to send updates to options such as routing and DNS configuration without triggering a reconnect. On the server side, the release also introduces “minimal” support to send these updates via new management interface commands (including targeted and broadcast-style updates). In operational terms, this is a quality-of-life leap: fewer interruptions for users and fewer “VPN dropped” tickets caused by routine network policy adjustments.
DNS improvements: more native behavior across platforms
DNS is a frequent source of VPN friction—especially in mixed fleets, remote work setups, and environments that require corporate name resolution alongside public DNS. OpenVPN 2.7 improves client handling of DNS options by including client implementations for Linux, BSD, and macOS as part of the default install, rather than relying on external glue.
For Windows, OpenVPN 2.7 introduces a new client implementation to support advanced features like split DNS and DNSSEC, making Windows behavior more aligned with modern enterprise expectations. Alongside that, OpenVPN adds two new environment variables designed to communicate default gateway redirection preferences to plugins such as NetworkManager, smoothing integration in managed desktop environments.
Windows changes: win-dco becomes the default, wintun is removed
OpenVPN 2.7 makes its Windows strategy clearer—and more decisive. The release delivers several architectural changes: the block-local flag is now reinforced using WFP (Windows Filtering Platform) filters, Windows network adapters can be generated on demand, and the automatic Windows service can run as an unprivileged user, reducing the blast radius of potential issues.
Crucially, OpenVPN 2.7 notes that support for the wintun driver has been removed. win-dco is now the default driver, with tap-windows6 as the fallback for use cases not covered by win-dco. That shift will matter to anyone maintaining Windows deployment scripts, documentation, or support playbooks—this is the kind of change that benefits long-term consistency, but demands short-term validation.
Data channel hardening: AES-GCM limits, epoch keys, and smarter routing checks
Beyond the platform headlines, OpenVPN 2.7 updates the data channel by enforcing an AES-GCM usage limit and introducing epoch data keys and an updated packet format. These changes target robustness in high-volume or long-running sessions—areas where subtle cryptographic and protocol details become operationally relevant.
The release also refines the “Recursive Routing” check: it is now more granular and only drops packets-in-tunnel when the destination IP, protocol, and port match what’s required to reach the VPN server—reducing unwanted packet drops in complex networks.
A release that targets day-to-day ops, not just feature checklists
Taken together, OpenVPN 2.7 looks like a release built around how VPNs are actually used in 2026: dynamic policies, mixed endpoints, DNS complexity, and a constant push for efficiency. DCO and multi-socket will interest the performance and infrastructure crowd, while PUSH_UPDATE and DNS improvements target the operational reality of keeping VPN services stable without turning every configuration tweak into a forced reconnect.
Frequently asked questions
What is OpenVPN DCO and why does OpenVPN 2.7 care about it?
DCO (Data Channel Offload) is a kernel-assisted approach to handling OpenVPN’s data channel more efficiently. OpenVPN 2.7 adds support for the upstream Linux ovpn DCO module and points to backports for current kernels.
Does OpenVPN 2.7 really allow route/DNS changes without reconnecting clients?
Yes. The new PUSH_UPDATE control-channel message allows servers to push updates (such as routing and DNS options) to clients without forcing a reconnect, reducing disruptions.
What changed on Windows with drivers in OpenVPN 2.7?
OpenVPN 2.7 removes support for the wintun driver. win-dco becomes the default, and tap-windows6 remains as a fallback for scenarios not covered by win-dco.
What’s the practical benefit of “multi-socket support” for OpenVPN servers?
It lets one server instance listen on multiple addresses/ports/protocols—useful for IPv4/IPv6, multi-interface servers, and deployments that need multiple entry points without running multiple OpenVPN instances.
vía: OpenVPN 2.7 update