11 ms·

Why not “Why not WireGuard?” (2020)

256 points by jitl 5y ago

tptacek 5y ago
This is ranking today because "Why Not WireGuard" ranked earlier, and the thread for that story is here: https://news.ycombinator.com/item?id=28896351 https://news.ycombinator.com/item?id=28896351
protoman3000 5y ago
We still can’t get WireGuard to work if the client uses the WiFi on our university campus. Does anybody have an idea how to overcome this?
- saberd 5y ago
  Are outgoing ports blocked by the university? Wireguard servers usually use port 5000. http://portquiz.net:5000/ http://portquiz.net:5000/
  - iso1210 5y ago
    I run wireguard servers on many ports, including 53, 443 and 5-figure numbers. I don't think I've got 5000 anywhere though.
    - 5e92cb50239222b 5y ago
      Same. Not that it means much, but I've been seeing 51820 being used in all documentation, blog posts, etc. Probably just copypasting the original examples, e.g. https://www.wireguard.com/quickstart/ https://www.wireguard.com/quickstart/ https://www.wireguard.com/xplatform/ https://www.wireguard.com/xplatform/
      - chupasaurus 5y ago
        A month ago I dug through the history, the only trace to origin of using 51820/UDP I've found is that the number is hardcoded in one of the tests.
  - jitl 5y ago
    Wow this Portquiz thing is great!
- ThatGeoGuy 5y ago
  There is a whole host of things this could be, but you may want to talk to your University IT and determine if they're doing any kind of port blocking, NAT blocking, etc. on the network. Many campus networks are fairly restricted, often for a variety of reasons. IPSec / OpenVPN may get a pass because they're known exceptions, whereas Wireguard is new enough I'd not be surprised if your campus didn't move fast enough to include it as an exception.
- sagres 5y ago
  What port is your Wireguard server listening on? It's most likely UDP/51820. Ask them to open UDP + port number.
- cge 5y ago
  If the wifi is eduroam, as many are now on university campuses, you should take a look at the service standards [1], especially page 32. While recommendations (on page 33) are only to block a minimum number of ports, if needed, in practice, I've found that some universities block all ports except those they are required to have open per eduroam policy. This includes blocking all UDP ports except 4500, 1194, and (outgoing only) 500. The trick of using common TCP ports won't work on these networks, as they open those only for TCP per policy, and often only outbound. On those networks, I've found using port 4500 for WireGuard works. This is a bit annoying, because the policy is clearly designed to ensure that VPNs work, it just isn't written to support WireGuard yet. [1]: https://www.eduroam.org/wp-content/uploads/2020/02/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf https://www.eduroam.org/wp-content/uploads/2020/02/GN3-12-19...
  - jeroenhd 5y ago
    Funny, the eduroam universities I've been to never blocked any outgoing traffic based on port number alone. In fact, one of them essentially provides you with a world routable IP address, only blocking some incoming ports known for abuse such as 25 and 53. A port scan of the network is a reminder of how badly the world has been relying on NAT to provide security (which it doesn't even do in the real world) because people will just permanently disable their firewall and think nothing of it. Once you hit the wired network, all ports are free game, which is even worse! Luckily, these networks are scanned and honeypots/badly configured servers will get hit with a warning in hours to minutes. My solution for those restrictive networks is to pick common ports as well. Outgoing ports 53 and 443 work in most networks I've tried, even for UDP. Running a WireGuard server on port 53 means you can't run DNS from that server, and running a server from 443 means no HTTP/3 or QUIC. If the goal is to run a server from behind Eduroam then I think you'll be tough out of luck.
    - gnufx 5y ago
      I suspect there's a big variation, particularly in whether the university has placed the keys to the kingdom in the hands of a "partner" of, shall we say, dubious competence and understanding of academia, after getting rid of decades worth of local experience. Fortunately those with decades of experience outside Networks group can usually find an "impossible" way to work around notwork and other roadblocks, but it's so much wasted time.
- trulyrandom 5y ago
  You could try running Wireguard over port 443. Since HTTP/3 also uses UDP and port 443, it's possible that the university network doesn't block this.
- jfoutz 5y ago
  I have some tangential experience with a big sprawling old university network. It's a hard job. On the one hand, you need to protect academic freedom. Someone really is writing a paper about sexuality and needs access to crazy port sites. There's also the 90 year old advisor that never really understood email and why it's bad to click on every link. Reach out to a professor, and write up a paper proposal about practical deployment of wireguard. You should be able to get some access to university IT folks. Not like, help desk, but net engineers. Take notes, capture the details about why it's tricky, and how you solve it. You're not going to get into a journal for pure research, or anything super fancy like that. But if you put in the time, you'll get wireguard working and get a little credit on campus as not being clueless.
- ngrilly 5y ago
  We had the same issue. Setting the MTU to 1280, the IPv6 minimum MTU (we use IPv6), instead of using the default value, fixed the issue.
29athrowaway 5y ago
What I do not like about IPsec is that it has a lot of moving parts and opportunities for vulnerabilities.
- jeroenhd 5y ago
  That's exactly my problem as well. The other problem I have is the way proprietary manufacturers rely on the fact you can configure IPsec insecurely so that they never need to update their broken-on-arrival IPsec hardware and software to support modern, secure standards.
