Don't let openvpn get a swelled head. Itself it was just a Bender project ("I'm gonna write vtun better; with hookers and beer!") anyway.

merlin has built-in wireguard support??

Try openwrt, ddwrt is cancer.

Oh that's interesting, though my model isn't on the list ;(

I'm sure it is, Im just not sure where to start and I get pretty decent speeds on open vpn. I guess now I'm going to have to try to figure it out

Oh I know it's odd. I think it must be something with my router or windows configuration, but it's very noticeably different between the two.

Yep. I entirely agree about the good points. I am just always weary about removing options like this, regardless of intention.

I'd be fine if for example I'm running my own wireguard implementation, I could choose the suite to use, not negotiate anything and ensure my client has the same configuration.

I'd probably not use it, but I like the option, and knowing that anyone that wants to try to break this now also needs to guess what options I'm running.

Well, I did think the "security through obscurity" line would come up. But that's really something that should be reserved for people making their own "triple XOR" crypto implementations closed source and hoping that protects them.

The "obscurity" if it's the term we want to use here in my use case isn't hiding using closed source to provide a perception of security. It's just giving a choice of crypto, but not adding to the protocol with negotiation.

My thinking is this, and we'll look at say ssh. We can choose between multiple key types and lengths for that. Now let's say for example ed25519 is compromised (in real terms I think the only likely compromise for any of the ssh key based auth options would be deriving a private key from the public key, so the "scanning" I talk about is a fantasy. But I'm going with it!). For ssh, there will for sure be bots hunting the internet for vulnerable ssh servers very soon after. Automating the process of getting in, installing whatever nefarious tools they want and moving on. But, crucially they will only get those that have used ed25519 for their auth key login. However they might well get every single wireguard vpn.

I'm really just advocating for the same option really. The option to not use the same as everyone else. With no reduction in security for anyone else and no need to negotiate, the onus would entirely be on the operator to ensure the same stack is configured on client and server. Of course with the understanding that using any other stack is at your own risk. E.g. "triple XOR" security might not be the best, for example :P

Oh and as I said, I doubt I would use it. I use wireguard as it is, I like wireguard as it is. But, I feel like having options is not a bad thing, provided the default is the "best" option currently known.

Yeah OpenVPN is often used for business reasons (e.g. by remote workers), so it's usually not blocked wholesale, only throttled (and known public VPNs providers and blocked via blacklisting their endpoints' ip addresses). Wireguard meanwhile is used much more rarely so there is less fallout from blocking it completely.

Yea every network may do things differently... in my case tcp/443 openvpn is blocked at several places that I frequent.

Wireguard is not Sensorship and DPI resilient at all, it relies solely on UDP. They state it on their official website that it's not their priority at all

Can second AirVPN being slow as shit

Is that so. I also think that windscribe is better

windscribe goes on sale a few time in the year. You can get it for 29$ a year which is a great price and for 20$ more you have static IP and permanent port-forwarding. It's a great deal for a trustworthy and feature rich VPN in my opinion

Maybe, but I'm using Gluetun's API too (which is very badly documented), and it seems to me some of the endpoints only work for OpenVPN. But I'll have to look into it properly.

Can you run multiple wire guard connections simultaneously? The reason I stick with OpenVPN is because my work uses wire guard and I can run two connections at the same time.

Thank you for the reply!

It isn't in a lot of ways

OpenVPN operates in kernel space as of 6.16. Well specifically for the data channel. Control channel is still managed in userspace so you don't have to do asymmetric TLS in the kernel. This also reduces the overhead and increases performance substantially. It is slightly more complicated to setup but barely tbh (I'm speaking from the server side). Is the crypto outdated? Not as far as I'm aware.

The big thing for public VPNs is the server can push the configuration to the client rather than having it be static. Config push, specifically for addressing is basically the only viable way to do a NATless VPN. Additionally while unrelated to public VPN providers wg does not have the ability to bind to individual IPs which is a headache for my internal VPN use case.