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.

[Staff 10385]

8 hours ago, EMULE said:

Can QUIC simulation in AmneziaWG 1.5 solve this problem?

Hello!

It could. Feel free to try it.
 

8 hours ago, EMULE said:

Some servers have all ports unavailable via Wireguard, some can only use one specific port

Let us double check in order to ascertain that the problem is not on the server side: can you please send us the names of the servers you experience this problem on?

Kind regards
 

[EMULE 10]

41 minutes ago, Staff said:

can you please send us the names of the servers you experience this problem on?

This is a problem. Because it's dynamic.
For example, today I can connect to all ports on server A, but only to a specific port on server B.
Tomorrow, I might only be able to connect to the specific port on server A, while all ports on server B will be available.
All servers behave this way; there's no guarantee that one will always be available and another will always be unavailable.
Server hardware and software are fixed, and my network environment is also fixed. Only the server load is dynamic, which is why I suspect it's a problem of Wireguard resources being exhausted on the server.
Perhaps OpenVPN is consuming too many resources. I think we can verify this on the two servers testing DCO by increasing the priority of WireGuard and seeing if all WireGuard ports are available.

[Staff 10385]

2 minutes ago, EMULE said:

This is a problem. Because it's dynamic.
For example, today I can connect to all ports on server A, but only to a specific port on server B.
Tomorrow, I might only be able to connect to the specific port on server A, while all ports on server B will be available.

Hello!

Understood. This is typical with dynamic blocking by GFW and other blocking tools. Remember that GFW (and other blocking tools) behavior is not deterministic, as clearly disclosed and proved at the USENIX Security Symposium 2025. We have already put in place methods capable to defeat the GFW in most circumstances (probably 85% success rate), as you have noticed, and when you are blocked by some heuristic decision of the GFW you necessarily need some trial and error. We are working to increase the success rate even more, stay tuned in the near future.
 

8 minutes ago, EMULE said:

Perhaps OpenVPN is consuming too many resources.

No, this is not the case. OpenVPN eats resources but not in a critical way, and it will require less and less resources while more and more clients switch to WireGuard or AmneziaWG.

According to your description, to the lack of any warning by our monitoring system, and the fact the we have no similar complaints from Western countries, we feel comfortable to say that this is not a server side problem.

Kind regards
 

[EMULE 10]

2 minutes ago, Staff said:

This is typical with dynamic blocking by GFW and other blocking tools.

Really? It's good news to know that it's not a server issue.😂
It seems the only option left is to try AmneziaWG 1.5.
😡Damn the GFW! The latest GFW has incorporated AI, greatly enhancing its ability to block VPN protocols.
Fortunately, China is vigorously promoting IPv6, which allows me to catch my breath for now.
The future depends on full support from the AmneziaWG protocol.🙌