hikerclimber1 5y ago
Everything is subjective. Especially laws.
RedShift1 5y ago
> In this section, Tremer argues that IPsec is not very hard to use after all — in contradiction to the experiences of most readers — and points out that you only need to specify your own public IP address, the public IP of your peer, the subnets you want to make available for each side, and a pre-shared key. After that, the VPN “is compatible with every vendor out there.” > This is a surprising set of claims. First of all, that is not the only information needed to configure IPsec: critically, correct use of IPsec requires you to specify exactly which cipher suites you want to allow. This is an unanswerable question for anyone who is not a cryptography expert. The defaults are virtually never secure or cross-platform. This is so true. I once configured a Sonicwall and Cisco router and even though all encryption settings for both phase 1 and phase 2 were exactly the same, the tunnel refused to come up with negotiation errors. I had to change ciphers on both sides before it worked. Vendor incompatibility is an absolute pain with IPsec and IKE.
- twistedpair 5y ago
  +1. I've done cross cloud connects where the cloud vendors are on the phone with me and eventually say "We really don't have any idea why the tunnels are not connecting". And that's when using Cisco VPN appliances, no less, following everyone's setup instructions to the letter. Indeed, not a trivially solved problem yet.
  - Spooky23 5y ago
    Sounds like a real shitshow all around. Building IPSec tunnels between ASAs isn’t rocket science. I would be worried about downstream issues with the security architecture, especially down the road when you pick up clients with compliance requirements.
    - chasil 5y ago
      ...and I quote, "3DES in combination with MD5 is a common candidate..." If a security architecture is a priority, then these people will not be customers. Triple DES is not "boring crypto" by any means. https://news.ycombinator.com/item?id=13383006 https://news.ycombinator.com/item?id=13383006 Wireguard's crypto is boring. That's the point.
deleted 5y ago
[deleted]
jeroenhd 5y ago
"The long-term option is to reconsider why you need that legacy VPN concentrator in the first place. WireGuard is open source, can run in a pure software virtual machine [...]" I think the answer to this is that companies prefer to buy "boxes" over running their own infrastructure. Sure, under the hood it's the exact same thing, but Cisco can market a nice grey box with a logo to your manager and you can't market a Linux kernel tool. Why buy a VPN concentrator when you can run OpenVPN or IPSec in a VM? Easy, because the VPN concentrator is plug and play after setup and you don't need to worry about those pesky updates (you should worry but updates are rarely provided anyway). From my point of view, WireGuard and IPsec/OpenVPN serve two entirely different markets. Wireguard is there for the companies running their own Linux infrastructure already, providing the tools for quick and dirty VPNs with no cost and barely any complexity. IPsec and to some extent OpenVPN is there for the companies thinking in boxes (the VPN box, the web server box, the Cisco box, the firewall box) who don't care about how the VPN works as long as they can pay someone else to make the box and as long as it works with their existing devices. Before WireGuard, most articles writing about the kind of thing WireGuard is good at would recommend setting up OpenVPN. And truth be told, OpenVPN is pretty good at this sort of thing, it's just complex to properly understand because of its complexity. IPsec is left over to the professionals, bridging offices together rather than making servers talk to each other securely. You can do a lot of what IPsec offers through WireGuard, but you can do everything WireGuard offers through IPsec. Whether your want to use that complexity or not is your own choice, but I don't think there's a real answer to be found here. Because of this I think many people are talking past each other without realizing it. "VPN" can mean many things to many people. To people watching a lot of Youtube, it's for pirating movies or watching foreign Netflix. For people working with legacy/prebuilt IT, it's how WFH is done together with some strange Cisco product. To Linux/OpenBSD engineers, it's just a network layer with many different applications. To corporate, it's the button you press to make the accounting report go brrrr when you're on the road. Arguments for one use case easily fall flat for all the others.
- resonanttoe 5y ago
  >I think the answer to this is that companies prefer to buy "boxes" over running their own infrastructure. Sure, under the hood it's the exact same thing, but Cisco can market a nice grey box with a logo to your manager and you can't market a Linux kernel tool. This is spot on. Companies prefer it because it comes with a support contract and defined SLAs.* The vast majority of companies that don't actively develop infra or software, aren't going to invest in support for OSS . (Think retail companies). They want to buy a solution and that means all of the solution, including support and who they can blame when it catastrophically fails.* *These may be meaningless most of the time if its a suitably complex problem. ** Also they may just not equipped to actually hire and build the infra in a meaningful way.*
nicolaslem 5y ago
I used to use IPFire (the Linux distribution for routers mentioned in the original article), since then I switched my router to plain Debian, allowing me to use Wireguard. This is so much simpler than fiddling with the VPN settings in the IPFire UI.
knorker 5y ago
> Someday, WireGuard will need to be upgraded to support a second cipher suite. When this happens, users will be able to configure it peer-by-peer to allow one cipher suite or the other, or both, exactly as they would with any other VPN. Is that accurate? I thought they explicitly said that this is not the case, that instead a V2 would still have just the one protocol? In any case it's a non-problem, as you simply migrate by setting up V2 on a different port, and migrate client by client.
- alfiedotwtf 5y ago
  I'd say better this that having "cipher agility" like with IPSec. During design of IPSec, someone was advocating for the "NULL cipher" which is essentially no-encription where the use case was "debugging". Tie in cipher agility with the NULL cypher, and you've got yourself an awesome downgrade attack
