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 10385]

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
 

[EMULE 10]

Yes, I'm using AmneziaWG to connect, and on many servers, all WireGuard ports are either unavailable or only one port is available. However, OpenVPN can connect using all protocols. I suspect OpenVPN is consuming too many resources, leaving the servers with no resources available for WireGuard connections. Allocating more server resources to WireGuard might be the solution to the WireGuard connectivity problem.

[Staff 10385]

12 hours ago, EMULE said:

on many servers, all WireGuard ports are either unavailable or only one port is available.

Hello!

This is a problem caused by blocks though, not a server problem.

Kind regards
 

[EMULE 10]

10 hours ago, Staff said:

This is a problem caused by blocks though, not a server problem.

Really? So how can this be resolved?
Change the connection protocol?
But it's still the same when I use AmneziaWG 1.0. Can QUIC simulation in AmneziaWG 1.5 solve this problem?
My ISP did not block the corresponding UDP ports. Some servers have all ports unavailable via Wireguard, some can only use one specific port, and some can connect to all three ports. What a perplexing question!
Wireguard is not as available on all servers as OpenVPN, which causes some trouble for users who use Wireguard to connect.
Did WireGuard require strict network conditions from the outset? I always feel that WireGuard's compatibility is not as good as OpenVPN's. Is it that network compatibility is sacrificed for high performance?
In any case, allocating more resources to Wireguard is reasonable, as Wireguard's high performance will be appreciated by more people.
Of course, OpenVPN is also indispensable, as there will always be some people who need to bypass strict network restrictions.
Is DCO an effective solution for optimizing both? I'm really looking forward to it.
So, what stage is DCO testing at? Is DCO 2.6.14 still unstable? OpenVPN 2.7 series has already removed support for WinTun, so I believe the OpenVPN team is full of confidence in DCO for the 2.7 series. I'm really looking forward to seeing the DCO effect in the official 2.7 series.