OpenVPN DCO Linux Kernel Module Aims To Offer Faster VPN Performance

[Mark Rose]

Will this be able to prolong my uptime on battery on my laptop while using openVPN?

Yes. This should cut OpenVPN CPU usage dramatically. The parallel encryption should also allow lower clocks across all cores instead of pinning just one. Won't make much difference for casual web browsing, but if you're doing big transfers or watching video, I bet the reduction in battery usage will be easily measurable.

[oibaf]

Would be interesting to compare it to classic userspace-only OpenVPN and WireGuard.

Comparison to classic userspace OpenVPN is on the linked article: https://openvpn.net/blog/openvpn-data-channel-offload/

Quick summary:

[sinepgib]

Couldn't they use eBPF for that? At least for the decryption phase.

It depends on whether the necessary functions are exposed and how old are the kernel versions they intend to support. They might also want to make sure it's always native code, while sometimes eBPF can be JITted and sometimes it will be interpreted by a VM, depending on configuration. Maybe they found it was a better trade off for them to just write a module.

[edwaleni]

Correct me if I am wrong:

Wireguard is UDP only and only uses stream ciphers.

OpenVPN supports TCP and therefore TLS.

Same purpose but different approaches.

A kernel approach to process TLS traffic would be a good thing, (I would think) as it would handle the encrypt/decrypt more effectively.

[birdie]

Comparison to classic userspace OpenVPN is on the linked article: https://openvpn.net/blog/openvpn-data-channel-offload/

So, roughly eight times faster, nice. VPN providers must be extremely interested.

[brad0]

Funny how chrome made firefox much better and now wireguard made openvpn much better.

Yet Firefox sucks so hard and it is regressing at such a fast pace it is ridiculous. If only OpenVPN could make WireGuard better; still leave a lot to be desired.

[oibaf]

Correct me if I am wrong:

Wireguard is UDP only and only uses stream ciphers.

OpenVPN supports TCP and therefore TLS.

Same purpose but different approaches.

A kernel approach to process TLS traffic would be a good thing, (I would think) as it would handle the encrypt/decrypt more effectively.

OpenVPN is usually UDP, there is also TCP mode to be used when, for example, only TCP ports 80/443 are permitted by the firewall.
The kernel module won't implement TLS, just the data channel, which is where the performance is needed.
TLS in OpenVPN is just used by the control channel and this won't be moved to the kernel.

[sinepgib]

OpenVPN is usually UDP, there is also TCP mode to be used when, for example, only TCP ports 80/443 are permitted by the firewall.
The kernel module won't implement TLS, just the data channel, which is where the performance is needed.
TLS in OpenVPN is just used by the control channel and this won't be moved to the kernel.

Since the kernel already supports handling TLS (not sure to what level tho), wouldn't it be a reasonable next step to take advantage of that support here?

[intelfx]

Since the kernel already supports handling TLS (not sure to what level tho), wouldn't it be a reasonable next step to take advantage of that support here?

No, there is no point in doing that because, as just said, TLS is only used for the control connection that has a negligible amount of data passing through it.