- Shish2k 5y ago
  “Set up a new service and migrate all your clients” sounds _worse_ than “update the centrally managed config for existing clients” though? I’m only dealing with double-digit numbers of devices, and this “non-problem” sounds like a nightmare...
  - tptacek 5y ago
    You are in fact unlikely to ever have to upgrade the WireGuard protocol under any kind of duress. But ciphersuite negotiation has itself been a source of protocol vulnerabilities, and those are vulnerabilities you'll never have to think about with WireGuard.
  - whoknowswhat11 5y ago
    Not for larger enterprises - simply because this is how they ALREADY do things. You setup new thing on new place, and 5 years later hope you can turn off version 1. You would be surprised at how LITTLE updating and reconfiguring of systems that are working big enterprises want to do. And this is doubly so in the VPN space which is a mindfield already of troubleshooting when users call and complain (98% user error, but the 2% config / ip exhaustion or whatever bites you and so once folks have a working setup they really don't want to mess with it).
glotzerhotze 5y ago
The main selling point imho is the ability to build multi-node-mesh-networks super easily with something like tailscale on top of wireguard. I also think this is a total different use-case than the one you’d most likely find in the wild today: people looking to use a VPN for „privacy issues“
- repiret 5y ago
  I suspect privacy VPNs remain a minority use case, dwarfed by people connecting their home office computer to their corporate network.
  - t-3 5y ago
    The insane number of advertisements (TV, radio, internet) for different consumer "privacy" VPNs suggests otherwise. Nobody would waste money trying to sell VPN service if people weren't buying a lot of it.
    - repiret 5y ago
      I don’t consume enough broadcast media to comment there, but I certainly haven’t seen many privacy VPN ads online. And of course it doesn’t have to be popular to support a lot of ads - high margin would do that too.
chrisweekly 5y ago
I recently set up my NAS, phone, and 2 machines with Tailscale and am delighted with the results. I'm no networking guru, but have been doing web-related things for a living since 1998, and Tailscale is hands-down the most straightforward way I've ever encountered to connect my devices securely. Intuitive UX, WireGuard under the hood, highly recommended.
- mlac 5y ago
  Yeah - Tailscale came up a few weeks ago on here. I took 20 minutes to set up my entire home network (ok, maybe 30) - but got my pihole, windows server, phones, and everything else online in minutes. And then it has been reliable and stayed online. I can now easily RDP into my Windows Machine from my iPad from anywhere. I had set up OpenVPN and wireguard for home network use, but Tailscale blows it away. And it's free for limited use. Honestly I thought the last post about Tailscale was filled with people astroturfing there were so many positive comments. But yeah - it's good. Really good. And it "just works". And the custom DNS is also awesome for RDP'ing and ssh'ing to devices by name on the network (e.g. ssh user@MacBook) can just work from an iPad.
  - Spivak 5y ago
    I keep seeing Tailscale come up and I’m sure the UX is great but I’m not really sure I get the value-add compared to normal WireGuard on a cheap VPC. Like it took like 30 minutes to have a WG server and profiles for all my devices. Scanned a few QR codes and now all my devices can all mutually talk to one another. Sure it’s not fancy P2P with lots of NAT busting tricks but the upside is that it always works. And I don’t need a fancy privacy preserving relay because I’m the relay! Automating all that stuff I’m sure is worth the price of admission for large deployments but for personal stuff I don’t get it.
    - knownjorbist 5y ago
      Your setup implies hub-and-spoke, does it not? Tailscale on each device is a mesh network.
    - 5y ago
deleted 5y ago
[deleted]
gnufx 5y ago
End-user experience with "enterprise" VPNs (GlobalProtect currently) leaves me much more trusting of WireGuard and OpenSSH, despite the Enterprise thinking SSH is too insecure to use without the VPN. Early on, I looked at the GlobalProtect client we were supposed to use on GNU/Linux (x86 only, amongst other things). I found it linked a well-obsolete openssl (I don't recall the CVE count), and was even unlawful because it violated the openssl licence conditions. Then I see the CVEs on these things. People who use them find the proprietary clients keep breaking with no notice for no apparent reason. Openconnect has just worked through all that when I've had to use GP rather than WireGuard. (Openconnect also allowed me to use Cisco's corporate VPN to test the Linux-based stuff they tried to sell us and insisted I had to use an MS Windows machine to connect. Thank you OC maintainers!)
- amaccuish 5y ago
  OpenConnect is fantastic and even better is their server, OCServ. OCServ just needs a bit more of WireGuard's mobility.
aborsy 5y ago
With services such as Tailscale, you need to trust the authentication servers that they run. In principle, they could access your network. It’s a start up with limited resources. I worry about their AS getting compromised at some point. For that reason, I don’t feel comfortable using it, and rather use a basic Wireguard concentrator. Otherwise, it’s a great layer around Wireguard. The set up is very easy, keys are rotated automatically, SSO is a good idea, and NAT traversal is very good. They will probably benefit from more relays around the world. I heard they have recently provided an option for running your own AS. I am not sure how easy it is to run, secure and maintain that.
- barsonme 5y ago
  This is true for pretty much any VPN provider, though. Like, somebody could compromise your company and start forging OpenVPN client certificates.
  - gnufx 5y ago
    And we've noticed compromises of multiple "Enterprise VPNs" reported recently.
- gnufx 5y ago
  There's a free software self-hostable server called "Headscale" somewhere on Github (not that I've used it). I saw a comment somewhere that Tailscale approved of it. I wonder whether a smaller company of experts(?) whose business is focussed on this is any more vulnerable than an established one with huge resources.
j3th9n 5y ago
This comment thread is for people who don't think IPSec/IKEv2 is the worst invention on the planet and want to share life saving stories about it. This will inevitably be downvoted, but (almost) everytime I see IPSec/IKEv2 mentioned there's a bunch of people puking all over it. Of course, it has a lot of options and configurations and you can fu*k things up, you have to study it a bit, like a brain surgeon has to read some books and do some practice. But once done that, it is a beautiful piece of protocol, excuse my language. It's fast, stable, it auto-reconnects, not to mention MOBIKE, it is simply state-of-the-art. I guess not everybody can drive the Formula 1 car of the VPN protocols. ;-o
- kortilla 5y ago
  It’s like a dishwasher where most of the buttons cause it to not wash your dishes at all and some just break your dishes entirely. A VPN protocol shouldn’t be a kit of parts that might be able to make a secure tunnel. It should only be able to be used correctly.
  - j3th9n 5y ago
    IPSec/IKEv2 is not breaking anything, maybe it just won't setup a tunnel. Maybe a better analogy: We don't say the same thing about for example a piano: "it should only be able to be used correctly". You have to study and practice a bit before you can play a somewhat decent piece, without study no piano play. The same for IPSec/IKEv2, without study no tunnel. Every VPN protocol needs a bit of study, maybe some protocol a bit more than the other. We have a Dutch saying: "Als een boer niet kan zwemmen ligt het aan zijn zwembroek", which translates to something like: "If a farmer can't swim it's because of his swimming trunks". If you want out-of-the-box VPN solutions, you go to a VPN provider and download their apps. ;-o
    - chousuke 5y ago
      But there's no value in IPsec being like a piano. Continuing the analogue, nearly everyone would be playing the exact same handful of songs in the exact same way and if they don't, they're doing it wrong. Why on earth do you have to learn to play an instrument like that? You don't want core pieces of security technology to have room for creativity.
gerdesj 5y ago
VPNs are a funny old thing and it's great to see a new tool to add to the toolbox. IPSEC is quite hard to deal with. For starters you have to understand that IPSEC was designed quite a while back and not only to shuffle TCP/IP (or UDP/IP). Nor is bog standard IPSEC "routing" in the IP sense. Those Phase 2 thingies are "selectors" - they look for attributes in a packet (generally left and right IP subnets) and then take action. Those selectors could be SPX/IPX addresses instead or people's family names if that makes sense for the system. Now, your P1 is the auth bit. It can accept many (err several) mechanisms but in general its PSK or certs. Then there is the identification thing - you pass your ID (which can be "lol, anyone, I'm pretty!") P1: You say Hi and state your ID and if you get a response with an ID then you try to authenticate. You send your methods and they send theirs. You pick an intersection of your offering and theirs and give it a go. With luck you get it right and you now have a relationship between you and the other end. That relationship is called a Security Association (SA) P2: This is called the Security Policy (Database). Network packets are inspected by the IPSEC engine looking for certain characteristics. In general it is IP subnet pairs - it doesn't have to be - remember IPSEC had much bigger goals than just IP. You send data and the other end decrypts it. I have not really done IPSEC justice here because it is quite beautiful as a standard. It is quite complete and the vendors and implementations have really fucked up. It is understandable in some cases because encryption does have a cost. In the end IPSEC is still the most employed VPN standard and also the worst understood. Sad really.
dang 5y ago
Past related threads: Why Not WireGuard (2020) - https://news.ycombinator.com/item?id=28896351 https://news.ycombinator.com/item?id=28896351 - Oct 2021 (31 comments) Why not “Why not WireGuard?” - https://news.ycombinator.com/item?id=22955607 https://news.ycombinator.com/item?id=22955607 - April 2020 (41 comments) Why Not WireGuard - https://news.ycombinator.com/item?id=22591454 https://news.ycombinator.com/item?id=22591454 - March 2020 (123 comments)
locusm 5y ago
My Mikrotik RB5009 arrived last week to replace the very unreliable Ubiquiti UDM. RouterOS supports Wireguard so looking forward to trying it.
GekkePrutser 5y ago
Not a big fan of tailscale (where this article comes from). I love the idea of Mesh VPN. They are amazing and they also add a lot of security on local networks as well (by encrypting traffic even if devices are on the same physical network). But they take fully open-source WireGuard and make a closed service around it (the client apps are open source but the configuration servers that coordinate everything are not). And then in addition to requiring you to trust them, they also outsource authentication to yet another party (for personal accounts you can choose Google, Microsoft or Github (a.k.a. Microsoft)). So now you have to trust two parties. Note: For enterprise customers they provide support for a lot more IDPs but that doesn't really make sense for a personal user. For my VPN I'd really like to keep things fully self-hosted including the servers for security. I don't want to depend on others for privacy and security reasons. Any information they don't have can't be compromised there. Luckily there are others like Nebula and Tinc that do provide fully self-hosted options. And there's ZeroTier which provides it to some extent (though fully self-hosted is intentionally difficult). But Tailscale doesn't offer it at all. I wouldn't mind so much if they had built it all themselves (like ZeroTier for example) but this way it feels like they're hitchhiking on WireGuard's success while not sharing its values like providing a fully self-hosted option. I'm sure it's all above board legally but it doesn't feel very nice.
- akerl_ 5y ago
  https://news.ycombinator.com/item?id=22466122 https://news.ycombinator.com/item?id=22466122 Might be of note here.
- commoner 5y ago
  Relevant: Headscale, a FOSS implementation of the Tailscale control server - GitHub: https://github.com/juanfont/headscale https://github.com/juanfont/headscale - HN: https://news.ycombinator.com/item?id=28572013 https://news.ycombinator.com/item?id=28572013 The Tailscale mobile apps aren't currently compatible with Headscale unless you modify and compile them yourself. But, those clients are mostly open source,* and the open parts can be forked and republished. * The Android client is under the 3-clause BSD License: https://github.com/tailscale/tailscale-android/blob/main/LICENSE https://github.com/tailscale/tailscale-android/blob/main/LIC.... The iOS, macOS, and Windows clients use the code in the main tailscale repo (also 3-clause BSD) "but additionally include small GUI wrappers that are not open source": https://github.com/tailscale/tailscale https://github.com/tailscale/tailscale.
EricE 5y ago
I love wireguard. It's fast, easy to configure, set up and use. Pro tip - piVPN can be used to set up VM's to quickly create wireguard VPN servers too. It's not just good for raspberry Pi's :)
kesor 5y ago
Excellent point by point dissection of a FUD article that shouldn't have even appeared on the first page of HN like it did previously today.
jeppesen-io 5y ago
Curious to try wireguard with Pritunl - on my todo list
xmodem 5y ago
> The end-user does not have to worry about the complexity of the protocol. If that was an issue we would have definitely gone rid of SIP and H.323, FTP and other protocols that don’t cope well with NAT and are decades old. Well, to be fair, we probably SHOULD get rid of SIP and H.323
- vbezhenar 5y ago
  And FTP is already on its way out. Modern networking looks funny. UDP as a baseline protocol. Wireguard and HTTPS/3 are built over UDP. Custom protocols are built over HTTPS/3. I think that it's good and simple suite of protocols.

256 points by jitl 5y ago

This is ranking today because "Why Not WireGuard" ranked earlier, and the thread for that story is here: https://news.ycombinator.com/item?id=28896351 https://news.ycombinator.com/item?id=28896351

protoman3000 5y ago

We still can’t get WireGuard to work if the client uses the WiFi on our university campus. Does anybody have an idea how to overcome this?

saberd 5y ago
Are outgoing ports blocked by the university? Wireguard servers usually use port 5000. http://portquiz.net:5000/ http://portquiz.net:5000/
- iso1210 5y ago
  I run wireguard servers on many ports, including 53, 443 and 5-figure numbers. I don't think I've got 5000 anywhere though.
  - 5e92cb50239222b 5y ago
    Same. Not that it means much, but I've been seeing 51820 being used in all documentation, blog posts, etc. Probably just copypasting the original examples, e.g. https://www.wireguard.com/quickstart/ https://www.wireguard.com/quickstart/ https://www.wireguard.com/xplatform/ https://www.wireguard.com/xplatform/
    - chupasaurus 5y ago
      A month ago I dug through the history, the only trace to origin of using 51820/UDP I've found is that the number is hardcoded in one of the tests.
- jitl 5y ago
  Wow this Portquiz thing is great!
ThatGeoGuy 5y ago
There is a whole host of things this could be, but you may want to talk to your University IT and determine if they're doing any kind of port blocking, NAT blocking, etc. on the network. Many campus networks are fairly restricted, often for a variety of reasons. IPSec / OpenVPN may get a pass because they're known exceptions, whereas Wireguard is new enough I'd not be surprised if your campus didn't move fast enough to include it as an exception.
sagres 5y ago
What port is your Wireguard server listening on? It's most likely UDP/51820. Ask them to open UDP + port number.
cge 5y ago
If the wifi is eduroam, as many are now on university campuses, you should take a look at the service standards [1], especially page 32. While recommendations (on page 33) are only to block a minimum number of ports, if needed, in practice, I've found that some universities block all ports except those they are required to have open per eduroam policy. This includes blocking all UDP ports except 4500, 1194, and (outgoing only) 500. The trick of using common TCP ports won't work on these networks, as they open those only for TCP per policy, and often only outbound. On those networks, I've found using port 4500 for WireGuard works. This is a bit annoying, because the policy is clearly designed to ensure that VPNs work, it just isn't written to support WireGuard yet. [1]: https://www.eduroam.org/wp-content/uploads/2020/02/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf https://www.eduroam.org/wp-content/uploads/2020/02/GN3-12-19...
- jeroenhd 5y ago
  Funny, the eduroam universities I've been to never blocked any outgoing traffic based on port number alone. In fact, one of them essentially provides you with a world routable IP address, only blocking some incoming ports known for abuse such as 25 and 53. A port scan of the network is a reminder of how badly the world has been relying on NAT to provide security (which it doesn't even do in the real world) because people will just permanently disable their firewall and think nothing of it. Once you hit the wired network, all ports are free game, which is even worse! Luckily, these networks are scanned and honeypots/badly configured servers will get hit with a warning in hours to minutes. My solution for those restrictive networks is to pick common ports as well. Outgoing ports 53 and 443 work in most networks I've tried, even for UDP. Running a WireGuard server on port 53 means you can't run DNS from that server, and running a server from 443 means no HTTP/3 or QUIC. If the goal is to run a server from behind Eduroam then I think you'll be tough out of luck.
  - gnufx 5y ago
    I suspect there's a big variation, particularly in whether the university has placed the keys to the kingdom in the hands of a "partner" of, shall we say, dubious competence and understanding of academia, after getting rid of decades worth of local experience. Fortunately those with decades of experience outside Networks group can usually find an "impossible" way to work around notwork and other roadblocks, but it's so much wasted time.
