Because OpenVPN is fiddly to set up and modern Wireguard setups seem to scale well enough.
this post was submitted on 18 Aug 2025
482 points (99.0% liked)
Technology
74292 readers
4180 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
I remember maybe 12-15 years ago, setting OpenVPN on my TomatoUSB flashed router, invoking all kind of openssl command to generate certificates, keys, signing stuff, setting the router, setting the TAP/TUN clients etc. but once setup it works for years on my laptop, phone, etc.
Now with WG I basically scan on my phone a QR code generated on my Merlin router and that's it.
merlin has built-in wireguard support??
yes for a long time now
Try openwrt, ddwrt is cancer.
What? Why?
I used to use ddwrt until I didn't have a router (forced by cablemodem that I couldn't modify)
But then I got fiber with a bridge and discovered OpenWRT and it was so incredible.
So much more capable and such a better more competent community.
Much more competent and ethical leadership that doesn't violate the GPL.
How it works, just made more sense to me, there are so many feature I never want to lack in a router and frankly I wish I had in every linux distro.
One of my absolute favorite thing about it, is that anything you click in the web interface, is a command run in the underlying system.
Here I am setting a DHCP tag, which makes it so that all computers with a certain MAC address will receive a non-routing gateway, cutting them off from the internet. I use this to stop my TVs and VMs from connecting to the internet without having to deal with a bunch of static IP addresses and that whole firewall tedium.
Notice how it's giving me the exact commands
And the WebUI shows you all the commands before they run it. Not only that makes understanding how the system works underneath. It makes it very easy to reproduce all the same configuration using bunch of commands you can paste from a text file !
Recently I wanted to turn older such routers into dumb wifi access points and they were all mostly the same, so I just flashed them and then ran a series of commands that I learned from the Web UI, with just some things tweaked for each device.
For me that feature alone makes the difference, but also the sketchiness of ddwrt with regards
I think ddwrt gets love because ANYTHING is better than the awful, unreliable stock and locked down web user interfaces on routers. But between ddwrt and openwrt, I think it is no-contest, openwrt is the best choice between those two.
Here is a bunch of articles more about this
https://wi-fiplanet.com/the-dd-wrt-controversy/
https://hackaday.com/2011/09/21/modifying-dd-wrts-protected-gui/
https://ebb.org/bkuhn/blog/2009/12/06/anatomy-gpl-violation.html
https://www.linksysinfo.org/index.php?threads/fresh-tomato-vs-openwrt-vs-dd-wrt.76178/
https://old.reddit.com/r/openwrt/comments/ld05u6/whats_the_difference_openwrt_ddwrt_tomato_opensan/
https://old.reddit.com/r/HomeNetworking/comments/9hk0lm/is_ddwrt_no_longer_recommendedgeneral_opinions_on/
https://www.raspberrypibox.com/dd-wrt-vs-openwrt/
https://news.ycombinator.com/item?id=8060911
https://old.reddit.com/r/HomeNetworking/comments/j5u3kf/why_is_ddwrt_such_a_pain/
https://old.reddit.com/r/linux/comments/3skn25/fcc_we_will_not_ban_ddwrt_on_wifi_routers/
Huh. Alright, that's pretty convincing. Thanks.
can't with broadcom
I hear you, I also have broadcom ewaste, a Trident 2+ switch running open switch and I can never upgrade the debian 9 OS running kernel 4.9.
I had to create a QEMU VM, put proxmox on it and put openwrt into an LXC in that to make it work. Our technology landscape is completely ducked.
EDIT: it’s been pointed out to me that using NetworkManager for Wireguard setup is shit. Instead use nmcli, this seems to have solved my problem.
I'm using Bazzite Linux with KDE, and for me Wireguard setup is copy/pasting several bits of information on multiple settings pages. OpenVPN is just downloading a single config file and inputting my user/pass.
Also, Wireguard disconnects so often, no matter which distro I'm on, that it's a pain in the butt having to reconnect a few times an hour. Not to mention that I can't have it set to autoconnect on login, or my internet doesn't work until I disconnect and reconnect.
Interesting, I also use KDE (on arch btw) and I definitely have had hours-long work sessions with ssh over a wireguard vpn to access my home PC from abroad, so I imagine the issue is probably not on the KDE side of the stack
These immutable distros always create a thousand little problems like that.
I don't think it's Bazzite, as it didn't work on NixOS or Nobara either. It's got to be something with my ISP, because as I said in my previous comment, it hasn't worked over multiple distros.
Wireguard disconnects so often
Wireguard is udp, it never "connects", there's no session.
Wireguard disconnects the WiFi.
However, it has been pointed out to me that my problem was using the GUI for NetworkManager to add the VPN, which apparently is shit for Wireguard. I added the VPN using nmcli instead and so far it’s working as intended.
WG was always so much better anyway.
Well it was written to replace open VPN right? So that makes sense
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.
load more comments
(1 replies)
load more comments
(3 replies)
Urgh, I don't really have time to do this migration but guess I'm planning it in anyway.
Past me was a lazy bum. But I'm confident that future me is all over this. Time for a nap.
Damn you sir, you didn't need to call me out with that last paragraph.
No, I know it wasn't my shoe, but look at how well it fits!
This post makes it look like there's something serious ly wrong with openvpn, but it's just them not wanting to deal with it and deprecating it.
Oh well, guess Ill put a note not to use them. My country blocks VPN protocols and wg specifically, so for my usecase I need as many protocols supported as possible, preferrably mimicking other innocuous protocols.
mullvad and windscribe are the only two i support <3
Do you have a stance on IVPN?
I’ve had an active iVPN sub for almost 8 years now. Cannot say anything bad about them whatsoever
recently switched from mullvad to ivpn, and the servers are noticeably slower. with mullvad all the servers I used achieved my connections max speed 500 mb/s but on ivpn they usually do 50 - 300, and sometimes i need to switch server because they go down (i use european servers). only reason i switched was because mullvad causes a wakelock on mint cinnamon and it drives me nuts.
load more comments
(5 replies)
load more comments
(4 replies)
I only have one problem with this. When they say wireguard being crypto opinionated is a good thing. I am weary to agree with that statement entirely.
While it is good for stability (only one stack to support and get right, and to be secure and efficient) I do wonder about overall and future security. Saying "You must use this specific cipher suite because we think it's the best" is a bit of a dangerous road to take.
I say this just because Curve 25519 is considered a very secure elliptic curve, to the best of my very limited knowledge on this subject. But we had a certain dual elliptic curve pseudo random number generator was pushed as "best practice" (NIST backed) some time ago, which didn't turn out so well, even omitting possible conspiracy scenarios, it had known weaknesses even before it was recommended. [1]
Since then I've generally not been a huge fan of being given one option as "the right way" when it comes to cryptography. Even if it is the "best" it gives one target to try to find a weakness in, rather than many.
I say all this as a wireguard user, it's a great, fast and reliable VPN. I just have concerns when the choice of using other algorithms and especially putting my own chosen chain together is taken away. Because it puts the exact same target to break on every one of us, rather than having to work out how to break multiple methods and algorithms and multiple combinations.
I think the idea behind opinionated cryptography is not only the idea of "We think this is the best, so you have to use it", but most importantly it removes all requirements of the protocol supporting cipher negotiation. This makes the protocol much simpler, easier to audit and as a result more secure. And if the cryptography in the protocol ever shows a weakness, then Wireguard v2 needs to be released as a breaking change. See all the SSL/TLS versions
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.
No. You are making assumptions about security and ultimately assuming you're the only one who thought this along the way.
knowing that anyone that wants to try to break this now also needs to guess what options I’m running.
Unless your security model has you being specifically targeted by advanced threat actors, the most likely scenario is that you’ll be affected by randomly discovered security vulnerabilities and not individuals tailoring an attack for your configuration.
Obfuscation of your configuration doesn’t add much security and using obscure settings could just as easily result in security vulnerabilities of their own. Vulnerabilities which, due to the obscurity of your configuration, may not be discovered by white hats for much longer.
I know that, if wireguard is exploitable, it’s very unlikely to be me that would be targeted. There are larger and more lucrative targets acting as honeypots for everyone else.
Even if it is the "best" it gives one target to try to find a weakness in, rather than many.
It sounds as if you're falling prey to the allure of security through obscurity.
I'd like to remind you of Kerckhoff's Principle.
a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge
What this is saying is that in a secure cryptosystem all you need to secure is the key.
Curve 25519 is, for the time being, considered a secure cryptosystem. It's likely that in the future it will become obsolete, but we're not there yet. When we get there WG will port to a new cipher that is more secure.
Even if you set your configs to not negotiate, just the fact that the stack COULD negotiate opens you up to downgrade attacks. Also, anybody trying to connect would get some kind of hello/response traffic that would broadcast your (non negotiable) configs, so what do you gain from being able to choose, except the ability to make mistakes?
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.
I think your example of SSH is actually the perfect counterpoint to your position!
SSH is versatile but there's SO many ways to configure it in an insecure way. It's important for SSH to be versatile because of how many different devices need it, but that also means it's really easy to have a config that supports crappy ciphers (3DES, RC4, etc), or enabling root login, or pick any other hundred problems that are either due to user misconfigs or just inherent vulnerabilities in a cipher or key exchange method. Its versatility is the core of its weaknesses.
For ssh, there will for sure be bots hunting the internet for vulnerable ssh servers very soon after. Automating the process of getting in
This already happens right now. If you have 22 open, your firewall is getting hammered with bots trying to get in, regardless of what cipher you're using, trying to exploit known weaknesses.
WG was never meant to be a swiss army knife, even though it is also versatile. It's designed to be fast, secure, and as dummy proof as possible.
giving a choice of crypto, but not adding to the protocol with negotiation.
I'm not sure how you'd achieve this. If you have a mechanism to change cipher modes then there would be part of the codebase and handshake that validates settings in some way, which adds potential attack vector.
History shows that every cipher mode eventually will be vulnerable to new computing power, I don't think that's avoidable. Quantum computing is the next big event on the horizon, which is why quantum resistant ciphers, even old ones that never really got adopted, are getting a lot of attention if they're deemed to be quantum resistant.
The important thing is that if, not when, it's reported that the cipher is vulnerable that people harden their networks in other ways until a new cipher mode is implemented. That's just how it works IMO. Edge security cannot and should not be your only security method anyways.
Overlay VPNs like tailscale and zerotier are interesting to me because you don't have to open any ports. I'm sure they have their own inherent vulnerabilities also but they don't make you punch holes in your firewall, which makes them less vulnerable to random attackers trying to scan your network edge.
This already happens right now. If you have 22 open, your firewall is getting hammered with bots trying to get in, regardless of what cipher you're using, trying to exploit known weaknesses.
I know, except they're only ever trying lame user/password pairs that only an idiot would have on their luggage. Same as on asterisk and the bots trying to exploit decades old exploits on wordpress etc. Regardless of whether the site you host is even remotely like wordpress.
I'm not sure how you'd achieve this. If you have a mechanism to change cipher modes then there would be part of the codebase and handshake that validates settings in some way, which adds potential attack vector.
Doesn't need to change the handshake. If the server is mine, and run by me and I decide I was to change say, just the key exchange part of the process. It could be changed without negotiation. I just need to make sure all clients are configured the same way. My point being there wouldn't be a negotiation. If you try to connect to wireguard on my server, you'd need to have the key exchange setup in the same way, with the same parameters too. Yes, it should be entirely optional and require specific configuration changes on both client and server to achieve. So long as server and client are configured with the same parameters there's no negotiation to make. The channel can be setup and if the configuration is wrong it just won't work.
A bit annoying for all the things that don't support openvpn, like old Synology NAS devices.
You can install a wireguard spk from blackvoid - Wireguard SPK for your Synology NAS.
Oh that's interesting, though my model isn't on the list ;(
Bummer. For whatever reason I always get much better speeds on openvpn servers.
That's not something you hear very often.
That’s very strange. WireGuard was specifically created in part because of speed limitations.
Sounds like an issue with your network or routes. By design, WG is faster.
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
Try lowering MTU, just don't lower it too much.
load more comments
(2 replies)
view more: next ›