[HN Gopher] Why not "Why not WireGuard?" (2020)
___________________________________________________________________
Why not "Why not WireGuard?" (2020)
Author : jitl
Score : 167 points
Date : 2021-10-17 17:05 UTC (5 hours ago)
(HTM) web link (tailscale.com)
(TXT) w3m dump (tailscale.com)
| hikerclimber1 wrote:
| Everything is subjective. Especially laws.
| RedShift1 wrote:
| > 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.
| chousuke wrote:
| What's also bad about IPsec is that most of its features are
| _useless_ in the vast majority of use cases. Some are probably
| even actively harmful to try to use. For example, it 's
| possible to use static encryption keys for a security
| association. That's not a good feature to have.
|
| If you just want to set up a secure tunnel connecting two
| networks over an untrusted network, probably 95% of what IPsec
| can do won't be of any help to you at all, and will actively
| hinder you because you have to find the exact combination of
| settings that works for whatever two endpoints you want to join
| together.
| [deleted]
| fmajid wrote:
| Absolutely. The only IPsec software I've seen that will not
| make you run away gibbering in terror as if you've seen Chtulu
| is OpenBSD's OpenIKEd, and while you can use it to make an
| IPsec VPN server for Apple iDevices without having to install
| third-party software, it doesn't play nice with other IPsec
| software because of the lack of mandated ciphers.
| mmarq wrote:
| Setting up a VPN on a PIX or on a Cisco router is so insanely
| complicated that there was an entire Cisco Academy course
| devoted only to that.
| twistedpair wrote:
| +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.
| user3939382 wrote:
| Had the same problem with Verizon Medium Business in 2015.
| Turns out there was basically one guy who knew the internals
| of the (required) IPSec VPN, he couldn't figure out why the
| tunnel wasn't working and I gave up and switched to another
| provider.
| Spooky23 wrote:
| 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 wrote:
| ...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
|
| Wireguard's crypto is boring. That's the point.
| Spooky23 wrote:
| Yeah that's a similar example of incompetent security or
| network engineering. (Or lack thereof)
| LaGrange wrote:
| I don't have a horse in this race, but this sounds like a
| Cisco problem.
| protoman3000 wrote:
| 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?
| trulyrandom wrote:
| 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 wrote:
| 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.
| saberd wrote:
| Are outgoing ports blocked by the university? Wireguard servers
| usually use port 5000. http://portquiz.net:5000/
| jitl wrote:
| Wow this Portquiz thing is great!
| iso1210 wrote:
| 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 wrote:
| 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/xplatform/
| chupasaurus wrote:
| 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.
| ThatGeoGuy wrote:
| 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 wrote:
| What port is your Wireguard server listening on? It's most
| likely UDP/51820. Ask them to open UDP + port number.
| ngrilly wrote:
| 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.
| cge wrote:
| 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-19...
| 5e92cb50239222b wrote:
| Why are they doing this at all? I don't think it's in the
| name of "security", if you can establish any VPN connection,
| you can easily exfiltrate any kind of traffic without anybody
| noticing.
| zamadatix wrote:
| In the name of security for the millions of BYOD devices
| that connect to eduroam. Only 0.1% may find inbound or
| strange ports useful but probably a double digit percentage
| of BYOD devices find unfiltered networks (particularly
| inbound or peer to peer communication) to result in massive
| continuous malware outbreaks.
| lazide wrote:
| Usually to protect the random unprotected machines on the
| local network (and the rest of the world from the poorly
| administered machines), in my experience.
|
| Some of it often boils down to mindset of the admin - allow
| everything unless you know it is a problem, or block
| everything unless you 'know' it is good.
| jeroenhd wrote:
| 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 wrote:
| 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.
| dang wrote:
| Past related threads:
|
| _Why Not WireGuard (2020)_ -
| https://news.ycombinator.com/item?id=28896351 - Oct 2021 (31
| comments)
|
| _Why not "Why not WireGuard?"_ -
| https://news.ycombinator.com/item?id=22955607 - April 2020 (41
| comments)
|
| _Why Not WireGuard_ -
| https://news.ycombinator.com/item?id=22591454 - March 2020 (123
| comments)
| [deleted]
| jeroenhd wrote:
| "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 wrote:
| >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.*
| knorker wrote:
| > 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 wrote:
| 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
| aborsy wrote:
| 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.
| gnufx wrote:
| 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.
| barsonme wrote:
| This is true for pretty much any VPN provider, though. Like,
| somebody could compromise your company and start forging
| OpenVPN client certificates.
| gnufx wrote:
| And we've noticed compromises of multiple "Enterprise VPNs"
| reported recently.
| nicolaslem wrote:
| 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.
| chrisweekly wrote:
| 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 wrote:
| 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.
| glotzerhotze wrote:
| 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 wrote:
| I suspect privacy VPNs remain a minority use case, dwarfed by
| people connecting their home office computer to their corporate
| network.
| tptacek wrote:
| 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
| j3th9n wrote:
| 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
| WesolyKubeczek wrote:
| I'm using IPSec for my homelab/roadwarrior setup, and that's
| explicitly because Linux, macOS, and iOS can all use it right
| out of the box without any "apps" to install.
|
| The only gripe I have is that StrongSwan is not a particularly
| easy piece of software to set up and debug when your tunnels
| suddenly go pear-shaped. I'd say they are a textbook example on
| how to screw things up when introducing a whole new set of
| daemons and configuration format, while a multi-year body of
| knowledge and corner cases exists only for the old format.
| kortilla wrote:
| 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 wrote:
| 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
| gerdesj wrote:
| 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.
| 29athrowaway wrote:
| What I do not like about IPsec is that it has a lot of moving
| parts and opportunities for vulnerabilities.
| jeroenhd wrote:
| 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.
| [deleted]
| gnufx wrote:
| 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 wrote:
| OpenConnect is fantastic and even better is their server,
| OCServ. OCServ just needs a bit more of WireGuard's mobility.
___________________________________________________________________
(page generated 2021-10-17 23:00 UTC)