trulyrandom 5y ago
You could try running Wireguard over port 443. Since HTTP/3 also uses UDP and port 443, it's possible that the university network doesn't block this.
jfoutz 5y ago
I have some tangential experience with a big sprawling old university network. It's a hard job. On the one hand, you need to protect academic freedom. Someone really is writing a paper about sexuality and needs access to crazy port sites. There's also the 90 year old advisor that never really understood email and why it's bad to click on every link. Reach out to a professor, and write up a paper proposal about practical deployment of wireguard. You should be able to get some access to university IT folks. Not like, help desk, but net engineers. Take notes, capture the details about why it's tricky, and how you solve it. You're not going to get into a journal for pure research, or anything super fancy like that. But if you put in the time, you'll get wireguard working and get a little credit on campus as not being clueless.
ngrilly 5y ago
We had the same issue. Setting the MTU to 1280, the IPv6 minimum MTU (we use IPv6), instead of using the default value, fixed the issue.

29athrowaway 5y ago

What I do not like about IPsec is that it has a lot of moving parts and opportunities for vulnerabilities.

jeroenhd 5y ago
That's exactly my problem as well. The other problem I have is the way proprietary manufacturers rely on the fact you can configure IPsec insecurely so that they never need to update their broken-on-arrival IPsec hardware and software to support modern, secure standards.

