OpenVPN, one of the most recognizable names in the VPN world, has just announced OpenVPN 2.7.0 as the newest stable release of its software for establishing secure connections—both point-to-point and site-to-site. In an industry where many improvements tend to be discreet and cumulative, this release brings noticeable changes on the front lines: support for Data Channel Offload (DCO) via the new ovpn module on Linux, compatibility with mbedTLS 4, progress in TLS 1.3 (featuring cutting-edge mbedTLS versions), and significant updates in DNS management and Windows architecture.
The message for tech media is clear: OpenVPN 2.7 isn’t just about “polishing” the product but about modernizing key components that influence performance, operational stability, and security. It arrives at a time when many organizations still rely on OpenVPN as a backbone for remote access, site interconnection, hybrid environments, or legacy infrastructure compatibility.
DCO on Linux: Bringing VPN closer to the kernel for better efficiency
The main technical highlight of OpenVPN 2.7 is the support for the Data Channel Offload (DCO) module. DCO aims to reduce data channel overhead by shifting some processing to the kernel, seeking to enhance efficiency and performance especially in high-traffic or large-client scenarios.
In OpenVPN 2.7, user-space software can now work with the ovpn DCO “upstream” module—that is, integrated into the main Linux kernel. Final availability depends on each distribution’s adoption cycle and kernel packaging, but the project presents it as a future path where offload becomes less of an external component and more a standard part of the Linux ecosystem. For those needing the module on current kernels that haven’t adopted it yet, backports are available via the ovpn-backports project—a common solution in enterprise environments where kernel updates aren’t always immediate.
Practically, this provides system administrators with a technical decision: experiment with DCO in labs or specific services where performance is a bottleneck, and plan migration once support is fully aligned with their distribution and maintenance policies.
Multi-socket: one server, multiple addresses, less complexity
Another direct-impact improvement for real-world deployments is multi-socket support on the server. OpenVPN 2.7 enables a single instance to manage multiple addresses, ports, or even protocols, avoiding duplicated configurations or parallel processes for common scenarios such as:
- Simultaneous listening on IPv4 and IPv6,
- Multihomed servers with multiple interfaces,
- Services exposed across different ports due to compatibility or network policies.
While it might seem like a convenience feature, in environments with hundreds or thousands of users, it reduces operational complexity, eases migrations, and streamlines maintenance.
PUSH_UPDATE: changing routes and DNS without disconnecting
OpenVPN 2.7 introduces client-side support for the new control channel message PUSH_UPDATE, designed to allow a server to send configuration changes—such as routes or DNS settings—without forcing reconnection.
Additionally, the release includes “minimal” server-side support, with new management interface commands to emit updates to specific clients or broadly. For IT teams, this means fewer disruptions when adjusting routing policies, split tunneling, internal DNS configurations, or infrastructure changes. In essence: the VPN stops being an “all-or-nothing” tool as configurations evolve.
DNS: better cross-platform consistency and advanced Windows features
DNS management has historically been one of the most sensitive areas for VPN clients, especially when handling corporate domains, internal resolutions, and security policies. OpenVPN 2.7 enhances this segment with “more DNS out of the box”:
- Default client implementations for Linux, BSD, and macOS included in standard installations,
- A new Windows implementation supporting features like split DNS and DNSSEC.
This approach aims for more consistent behavior across platforms and allows the client to implement modern DNS policies without heavily relying on external solutions or fragile integrations.
Furthermore, two new environment variables are introduced to handle default gateway redirection via plugins like NetworkManager. This technical detail can be the difference between a “clean” integration and one that breaks with minor route changes.
Windows: win-dco gains ground, wintun is phased out
Windows-related updates feature notable changes. OpenVPN 2.7 consolidates architecture and security improvements, including a significant move: dropping support for the wintun driver and making win-dco the default driver, while tap-windows6 remains as a fallback for unsupported cases.
Additional security and operational enhancements include:
- The block-local flag now enforced more robustly via WFP (Windows Filtering Platform),
- Network adapters can be generated on demand,
- The automatic service can run as a non-privileged user,
- The win-dco driver now supports server mode.
For enterprises, the takeaway is that OpenVPN is modernizing its Windows operation with a design aligned to best practices: fewer privileges, more filtering control, and a driver foundation guiding future developments.
Data channel limits: AES-GCM and per-epoch keys
On the cryptographic and data channel robustness front, OpenVPN 2.7 introduces improvements such as:
- Applying usage limits to AES-GCM,
- Implementing epoch data keys and a revised packet format.
This set of changes sits at the intersection of security and operational performance: aiming to reinforce cryptographic guarantees when using AEAD ciphers at scale, while modernizing key and packet management. In high-volume deployments, these details matter: they are the subtle distinctions that separate a “working” VPN from one that remains secure and reliable over time.
A release that calls for planning and offers room for improvement
OpenVPN 2.7.0 arrives with a comprehensive list of updates that collectively represent a clear evolution: a stronger foundation for performance (DCO), more flexible deployments (multi-socket), greater control without disruption (PUSH_UPDATE), and practical advances in DNS and Windows support. For technical teams, the recommended approach is to experiment and plan: test win-dco within Windows environments, review compatibility with the Wintun deprecation, and evaluate how well the ovpn DCO module integrates based on the kernel version in use in production.
This isn’t just a “cosmetic” update: it’s a version that updates core aspects. And in tech, that’s usually a good sign when done with a clear purpose.
Frequently Asked Questions
What is OpenVPN DCO and why is it important in OpenVPN 2.7?
DCO (Data Channel Offload) lets part of the data channel process be delegated to a kernel module (ovpn), aiming to reduce overhead and improve efficiency—especially in high-traffic scenarios.
Does OpenVPN 2.7 support changing DNS or routes without disconnecting?
Yes. The PUSH_UPDATE feature allows the server to send configuration changes—such as new DNS settings or routes—without disconnecting clients.
What changes do Windows users see with OpenVPN 2.7 and the wintun driver?
OpenVPN 2.7 drops support for wintun and sets win-dco as the default driver; tap-windows6 remains as an alternative for unsupported cases. Security and filtering are also enhanced with WFP and reduced privileges for services.
How does OpenVPN 2.7 improve the data channel with AES-GCM?
It applies usage limits to AES-GCM encryption, and introduces epoch data keys and a revised packet format to strengthen cryptographic guarantees under high load.
via: OpenVPN 2.7 Update