Request: Dedicated Wireguard Servers

[ms2738 12]

While I love that you continue to support OpenVPN would you please reconsider a few WireGuard‑only 10–20 Gbit servers to quantify the uplift for users who prioritize raw speed and low latency?  It’s my understanding that OpenVPN server processes are single‑threaded and CPU‑intensive. Co‑hosting OpenVPN and WireGuard on the same high‑capacity host (10–20 Gbit) can constrain aggregate throughput under load because per‑core bottlenecks caps per‑host headroom when many OpenVPN clients are active.  In cities where you have multiple 20 Gbit servers like New York dedicating one to Wireguard doesn't seem unreasonable?  Thank you for your consideration. 

[ms2738 12]

+1

[ASiC666 0]

I vote this up as well, as the suggestion makes perfectly good sense.

Personally I wouldn't mind if OpenVPN takes the decommissioning route.
Although it still provides a solid solution, it's a product of its time and it shows (no kernel support, single threaded etc).

Some VPN providers are either started or already phased it out.
And I will assume the gains are in favour as much for the users as the providers themselves with WireGuard's being less demanding on the compute resources.

My two pence

[Staff 10381]

Hello!

Please note that the ability to connect over a generic HTTP, HTTPS, SOCKS4 and SOCKS5 proxies, especially those only supporting TCP, is an OpenVPN strong feature that's not matched by WireGuard. The flexibility and ease of OpenVPN to do it is very important for anyone connecting from behind a proxy (such a corporate proxy). This is a feature that we do no want to lose so phasing out OpenVPN in its entirety is not on the table at the moment.

Another similar, powerful feature that WireGuard can not offer is establishing an SSH tunnel, or a TLS one (by stunnel typically) and then connect OpenVPN over it.

However, a balanced approach is possible, and we are already moving toward that direction. For example, our kernel networking tuning is preferring WireGuard needs, not OpenVPN ones, although the approach is not too unbalanced. In the future we might also consider to lower the amount of concurrent OpenVPN processes we run on servers (we do it to aid balancing for the notorious problem you mention and for which a stable and easy to maintain DCO would be a solution).

Kind regards