hikerclimber1 5y ago

Everything is subjective. Especially laws.

RedShift1 5y ago

> In this section, Tremer argues that IPsec is not very hard to use after all — in contradiction to the experiences of most readers — and points out that you only need to specify your own public IP address, the public IP of your peer, the subnets you want to make available for each side, and a pre-shared key. After that, the VPN “is compatible with every vendor out there.” > This is a surprising set of claims. First of all, that is not the only information needed to configure IPsec: critically, correct use of IPsec requires you to specify exactly which cipher suites you want to allow. This is an unanswerable question for anyone who is not a cryptography expert. The defaults are virtually never secure or cross-platform. This is so true. I once configured a Sonicwall and Cisco router and even though all encryption settings for both phase 1 and phase 2 were exactly the same, the tunnel refused to come up with negotiation errors. I had to change ciphers on both sides before it worked. Vendor incompatibility is an absolute pain with IPsec and IKE.

twistedpair 5y ago
+1. I've done cross cloud connects where the cloud vendors are on the phone with me and eventually say "We really don't have any idea why the tunnels are not connecting". And that's when using Cisco VPN appliances, no less, following everyone's setup instructions to the letter. Indeed, not a trivially solved problem yet.
- Spooky23 5y ago
  Sounds like a real shitshow all around. Building IPSec tunnels between ASAs isn’t rocket science. I would be worried about downstream issues with the security architecture, especially down the road when you pick up clients with compliance requirements.
  - chasil 5y ago
    ...and I quote, "3DES in combination with MD5 is a common candidate..." If a security architecture is a priority, then these people will not be customers. Triple DES is not "boring crypto" by any means. https://news.ycombinator.com/item?id=13383006 https://news.ycombinator.com/item?id=13383006 Wireguard's crypto is boring. That's the point.

deleted 5y ago

[deleted]

jeroenhd 5y ago

"The long-term option is to reconsider why you need that legacy VPN concentrator in the first place. WireGuard is open source, can run in a pure software virtual machine [...]" I think the answer to this is that companies prefer to buy "boxes" over running their own infrastructure. Sure, under the hood it's the exact same thing, but Cisco can market a nice grey box with a logo to your manager and you can't market a Linux kernel tool. Why buy a VPN concentrator when you can run OpenVPN or IPSec in a VM? Easy, because the VPN concentrator is plug and play after setup and you don't need to worry about those pesky updates (you should worry but updates are rarely provided anyway). From my point of view, WireGuard and IPsec/OpenVPN serve two entirely different markets. Wireguard is there for the companies running their own Linux infrastructure already, providing the tools for quick and dirty VPNs with no cost and barely any complexity. IPsec and to some extent OpenVPN is there for the companies thinking in boxes (the VPN box, the web server box, the Cisco box, the firewall box) who don't care about how the VPN works as long as they can pay someone else to make the box and as long as it works with their existing devices. Before WireGuard, most articles writing about the kind of thing WireGuard is good at would recommend setting up OpenVPN. And truth be told, OpenVPN is pretty good at this sort of thing, it's just complex to properly understand because of its complexity. IPsec is left over to the professionals, bridging offices together rather than making servers talk to each other securely. You can do a lot of what IPsec offers through WireGuard, but you can do everything WireGuard offers through IPsec. Whether your want to use that complexity or not is your own choice, but I don't think there's a real answer to be found here. Because of this I think many people are talking past each other without realizing it. "VPN" can mean many things to many people. To people watching a lot of Youtube, it's for pirating movies or watching foreign Netflix. For people working with legacy/prebuilt IT, it's how WFH is done together with some strange Cisco product. To Linux/OpenBSD engineers, it's just a network layer with many different applications. To corporate, it's the button you press to make the accounting report go brrrr when you're on the road. Arguments for one use case easily fall flat for all the others.

resonanttoe 5y ago
>I think the answer to this is that companies prefer to buy "boxes" over running their own infrastructure. Sure, under the hood it's the exact same thing, but Cisco can market a nice grey box with a logo to your manager and you can't market a Linux kernel tool. This is spot on. Companies prefer it because it comes with a support contract and defined SLAs.* The vast majority of companies that don't actively develop infra or software, aren't going to invest in support for OSS . (Think retail companies). They want to buy a solution and that means all of the solution, including support and who they can blame when it catastrophically fails.* *These may be meaningless most of the time if its a suitably complex problem. ** Also they may just not equipped to actually hire and build the infra in a meaningful way.*

nicolaslem 5y ago

I used to use IPFire (the Linux distribution for routers mentioned in the original article), since then I switched my router to plain Debian, allowing me to use Wireguard. This is so much simpler than fiddling with the VPN settings in the IPFire UI.

knorker 5y ago

> Someday, WireGuard will need to be upgraded to support a second cipher suite. When this happens, users will be able to configure it peer-by-peer to allow one cipher suite or the other, or both, exactly as they would with any other VPN. Is that accurate? I thought they explicitly said that this is not the case, that instead a V2 would still have just the one protocol? In any case it's a non-problem, as you simply migrate by setting up V2 on a different port, and migrate client by client.

alfiedotwtf 5y ago
I'd say better this that having "cipher agility" like with IPSec. During design of IPSec, someone was advocating for the "NULL cipher" which is essentially no-encription where the use case was "debugging". Tie in cipher agility with the NULL cypher, and you've got yourself an awesome downgrade attack
Shish2k 5y ago
“Set up a new service and migrate all your clients” sounds _worse_ than “update the centrally managed config for existing clients” though? I’m only dealing with double-digit numbers of devices, and this “non-problem” sounds like a nightmare...
- tptacek 5y ago
  You are in fact unlikely to ever have to upgrade the WireGuard protocol under any kind of duress. But ciphersuite negotiation has itself been a source of protocol vulnerabilities, and those are vulnerabilities you'll never have to think about with WireGuard.
- whoknowswhat11 5y ago
  Not for larger enterprises - simply because this is how they ALREADY do things. You setup new thing on new place, and 5 years later hope you can turn off version 1. You would be surprised at how LITTLE updating and reconfiguring of systems that are working big enterprises want to do. And this is doubly so in the VPN space which is a mindfield already of troubleshooting when users call and complain (98% user error, but the 2% config / ip exhaustion or whatever bites you and so once folks have a working setup they really don't want to mess with it).

glotzerhotze 5y ago

The main selling point imho is the ability to build multi-node-mesh-networks super easily with something like tailscale on top of wireguard. I also think this is a total different use-case than the one you’d most likely find in the wild today: people looking to use a VPN for „privacy issues“

repiret 5y ago
I suspect privacy VPNs remain a minority use case, dwarfed by people connecting their home office computer to their corporate network.
- t-3 5y ago
  The insane number of advertisements (TV, radio, internet) for different consumer "privacy" VPNs suggests otherwise. Nobody would waste money trying to sell VPN service if people weren't buying a lot of it.
  - repiret 5y ago
    I don’t consume enough broadcast media to comment there, but I certainly haven’t seen many privacy VPN ads online. And of course it doesn’t have to be popular to support a lot of ads - high margin would do that too.

chrisweekly 5y ago

I recently set up my NAS, phone, and 2 machines with Tailscale and am delighted with the results. I'm no networking guru, but have been doing web-related things for a living since 1998, and Tailscale is hands-down the most straightforward way I've ever encountered to connect my devices securely. Intuitive UX, WireGuard under the hood, highly recommended.

mlac 5y ago
Yeah - Tailscale came up a few weeks ago on here. I took 20 minutes to set up my entire home network (ok, maybe 30) - but got my pihole, windows server, phones, and everything else online in minutes. And then it has been reliable and stayed online. I can now easily RDP into my Windows Machine from my iPad from anywhere. I had set up OpenVPN and wireguard for home network use, but Tailscale blows it away. And it's free for limited use. Honestly I thought the last post about Tailscale was filled with people astroturfing there were so many positive comments. But yeah - it's good. Really good. And it "just works". And the custom DNS is also awesome for RDP'ing and ssh'ing to devices by name on the network (e.g. ssh user@MacBook) can just work from an iPad.
- Spivak 5y ago
  I keep seeing Tailscale come up and I’m sure the UX is great but I’m not really sure I get the value-add compared to normal WireGuard on a cheap VPC. Like it took like 30 minutes to have a WG server and profiles for all my devices. Scanned a few QR codes and now all my devices can all mutually talk to one another. Sure it’s not fancy P2P with lots of NAT busting tricks but the upside is that it always works. And I don’t need a fancy privacy preserving relay because I’m the relay! Automating all that stuff I’m sure is worth the price of admission for large deployments but for personal stuff I don’t get it.
  - knownjorbist 5y ago
    Your setup implies hub-and-spoke, does it not? Tailscale on each device is a mesh network.
  - 5y ago

deleted 5y ago

[deleted]

gnufx 5y ago

End-user experience with "enterprise" VPNs (GlobalProtect currently) leaves me much more trusting of WireGuard and OpenSSH, despite the Enterprise thinking SSH is too insecure to use without the VPN. Early on, I looked at the GlobalProtect client we were supposed to use on GNU/Linux (x86 only, amongst other things). I found it linked a well-obsolete openssl (I don't recall the CVE count), and was even unlawful because it violated the openssl licence conditions. Then I see the CVEs on these things. People who use them find the proprietary clients keep breaking with no notice for no apparent reason. Openconnect has just worked through all that when I've had to use GP rather than WireGuard. (Openconnect also allowed me to use Cisco's corporate VPN to test the Linux-based stuff they tried to sell us and insisted I had to use an MS Windows machine to connect. Thank you OC maintainers!)

amaccuish 5y ago
OpenConnect is fantastic and even better is their server, OCServ. OCServ just needs a bit more of WireGuard's mobility.

aborsy 5y ago

With services such as Tailscale, you need to trust the authentication servers that they run. In principle, they could access your network. It’s a start up with limited resources. I worry about their AS getting compromised at some point. For that reason, I don’t feel comfortable using it, and rather use a basic Wireguard concentrator. Otherwise, it’s a great layer around Wireguard. The set up is very easy, keys are rotated automatically, SSO is a good idea, and NAT traversal is very good. They will probably benefit from more relays around the world. I heard they have recently provided an option for running your own AS. I am not sure how easy it is to run, secure and maintain that.

barsonme 5y ago
This is true for pretty much any VPN provider, though. Like, somebody could compromise your company and start forging OpenVPN client certificates.
- gnufx 5y ago
  And we've noticed compromises of multiple "Enterprise VPNs" reported recently.
gnufx 5y ago
There's a free software self-hostable server called "Headscale" somewhere on Github (not that I've used it). I saw a comment somewhere that Tailscale approved of it. I wonder whether a smaller company of experts(?) whose business is focussed on this is any more vulnerable than an established one with huge resources.

j3th9n 5y ago

This comment thread is for people who don't think IPSec/IKEv2 is the worst invention on the planet and want to share life saving stories about it. This will inevitably be downvoted, but (almost) everytime I see IPSec/IKEv2 mentioned there's a bunch of people puking all over it. Of course, it has a lot of options and configurations and you can fu*k things up, you have to study it a bit, like a brain surgeon has to read some books and do some practice. But once done that, it is a beautiful piece of protocol, excuse my language. It's fast, stable, it auto-reconnects, not to mention MOBIKE, it is simply state-of-the-art. I guess not everybody can drive the Formula 1 car of the VPN protocols. ;-o

kortilla 5y ago
It’s like a dishwasher where most of the buttons cause it to not wash your dishes at all and some just break your dishes entirely. A VPN protocol shouldn’t be a kit of parts that might be able to make a secure tunnel. It should only be able to be used correctly.
- j3th9n 5y ago
  IPSec/IKEv2 is not breaking anything, maybe it just won't setup a tunnel. Maybe a better analogy: We don't say the same thing about for example a piano: "it should only be able to be used correctly". You have to study and practice a bit before you can play a somewhat decent piece, without study no piano play. The same for IPSec/IKEv2, without study no tunnel. Every VPN protocol needs a bit of study, maybe some protocol a bit more than the other. We have a Dutch saying: "Als een boer niet kan zwemmen ligt het aan zijn zwembroek", which translates to something like: "If a farmer can't swim it's because of his swimming trunks". If you want out-of-the-box VPN solutions, you go to a VPN provider and download their apps. ;-o
  - chousuke 5y ago
    But there's no value in IPsec being like a piano. Continuing the analogue, nearly everyone would be playing the exact same handful of songs in the exact same way and if they don't, they're doing it wrong. Why on earth do you have to learn to play an instrument like that? You don't want core pieces of security technology to have room for creativity.

gerdesj 5y ago

VPNs are a funny old thing and it's great to see a new tool to add to the toolbox. IPSEC is quite hard to deal with. For starters you have to understand that IPSEC was designed quite a while back and not only to shuffle TCP/IP (or UDP/IP). Nor is bog standard IPSEC "routing" in the IP sense. Those Phase 2 thingies are "selectors" - they look for attributes in a packet (generally left and right IP subnets) and then take action. Those selectors could be SPX/IPX addresses instead or people's family names if that makes sense for the system. Now, your P1 is the auth bit. It can accept many (err several) mechanisms but in general its PSK or certs. Then there is the identification thing - you pass your ID (which can be "lol, anyone, I'm pretty!") P1: You say Hi and state your ID and if you get a response with an ID then you try to authenticate. You send your methods and they send theirs. You pick an intersection of your offering and theirs and give it a go. With luck you get it right and you now have a relationship between you and the other end. That relationship is called a Security Association (SA) P2: This is called the Security Policy (Database). Network packets are inspected by the IPSEC engine looking for certain characteristics. In general it is IP subnet pairs - it doesn't have to be - remember IPSEC had much bigger goals than just IP. You send data and the other end decrypts it. I have not really done IPSEC justice here because it is quite beautiful as a standard. It is quite complete and the vendors and implementations have really fucked up. It is understandable in some cases because encryption does have a cost. In the end IPSEC is still the most employed VPN standard and also the worst understood. Sad really.

dang 5y ago

Past related threads: Why Not WireGuard (2020) - https://news.ycombinator.com/item?id=28896351 https://news.ycombinator.com/item?id=28896351 - Oct 2021 (31 comments) Why not “Why not WireGuard?” - https://news.ycombinator.com/item?id=22955607 https://news.ycombinator.com/item?id=22955607 - April 2020 (41 comments) Why Not WireGuard - https://news.ycombinator.com/item?id=22591454 https://news.ycombinator.com/item?id=22591454 - March 2020 (123 comments)

locusm 5y ago

My Mikrotik RB5009 arrived last week to replace the very unreliable Ubiquiti UDM. RouterOS supports Wireguard so looking forward to trying it.

GekkePrutser 5y ago

Not a big fan of tailscale (where this article comes from). I love the idea of Mesh VPN. They are amazing and they also add a lot of security on local networks as well (by encrypting traffic even if devices are on the same physical network). But they take fully open-source WireGuard and make a closed service around it (the client apps are open source but the configuration servers that coordinate everything are not). And then in addition to requiring you to trust them, they also outsource authentication to yet another party (for personal accounts you can choose Google, Microsoft or Github (a.k.a. Microsoft)). So now you have to trust two parties. Note: For enterprise customers they provide support for a lot more IDPs but that doesn't really make sense for a personal user. For my VPN I'd really like to keep things fully self-hosted including the servers for security. I don't want to depend on others for privacy and security reasons. Any information they don't have can't be compromised there. Luckily there are others like Nebula and Tinc that do provide fully self-hosted options. And there's ZeroTier which provides it to some extent (though fully self-hosted is intentionally difficult). But Tailscale doesn't offer it at all. I wouldn't mind so much if they had built it all themselves (like ZeroTier for example) but this way it feels like they're hitchhiking on WireGuard's success while not sharing its values like providing a fully self-hosted option. I'm sure it's all above board legally but it doesn't feel very nice.

akerl_ 5y ago
https://news.ycombinator.com/item?id=22466122 https://news.ycombinator.com/item?id=22466122 Might be of note here.
commoner 5y ago
Relevant: Headscale, a FOSS implementation of the Tailscale control server - GitHub: https://github.com/juanfont/headscale https://github.com/juanfont/headscale - HN: https://news.ycombinator.com/item?id=28572013 https://news.ycombinator.com/item?id=28572013 The Tailscale mobile apps aren't currently compatible with Headscale unless you modify and compile them yourself. But, those clients are mostly open source,* and the open parts can be forked and republished. * The Android client is under the 3-clause BSD License: https://github.com/tailscale/tailscale-android/blob/main/LICENSE https://github.com/tailscale/tailscale-android/blob/main/LIC.... The iOS, macOS, and Windows clients use the code in the main tailscale repo (also 3-clause BSD) "but additionally include small GUI wrappers that are not open source": https://github.com/tailscale/tailscale https://github.com/tailscale/tailscale.

EricE 5y ago

I love wireguard. It's fast, easy to configure, set up and use. Pro tip - piVPN can be used to set up VM's to quickly create wireguard VPN servers too. It's not just good for raspberry Pi's :)

kesor 5y ago

Excellent point by point dissection of a FUD article that shouldn't have even appeared on the first page of HN like it did previously today.

jeppesen-io 5y ago

Curious to try wireguard with Pritunl - on my todo list

xmodem 5y ago

> The end-user does not have to worry about the complexity of the protocol. If that was an issue we would have definitely gone rid of SIP and H.323, FTP and other protocols that don’t cope well with NAT and are decades old. Well, to be fair, we probably SHOULD get rid of SIP and H.323

vbezhenar 5y ago
And FTP is already on its way out. Modern networking looks funny. UDP as a baseline protocol. Wireguard and HTTPS/3 are built over UDP. Custom protocols are built over HTTPS/3. I think that it's good and simple suite of protocols.