26 ms·

Why Not WireGuard

brian_herman__ 7y ago
I know Wireguard is better but how do I get my work to use it instead of openvpn?
- battery_cowboy 7y ago
  Provide them a plan to transition to it that's bullet proof and wait until the current crisis is over (no one smart is making changes to their VPN right now while it's being overtaxed). You'll need the code to run it, the plan for authentication and authorization, documentation, testing, maintenance plans, training, rollout plans, fallback plans, etc.
- tjalfi 7y ago
  If it’s a large company, wait 5 to 10 years for the IETF to mangle the design and Cisco to add support for the botched protocol.
- kylek 7y ago
  I think one of the points the author is getting at is that there is a lack of (enterprise-level?) tooling around wireguard at the moment. Something that supports 2fa to connect would be nice, etc.
  - vxNsr 7y ago
    Yeah, the setup really needs to find a way to not require manually adding the actual private keys to each side to set it up.
    - jedberg 7y ago
      But that is precisely what makes it so easy and yet remain secure. When I add a new client, it takes just a minute to generate the keys and send over the QR code to the person via an already secure side channel, if we aren't already meeting face to face.
    - eadmund 7y ago
      You don't add the private keys to both sides: you add each node's private key and the other node's public key on each side.
  - 0xCMP 7y ago
    Tailscale seems to be trying to provide exactly this: https://tailscale.com/ https://tailscale.com/
  - rauhl 7y ago
    I wonder what two-factor would even look like for WireGuard. It’s a stateless protocol, so how often would you need to enter a second factor? How would you be prompted? Maybe that is working at the wrong level? Maybe it’s possible to build that feature atop WireGuard, without failing open (potentially catastrophic if you are using it as a VPN).
    - nightfly 7y ago
      We're considering that at my work for internal use. The easiest solution we can think of would be using something like an HTTPS API to 2FA to a server, ship a private key and other connection info out to the client, and require the client to check in regularly to keep their generated key enabled. So yeah, something to build on top of Wireguard.
      - tialaramex 7y ago
        When you start shipping private keys alarm bells ought to go off in your head. "The whole point of this cryptosystem I'm using is that these keys never go anywhere, but somehow I've persuaded myself that I need to move them over the network so I screwed up badly somewhere". This is the same in TLS setups (including OpenVPN) and in S/MIME (where it's a reminder that S/MIME probably is only delivering theatre and not any real security to your users).
        afiori 7y ago
        That could be changed by generating the key in the authenticated client.
- loeg 7y ago
  Depending on firewall egress policy, reverse tunnel home.
mrkurt 7y ago
(Disclosure: we use wireguard heavily at fly.io to handle backhaul between customer apps) The tldr of this seems to be "wireguard isn't as complicated as openvpn / ipsec infrastructure". Which is true. It's not, it has a much smaller scope.
Havoc 7y ago
>Obviously virtually every desktop/server CPU bought in the last couple of years has AES-NI. Except raspberry pis. Exactly the type of crowd attracted by simple home-rolled tunnels like wg
- jsight 7y ago
  How fast can it do with without native support? EDIT: Seems like >700 Mbps is possible with the pi4. Not bad, IMO: https://www.reddit.com/r/WireGuard/comments/d8k605/gigabit_wireguard_performance_on_sbcs/ https://www.reddit.com/r/WireGuard/comments/d8k605/gigabit_w...
  - Havoc 7y ago
    Yeah the rasp 4s are pretty insane. You can also use them as a router/firewall if you're sufficiently insane via a USB3 network adapter.
    - bestham 7y ago
      Or as a "one-armed router" with the use of a VLAN capable switch.
    - jsight 7y ago
      Honestly, I use a pi 3b as a router/firewall and it works pretty well for up to ~90 Mbs of traffic. That is just enough for me right now. Its an unexpected use case, but it is much more stable and flexible than a lot of "better" solutions.
      - Havoc 7y ago
        Managed 250 with a rasp4. Mostly because that was fiber line speed at the time. I suspect they can do 500ish
- fmajid 7y ago
  The author lives in a desktop-centric world and conveniently forgets the 10x more numerous mobile devices that do NOT have AES acceleration, and where ChaCha20-Poly1305 yields substantial battery life savings, which is why Google promotes it so widely for Android.
JumpCrisscross 7y ago
Frankly, my takeaway is that if one can use WireGuard, use it. If one can make small changes to use WireGuard, make those changes and use it. If one must use a feature only OpenVPN or IPSec provide, don't use WireGuard. That's a compelling pitch for WireGuard. (And VPNs as a whole.)
- edoo 7y ago
  At this point I'd only be using ovpn for tcp state caching which is amazing on poor mobile links. You can have your ovpn link resetting every 30 seconds and the tcp connections just continue like nothing happened, and I'd still use it on top of WireGuard.
microcolonel 7y ago
I think there are good points made here, but for the most part WireGuard is a massive upgrade compared to OpenVPN for most users, and I think it's set up really well for that use case (especially in a setting where you have control of the endpoints). There are other things for other use cases, I'm looking at glorytun [0] right now as a start. I particularly want the multipath stuff. Right now, it has the ability to do AEGIS where AES extensions are available, and fall back to ChaCha20-Poly1305. I personally think libsodium should look at adding a ChaCha12, and maybe ChaCha8, mode; 20 rounds seems pretty excessive, all things considered, and it has a considerable performance cost. By the way, given that the hardware would probably have dramatically more throughput and less complexity, I do wonder why CPU vendors aren't looking at ChaCha acceleration. It's not strictly necessary for timing attack reasons, since ChaCha doesn't really have these problems in software, but it seems to be better in every way than AES, given equal effort. RE: the multipath functionality is interesting to me, because I want to set up in some locations where directional radio could degrade in one direction or another, or maybe only satellite is available sometimes. I think probably the mad/glorytun multipath stuff is not that smart yet, but it's a start. [0]: https://github.com/angt/glorytun https://github.com/angt/glorytun
bscphil 7y ago
Several of the criticisms in this article seem fair, some less so to me, but this does really hit the problem on the head: > It is not very hard for me to conclude that WireGuard is not ready - yet. > It has been drafted as a lightweight and fast solution to some problems of the existing solutions. Unfortunately it has sacrificed many features that will be relevant for many users and therefore will not be able to replace IPsec and OpenVPN. > For that we need to add at least IP address assignment, pushing configuration like DNS servers and routes. This has certainly been the case for me. My use case for a VPN is a typical road warrior set-up. In my experience Wireguard seems like it's probably great for people who are accustomed to setting up custom VPN configurations already, and in fact probably simplifies the steps in doing so. But as someone who just needs a set-it-and-forget-it configuration to remote in and forward my connections that just consistently works, trying to get Wireguard working was hours of misery. There's enough tooling built around OpenVPN that you can generate a simple .ovpn configuration that just works and does everything you want in a few minutes. You don't need to be a professional network admin or have a lot of experience configuring VPNs. I hope Wireguard gets to that point because I really do believe in its technical superiority.
- vesinisa 7y ago
  I see WireGuard as a very promising VPN protocol. It should be easy to build e.g. higher level configuration protocols for DNS and such on top of it. WireGuard itself seems to adhere well to the Unix philosophy of doing just one thing and doing it really well. With OpenVPN you have all the bells and whistles, and it's easy to get tripped up in the myriad of configuration options. With WireGuard you start with the fundamentals: establishing the tunnel interface. Then you start adding routing, DNS etc. to suite your specific scenario.
  - bscphil 7y ago
    > I see WireGuard as a very promising VPN protocol. It should be easy to build e.g. higher level configuration protocols for DNS and such on top of it. You're 100% correct about this, but I think it's easy to miss that you could say very similar things about all sorts of very well designed, low-level technologies, that for years no one has bothered to build the necessary high level tooling around! Magic Wormhole is another great example: it's a brilliant system, it's even very easy to use from the terminal, but nobody has bothered to build a GUI around it or create any of the more complicated (but awesome!) tooling that the wormhole protocol allows. (At least as of the last time I looked into this.)
jchw 7y ago
There are two things that bug me: 1. The insistence that because complicated protocols are still in wide use, that complications are not a big deal. This is weird. Are we just not acknowledging all of the costs from complicated protocols? Look at TLS. 2. Focusing on a broken benchmark and encryption algorithms and coming to the conclusion that Wireguard is not faster seemingly with no actual testing. Well, maybe it somehow isn’t, but in my experience I get significantly better performance using WireGuard as a drop-in replacement for OpenVPN in a couple of circumstances, on top of better latency. I am no expert but I’d be willing to bet there is some truth to the performance claims. IPSec, of course, has its issues too, but that’s an entirely different story.
- gonzo 7y ago
  Wireguard will likely replace OpenVPN. But it won’t be faster than IPsec (basically the same framing overhead), and won’t be replacing IPsec.
  - kova12 7y ago
    I've been using wireguard lately on my phone and laptop. I can tell that it's leaps and bounds faster than openVPN in terms of pure network throughput but also in terms how fast it establishes a channel. With such performance it is a viable always-on VPN solution. In other words, it's a game changer. Regarding IPSEC: I have never been able to reliably configure and use IPSEC, and I'm in IT for several decades. Not that it can't be done, it's just too complex, so much so that it only makes sense for large companies to hire and train specialists who can do it. If wireguard offers similar throughput but eliminates complexity, I'd say it makes sense to replace IPSEC with it, if only to reduce complexity
    - fmajid 7y ago
      It’s much easier on the OpenBSD OpenIKEd (IKEv2) server that competes with theirs and that they denigrate, at least with iOS and macOS clients. Where WG wins massively over IPSec is in ease of configuration.
FDSGSG 7y ago
>Is WireGuard faster than other VPN solutions? >Simple answer: It isn't. It's really hard to not dismiss this guy as an utter clown when it's so obvious he's making these claims without even trying wireguard.
- wmf 7y ago
  The author seems to have enough experience with IPSec that people would dismiss his first-hand experience or benchmarks as biased anyway.
  - gonzo 7y ago
    > The author seems to have enough experience with IPSec that people would dismiss his first-hand experience or benchmarks as biased anyway. OK, if you want to claim bias... I own the company behind pfSense, and am sponsoring the work to put wireguard in the FreeBSD kernel (and will pay for the additional work to put this work in pfSense.) He's right, wireguard will be no faster than IPsec given equivalent encryption schemes (say, if IPsec were to use ChaCha20-Poly1305 for the bulk encryption) because the framing overheads are within a few bytes of each other. And if you're willing to compare AES-GCM to ChaCha20+Poly1305, then AES will, indeed, almost always be faster. The author makes note of the AES-NI instructions, and Wireguard's claim to be able to use the vector (AVX512) instructions, > The WireGuard whitepaper mentions due to AVX512, ChaCha20-Poly1305 will outperform AES-NI1, but that instruction set extension will only be available on large processors which again won't help with smaller and mobile hardware that will always be faster with AES-NI. However: 1) using the vector units from inside the kernel will involve a lot more overhead if anything else (say, in user land) is using the vector unit(s). Welcome to vector context switch overhead. Tons of huge registers to save and restore. 2) near future versions of AVX512 [https://eprint.iacr.org/2018/392.pdf https://eprint.iacr.org/2018/392.pdf] will support vector versions of the AES-NI (VAES) and PCLMULDQD (VPCLMULDQD) instructions. These have been timed at over 150Gbps. Yes, that's correct.
    - loeg 7y ago
      > 1) using the vector units from inside the kernel will involve a lot more overhead if anything else (say, in user land) is using the vector unit(s). Welcome to vector context switch overhead. Tons of huge registers to save and restore. FWIW, x86 AESNI instructions also operate on the XMM vector units. Doing AESNI in the kernel involves much of the same overhead as accelerated Chacha. (No comment on AVX512 and future directions — I'll take your word for that part.)
danielheath 7y ago
The "cypher upgrades are too hard" claim is ridiculous. Deploy a new endpoint on the new ciphers, update clients to use it, shut off the old one (optionally, limit its access initially then shut it off later).
eeZah7Ux 7y ago
> There is a sub-project called "wg-dynamic" which adds a user-space daemon to overcome this shortcoming. A massive design flaw because of the use-cases stated above, but it is even worse that IPv6 is all about dynamic addressing. "massive"? Citation needed. I never used a dynamic IP address on a server, for obvious security and reliability reasons.
eeZah7Ux 7y ago
> If you were to change the cipher you are using from one day to the next one, you would need to upgrade your WireGuard software on all those laptops, phones, etc. at the same time. That is literally impossible. Administrators who have tried this needed months to deploy configuration changes. Nonsense. That's what userspace tooling is for. You automatically deploy a new version with a new configuration file to use a new server. Over time, laptops & co migrate to it. Later on you revoke the previous version and shut down the server. It's done all the time.
cetra3 7y ago
WireGuard is very hard to manage with a pool of connected devices, especially if you don't know how many will connect ahead of time, it really needs Dynamic IPs, Routes & DNS to compete against OpenVPN. You should be able to add in hostname & credentials on the client end and let it do its magic. I also feel like the language used in wg-dynamic is very dismissive and counter productive: > WireGuard currently uses static addresses everywhere. This is because that is mostly a better way to design your network. But in some cases, insane people want dynamic IP addresses or other dynamic configuration. https://github.com/WireGuard/wg-dynamic/blob/master/docs/idea.md https://github.com/WireGuard/wg-dynamic/blob/master/docs/ide... So now I'm insane for not wanting to configure every connected client?
anderskaseorg 7y ago
“ChaCha20 is a stream cipher which are easier to implement in software. They encrypt one bit at a time. Block ciphers like AES encrypt a block of 128 bits at a time. That would need many more transistors when implemented in hardware, so larger processors come with AES-NI - an instruction set extension that performs some tasks of the encryption process to speed it up.” This entire paragraph is nonsense—that isn’t what a stream cipher means. ChaCha20 encrypts 512 bits at a time. The rest of that section goes on to describe how AES-NI is available everywhere except where it isn’t, and ChaCha20 can’t take advantage of hardware acceleration except where it can—then makes a blanket conclusion that AES will “outperform ChaCha20 in every single scenario” with all those exceptions conveniently ignored. (Are there correct, nuanced arguments to be made here one way or the other? Of course. But this article isn’t one of them.)
- ccktlmazeltov 7y ago
  The first paragraph makes no sense that's true, but what follows is a good point. AES-GCM is much much faster than ChaCha20-Poly1305. If: 1) your market is fragmented 2) many clients are cheap phones that don't support AES-NI 3) you can differentiate them so that you don't penalize better clients Then yeah it makes sense to use Chacha20-Poly1305 for some of these clients. But choosing Chacha20-Poly1305 over AES-GCM all the time doesn't, and I'm not sure why Wireguard does that (besides trying to be trendy).
  - cakoose 7y ago
    Sure, that's a fine argument to make. But the article says "I expect AES to outperform ChaCha20 in every single scenario", even when the very next sentence talks about a scenario where that's not true.
  - cyphar 7y ago
    It's to make the design simpler. If you only use one crypto algorithm there's no cipher suite negotiation in the protocol (and thus no downgrade attacks). And while AES-GCM is faster with AES-NI, ChaCha20-Poly1305 is constructed to avoid timing side-channels (so software implementations are automatically much safer by default).
abrookewood 7y ago
Slightly off topic, but does anyone know how you could configure user groups with Wireguard? So a common set of ACLs, permissions etc. It seems more geared towards a single user.
- lapinot 7y ago
  What do you mean by "user groups" and "ACL" in the context of VPN? In any case, the answer is most probably "write some firewall rules" (discriminating on the source IP, the ones you configured as allowed IPs in wireguard).
  - abrookewood 7y ago
    I was trying to work out whether I could replace a VPN server like OpenVPN or SoftEther with Wireguard. Both of those allow you to create multiple client/users that share a set of rules. E.g. roaming Developers can connect via VPN to this resource, but not that one. WireGuard looks to be a lot lower level and probably not well suited to that task.
    - chme 7y ago
      WireGuard is a protocol with some tools to setup basic connections. What you probably want is some way to manage Wireguard peers and network zones with firewall and routing rules.
wrs 7y ago
Wireguard is early, agreed, but I totally disagree with this attitude that “real world IPSec works fine”. When I have to set up an IPSec tunnel where at least one side is a vendor I haven’t already suffered through, I always allocate at least a full day to getting it to work. Perhaps it’s because I’ve chosen obscure fly-by-night vendors like Cisco, VMWare, Microsoft, and Google. Or...maybe IPSec, in theory and practice, is a nightmare of unnecessary complexity that should be killed with fire.
- 1_person 7y ago
  A substantial fraction of the complexity of IPsec actually is the fault of the various vendors and implementations -- and is technically the complexity of IKE rather than IPsec in most cases. It's actually quite simple under the hood and frankly can't be made much simpler while still achieving the security objectives. The often wildly overcomplicated configuration syntax together with subtle differences in implementation defaults, cipher and parameter naming are what I see creating challenges for vendor interoperability.
  - wrs 7y ago
    The distinction between IKE and IPsec is the last thing on my mind when I’m in the fourth hour of debugging a connection. :) The existence of all the configuration options is the underlying problem. Well, the wealth of options plus the near-universal behavior when you have a mismatched configuration: either a vague yet misleading error message or just a silent refusal to work. Combine that with arbitrary vendor restrictions on that wealth of options and it’s just a guaranteed waste of time, E.g., neither GCP nor VMWare VeloCloud let you configure key lifetimes, so they can never connect to each other. Aside from the vendor stupidity, that’s a protocol problem: how does refusing to connect when the two sides disagree on key lifetime help security?
    - 1_person 7y ago
      Permitting key lifetime to disagree can allow an attacker to manipulate key lifetime, which could defeat perfect forward secrecy if the key lifetime is manipulated towards infinity or used to gather data for a known plaintext attack if the key lifetime is manipulated towards 0. Replay attacks also come to mind.
Mister_Snuggles 7y ago
I've been looking at WireGuard on and off but so far I'm sticking with IPSec. I currently have two use cases: 1) A road-warrior setup for iOS and MacOS devices with connect-on-demand if needed. Authentication is done using user certificates issued by an internal CA. This gives me secure access to check my security cameras, etc, and makes it completely frictionless. 2) A persistent tunnel to a cloud provider's network. The cloud provider only supports IPSec, so WireGuard isn't even an option here. This is mainly just homelab-type playing around, not serious work. I think WireGuard can do the first use case, but without centralized control over what routes, split tunnels, DNS, IP address assignments, etc, are pushed to the clients. I'd have to manage deploying all of this to the clients by hand instead of letting StrongSwan do it for me. On the IPSec side, setting everything up was a huge amount of effort. My first use case probably took a total of a day and a half (over the course of a couple of years as the solution changed and evolved) to get it into its current state. I'm not including getting the PKI stuff figured out since I wanted that for other stuff anyway. The second use case took me about three days to get set up satisfactorily. Most of this is because I can't see the logs on the cloud provider side, so debugging it is a matter of waiting, sometimes for six hours, for the tunnel to stop passing traffic, followed by tweaking settings based on what the error might be, and repeating. IPSec's complexity[0] really works against it here. I expect that WireGuard would be significantly easier for this use case if the cloud provider supported it. [0] https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection https://wiki.strongswan.org/projects/strongswan/wiki/ConnSec... - I've been staring at this page way too much lately.
geofft 7y ago
> Imagine you have a VPN server with 200 road warrior clients somewhere out there in the world - which is a very normal use-case. If you were to change the cipher you are using from one day to the next one, you would need to upgrade your WireGuard software on all those laptops, phones, etc. at the same time. That is literally impossible. Administrators who have tried this needed months to deploy configuration changes. Sometimes even middle-sized companies need years to conduce a process like this. In a world where Mario Kart Tour can get millions of people on all sorts of smartphones to update within a day of release, there is no actual reason why anyone else should be unable to. All of these businesses have painted themselves into a corner - they've said that they don't care about being able to update software within a year, and they've built processes around that, and now they whine that they can't update software within a year. Tough. Design things from day one with the assumption that updates will happen. Then you can patch software vulnerabilities in a timely fashion and not get attacked via well-known VPN software flaws like Travelex did. If you genuinely care about your business, you'll already want to figure this out. (Which is the other problem with this article: "secure" isn't really about cryptographic algorithms, these days. There are tons of good cryptographic algorithms. Just don't use the bad ones. "Secure" is about whether you're using them right, whether you've got memory safety vulnerabilities, whether you've got logic flaws, etc. Every piece of complexity in your software - including cryptographic agility - imperils "secure," and the best defense is being able to confidently apply patches to your software wherever it's being run.)
- laktak 7y ago
  You can also setup the new version as a new instance on a different port and run them in parallel.
jcrawfordor 7y ago
The article is obviously a promotional piece for ipfire and so exists to promote a certain angle on the topic. Even understanding this, though, it's strikes me as pretty questionable. The section discussing dynamic IP addresses seems to be based on a misunderstanding of Wireguard. The IP addresses that must be statically established in Wireguard are the addresses used inside of the tunnel, and are independent of the public (internet) IPs of the machines involved. The wg-dynamic daemon mentioned is a system for dynamically allocating IP addresses in the tunnel, and has so far not been completed, at least in part because it's not very obvious why you would want to do this (although in general the development of an in-band configuration standard for Wireguard has useful implications). Wireguard allows you to identify the endpoint using a DNS name, which means you can handle a 'server' with a dynamic IP address by dynamically updating the DNS record - a common approach that is no doubt exactly what ipfire supports doing for ipsec. In the end, though, the article just suffers from being an apples-to-oranges comparison. Wireguard is a VPN tunnel protocol implementation, ipfire is some sort of GUI frontend for managing a bunch of network tools. Of course ipfire has quite a few more features than wireguard.
- tssva 7y ago
  Although the article is confused regarding dynamic IP addresses your solution of identifying the endpoint using a DNS name is also not a complete solution when using Wireguard. The Wireguard tool, wg, resolves the DNS name and then sets the ip address for the endpoint which the wireguard protocol implementation then uses. Since the wireguard protocol implementation doesn't do any DNS resolution if the endpoint address changes even if the DNS record is updated wireguard will never know. Instead another tool needs to check the DNS record of the endpoint periodically either at some fixed interval and/or based upon the TTL of the DNS record. If the record changes it then needs to update the configuration of the wireguard protocol implementation.
  - cyphar 7y ago
    This is not always required. WireGuard peers can roam freely very similarly to Mosh (if one peer receives an authenticated message from one of its peers from a different IP address, it will update the gateway of that peer and will send all subsequent packets to that IP address). But to be fair, this doesn't work perfectly (especially if you have certain firewall rules that block UDP packets if they're not part of the what the firewall thinks is the same "connection", if both peers change their IP at the same time, or if the peer whose IP changed was rebooted or reconfigured before the other peer received a packet from its new IP addreds) but it really does work surprisingly well. For those (important) corner-cases, I would imagine that higher-level tooling such as NetworkManager would do the DNS checks you're talking about.
notlukesky 7y ago
Does anyone have a breakdown of the different open source licenses for the other projects apart from the kernel? from wireguard.com License The kernel components are released under the GPLv2, as is the Linux kernel itself. Other projects are licensed under MIT, BSD, Apache 2.0, or GPL, depending on context.
dispose256 7y ago
Well, I can see that I am outgunned as far as advanced networking knowledge goes. I would just like to say that I did a head to head comparison between openvpn and wireguard using the same hardware, server and client endpoints. Connection from Montreal to Amsterdam. Result was that something like this: novpn=100% wireguard=95% speed, openvpn=25% speed. Enough to convince me that for my use case (simple, steady point to point) wireguard is very much the superior option.
api 7y ago
Most of this is silly, but there is one correct point: large enterprises will never use WG unless we can get NIST to approve ChaCha and C25519 under FIPS. Yes it's mostly bullshit. No it won't ever change. FIPS is a check box and its all about liability and things like insurance. It has zero to do with tech and everything to do with standards and bureaucratic and legal requirements. Nobody ever got fired for using FIPS approved stuff. Use something different like WG and it (and you) will be blamed for any breach. Note that I'm not sure to what extent this is true in Europe, but there you have another problem. In my experience European industry is just culturally super conservative and does not like to adopt new things. So even if they don't have the FIPS boat anchor, they're just terribly change-averse.
teekert 7y ago
Hmm, I really wonder what mess he is talking about: "and here we are in the middle of this mess." It takes an experienced sysadmin a whole 20 min of his life to install the program, play with it and judge it (I guess, it took me a whole evening before I understood that the client needed its own config which can be created on the server, it's nice that you can then just scan a QR code with your phone though to configure it). Or even less when he talks to colleagues. This whole sentence immediately puts me off. I'm just a home server guy, no vpn experience. Messed with WireGuard for a night and left it installed. Have been using it ever since with no issues. How did I get in the middle of this mess?
adam0c 7y ago
paid advertising?
hhamalai 7y ago
Blah, WireGuard ain't necessarily superior by technical means, but being open source & easy to use solution, its efforts are crucial for the secure communications sector to go forward. All this FUD is just telling there is a strong need for tools like WireGuard.
mikl 7y ago
This is an excellent example of motivated reasoning. The author wants to keep selling his IPSec tool and thus throws together a word salad loaded with conjecture and theoretical concerns. It appears he’s not even tried WireGuard. The argument that it does not work for road warriors is a misunderstanding of where static IPs are required (inside the tunnel, not outside). As one who has tried WireGuard, I’m happy to say it can already replace OpenVPN and IPSec for the 80% case. And not only that, it is in practical experience much easier to install and set up, and much faster to connect and has excellent latency and bandwidth. It is great for road warriors, I’ve been using it for that purpose for six months or so and have never had any problems with it. Sure, there are some VPN features WG will not implement, for those you’ll have to stick with legacy VPNs like IPSec or OpenVPN. The rest is just FUD.
- larschdk 7y ago
  Static IP addressing inside the tunnel is still a major pain point for significant use-cases, e.g. company-wide VPN access for all employees. How do you do static addressing for 200+ people with their own devices?
  - kemotep 7y ago
    You provision them. How do you create user accounts for 200+ people? These end users likely do not already have wireguard on their devices so as part of the software rollout you assign them an ip. A /24 gives you enough addresses for over 200 people and a /8 future proofs you for a much larger company size. You can also just spin up different wireguard networks for different departments or even think about using IPV6. This is the same for any large rollout of technology really. There may be some hands on effort but nothing that couldn't be automated with a spreadsheet and a script.
- puzzlingcaptcha 7y ago
  >and much faster to connect and has excellent latency and bandwidth I have my own ipsec deployment and this argument always seems shaky to me. Here is how long it takes to establish ipsec connection on my laptop: https://streamable.com/27des https://streamable.com/27des The cipher suite used is aes256gcm16-prfsha384-ecp384 for IKE and aes256gcm16-ecp384 for ESP which is in line with CNSA https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa... I'm using Strongswan which I highly recommend mostly due to their comprehensive set of tests for virtually every scenario https://www.strongswan.org/testing/testresults/ https://www.strongswan.org/testing/testresults/ I did not see any meaningful difference in bandwidth between ipsec and wireguard. As a bonus, ipsec is natively supported by Windows 10. I don't use OpenVPN which I think is worse in that regard due to packet shuffling between the kernel and userspace but between ipsec and wireshark the only discernible difference for me is the effort in setting it up.
alanfranz 7y ago
There seems to be a misunderstanding of what "cryptographic agility" is, as well. Usually cryptographic agility means the ability to mix-and-match different protocols/options, e.g. use a certain key exchange algorithm with a certain symmetric encryption algorithm and/or MAC/HMAC; keysize, handshakes, options, things - everything can be negotiated by different clients, and sometimes a bad option (or a bad combination of options) can be negotiated. If you've got five key exchange algorithms, ten encryption algorithms with different key and block sizes, and ten MAC/HMAC algorithms - I'll let you calculate how many possible outcomes are there. Without cryptographic agility, this is not possible. In TLS, you would have a very specific key exchange algorithm with a very specific encryption and auth algorithm. But this does not mean that versioning is not supported. When some primitive is too old, a V2 API (again with a precise algorithm combination) can be created, and clients and servers can keep using both V1 and V2 for some time.
WhyNotHugo 7y ago
It's hard to see how you can focus on security _and_ implement something as a kernel module. A kernel module give it the highest amount of privileges it can have. Meanwhile, we all know of the "principle of least privilege". Not to mention any potential bugs can kill the entire system. While a kernel module may have some performance gains, I'm sceptical about the trade-offs here. And I definitely don't think "VPN" falls into what we usually think a kernel should be responsible for.
- floatboth 7y ago
  The kernel part is tiny. AFAIK, this is just like Netflix's KTLS — configuration stuff and handshakes are in userspace, only the bulk transport crypto is in kernel.
j0057 7y ago
Having to update all clients at the same time when deploying a Wireguard with different ciphers is solvable with just deploying another Wireguard server alongside the new one, right? I mean it's debatable whether one likes this approach better than more complex cipher negotiation protocols -- clearly these things should not be thought about in absolutes or "best practices", but as tradeoffs with different pros and cons. Wireguard seems to prioritize protocol complexity above upgradeability, that's not to say one is better than the other.

I know Wireguard is better but how do I get my work to use it instead of openvpn?

battery_cowboy 7y ago
Provide them a plan to transition to it that's bullet proof and wait until the current crisis is over (no one smart is making changes to their VPN right now while it's being overtaxed). You'll need the code to run it, the plan for authentication and authorization, documentation, testing, maintenance plans, training, rollout plans, fallback plans, etc.
tjalfi 7y ago
If it’s a large company, wait 5 to 10 years for the IETF to mangle the design and Cisco to add support for the botched protocol.
kylek 7y ago
I think one of the points the author is getting at is that there is a lack of (enterprise-level?) tooling around wireguard at the moment. Something that supports 2fa to connect would be nice, etc.
- vxNsr 7y ago
  Yeah, the setup really needs to find a way to not require manually adding the actual private keys to each side to set it up.
  - jedberg 7y ago
    But that is precisely what makes it so easy and yet remain secure. When I add a new client, it takes just a minute to generate the keys and send over the QR code to the person via an already secure side channel, if we aren't already meeting face to face.
  - eadmund 7y ago
    You don't add the private keys to both sides: you add each node's private key and the other node's public key on each side.
- 0xCMP 7y ago
  Tailscale seems to be trying to provide exactly this: https://tailscale.com/ https://tailscale.com/
- rauhl 7y ago
  I wonder what two-factor would even look like for WireGuard. It’s a stateless protocol, so how often would you need to enter a second factor? How would you be prompted? Maybe that is working at the wrong level? Maybe it’s possible to build that feature atop WireGuard, without failing open (potentially catastrophic if you are using it as a VPN).
  - nightfly 7y ago
    We're considering that at my work for internal use. The easiest solution we can think of would be using something like an HTTPS API to 2FA to a server, ship a private key and other connection info out to the client, and require the client to check in regularly to keep their generated key enabled. So yeah, something to build on top of Wireguard.
    - tialaramex 7y ago
      When you start shipping private keys alarm bells ought to go off in your head. "The whole point of this cryptosystem I'm using is that these keys never go anywhere, but somehow I've persuaded myself that I need to move them over the network so I screwed up badly somewhere". This is the same in TLS setups (including OpenVPN) and in S/MIME (where it's a reminder that S/MIME probably is only delivering theatre and not any real security to your users).
      - afiori 7y ago
        That could be changed by generating the key in the authenticated client.
loeg 7y ago
Depending on firewall egress policy, reverse tunnel home.

(Disclosure: we use wireguard heavily at fly.io to handle backhaul between customer apps) The tldr of this seems to be "wireguard isn't as complicated as openvpn / ipsec infrastructure". Which is true. It's not, it has a much smaller scope.

Havoc 7y ago

>Obviously virtually every desktop/server CPU bought in the last couple of years has AES-NI. Except raspberry pis. Exactly the type of crowd attracted by simple home-rolled tunnels like wg

jsight 7y ago
How fast can it do with without native support? EDIT: Seems like >700 Mbps is possible with the pi4. Not bad, IMO: https://www.reddit.com/r/WireGuard/comments/d8k605/gigabit_wireguard_performance_on_sbcs/ https://www.reddit.com/r/WireGuard/comments/d8k605/gigabit_w...
- Havoc 7y ago
  Yeah the rasp 4s are pretty insane. You can also use them as a router/firewall if you're sufficiently insane via a USB3 network adapter.
  - bestham 7y ago
    Or as a "one-armed router" with the use of a VLAN capable switch.
  - jsight 7y ago
    Honestly, I use a pi 3b as a router/firewall and it works pretty well for up to ~90 Mbs of traffic. That is just enough for me right now. Its an unexpected use case, but it is much more stable and flexible than a lot of "better" solutions.
    - Havoc 7y ago
      Managed 250 with a rasp4. Mostly because that was fiber line speed at the time. I suspect they can do 500ish
fmajid 7y ago
The author lives in a desktop-centric world and conveniently forgets the 10x more numerous mobile devices that do NOT have AES acceleration, and where ChaCha20-Poly1305 yields substantial battery life savings, which is why Google promotes it so widely for Android.

JumpCrisscross 7y ago

Frankly, my takeaway is that if one can use WireGuard, use it. If one can make small changes to use WireGuard, make those changes and use it. If one must use a feature only OpenVPN or IPSec provide, don't use WireGuard. That's a compelling pitch for WireGuard. (And VPNs as a whole.)

edoo 7y ago
At this point I'd only be using ovpn for tcp state caching which is amazing on poor mobile links. You can have your ovpn link resetting every 30 seconds and the tcp connections just continue like nothing happened, and I'd still use it on top of WireGuard.

microcolonel 7y ago

I think there are good points made here, but for the most part WireGuard is a massive upgrade compared to OpenVPN for most users, and I think it's set up really well for that use case (especially in a setting where you have control of the endpoints). There are other things for other use cases, I'm looking at glorytun [0] right now as a start. I particularly want the multipath stuff. Right now, it has the ability to do AEGIS where AES extensions are available, and fall back to ChaCha20-Poly1305. I personally think libsodium should look at adding a ChaCha12, and maybe ChaCha8, mode; 20 rounds seems pretty excessive, all things considered, and it has a considerable performance cost. By the way, given that the hardware would probably have dramatically more throughput and less complexity, I do wonder why CPU vendors aren't looking at ChaCha acceleration. It's not strictly necessary for timing attack reasons, since ChaCha doesn't really have these problems in software, but it seems to be better in every way than AES, given equal effort. RE: the multipath functionality is interesting to me, because I want to set up in some locations where directional radio could degrade in one direction or another, or maybe only satellite is available sometimes. I think probably the mad/glorytun multipath stuff is not that smart yet, but it's a start. [0]: https://github.com/angt/glorytun https://github.com/angt/glorytun

bscphil 7y ago

Several of the criticisms in this article seem fair, some less so to me, but this does really hit the problem on the head: > It is not very hard for me to conclude that WireGuard is not ready - yet. > It has been drafted as a lightweight and fast solution to some problems of the existing solutions. Unfortunately it has sacrificed many features that will be relevant for many users and therefore will not be able to replace IPsec and OpenVPN. > For that we need to add at least IP address assignment, pushing configuration like DNS servers and routes. This has certainly been the case for me. My use case for a VPN is a typical road warrior set-up. In my experience Wireguard seems like it's probably great for people who are accustomed to setting up custom VPN configurations already, and in fact probably simplifies the steps in doing so. But as someone who just needs a set-it-and-forget-it configuration to remote in and forward my connections that just consistently works, trying to get Wireguard working was hours of misery. There's enough tooling built around OpenVPN that you can generate a simple .ovpn configuration that just works and does everything you want in a few minutes. You don't need to be a professional network admin or have a lot of experience configuring VPNs. I hope Wireguard gets to that point because I really do believe in its technical superiority.

vesinisa 7y ago
I see WireGuard as a very promising VPN protocol. It should be easy to build e.g. higher level configuration protocols for DNS and such on top of it. WireGuard itself seems to adhere well to the Unix philosophy of doing just one thing and doing it really well. With OpenVPN you have all the bells and whistles, and it's easy to get tripped up in the myriad of configuration options. With WireGuard you start with the fundamentals: establishing the tunnel interface. Then you start adding routing, DNS etc. to suite your specific scenario.
- bscphil 7y ago
  > I see WireGuard as a very promising VPN protocol. It should be easy to build e.g. higher level configuration protocols for DNS and such on top of it. You're 100% correct about this, but I think it's easy to miss that you could say very similar things about all sorts of very well designed, low-level technologies, that for years no one has bothered to build the necessary high level tooling around! Magic Wormhole is another great example: it's a brilliant system, it's even very easy to use from the terminal, but nobody has bothered to build a GUI around it or create any of the more complicated (but awesome!) tooling that the wormhole protocol allows. (At least as of the last time I looked into this.)

jchw 7y ago

There are two things that bug me: 1. The insistence that because complicated protocols are still in wide use, that complications are not a big deal. This is weird. Are we just not acknowledging all of the costs from complicated protocols? Look at TLS. 2. Focusing on a broken benchmark and encryption algorithms and coming to the conclusion that Wireguard is not faster seemingly with no actual testing. Well, maybe it somehow isn’t, but in my experience I get significantly better performance using WireGuard as a drop-in replacement for OpenVPN in a couple of circumstances, on top of better latency. I am no expert but I’d be willing to bet there is some truth to the performance claims. IPSec, of course, has its issues too, but that’s an entirely different story.

gonzo 7y ago
Wireguard will likely replace OpenVPN. But it won’t be faster than IPsec (basically the same framing overhead), and won’t be replacing IPsec.
- kova12 7y ago
  I've been using wireguard lately on my phone and laptop. I can tell that it's leaps and bounds faster than openVPN in terms of pure network throughput but also in terms how fast it establishes a channel. With such performance it is a viable always-on VPN solution. In other words, it's a game changer. Regarding IPSEC: I have never been able to reliably configure and use IPSEC, and I'm in IT for several decades. Not that it can't be done, it's just too complex, so much so that it only makes sense for large companies to hire and train specialists who can do it. If wireguard offers similar throughput but eliminates complexity, I'd say it makes sense to replace IPSEC with it, if only to reduce complexity
  - fmajid 7y ago
    It’s much easier on the OpenBSD OpenIKEd (IKEv2) server that competes with theirs and that they denigrate, at least with iOS and macOS clients. Where WG wins massively over IPSec is in ease of configuration.

FDSGSG 7y ago

>Is WireGuard faster than other VPN solutions? >Simple answer: It isn't. It's really hard to not dismiss this guy as an utter clown when it's so obvious he's making these claims without even trying wireguard.

wmf 7y ago
The author seems to have enough experience with IPSec that people would dismiss his first-hand experience or benchmarks as biased anyway.
- gonzo 7y ago
  > The author seems to have enough experience with IPSec that people would dismiss his first-hand experience or benchmarks as biased anyway. OK, if you want to claim bias... I own the company behind pfSense, and am sponsoring the work to put wireguard in the FreeBSD kernel (and will pay for the additional work to put this work in pfSense.) He's right, wireguard will be no faster than IPsec given equivalent encryption schemes (say, if IPsec were to use ChaCha20-Poly1305 for the bulk encryption) because the framing overheads are within a few bytes of each other. And if you're willing to compare AES-GCM to ChaCha20+Poly1305, then AES will, indeed, almost always be faster. The author makes note of the AES-NI instructions, and Wireguard's claim to be able to use the vector (AVX512) instructions, > The WireGuard whitepaper mentions due to AVX512, ChaCha20-Poly1305 will outperform AES-NI1, but that instruction set extension will only be available on large processors which again won't help with smaller and mobile hardware that will always be faster with AES-NI. However: 1) using the vector units from inside the kernel will involve a lot more overhead if anything else (say, in user land) is using the vector unit(s). Welcome to vector context switch overhead. Tons of huge registers to save and restore. 2) near future versions of AVX512 [https://eprint.iacr.org/2018/392.pdf https://eprint.iacr.org/2018/392.pdf] will support vector versions of the AES-NI (VAES) and PCLMULDQD (VPCLMULDQD) instructions. These have been timed at over 150Gbps. Yes, that's correct.
  - loeg 7y ago
    > 1) using the vector units from inside the kernel will involve a lot more overhead if anything else (say, in user land) is using the vector unit(s). Welcome to vector context switch overhead. Tons of huge registers to save and restore. FWIW, x86 AESNI instructions also operate on the XMM vector units. Doing AESNI in the kernel involves much of the same overhead as accelerated Chacha. (No comment on AVX512 and future directions — I'll take your word for that part.)

danielheath 7y ago

The "cypher upgrades are too hard" claim is ridiculous. Deploy a new endpoint on the new ciphers, update clients to use it, shut off the old one (optionally, limit its access initially then shut it off later).

eeZah7Ux 7y ago

> There is a sub-project called "wg-dynamic" which adds a user-space daemon to overcome this shortcoming. A massive design flaw because of the use-cases stated above, but it is even worse that IPv6 is all about dynamic addressing. "massive"? Citation needed. I never used a dynamic IP address on a server, for obvious security and reliability reasons.

eeZah7Ux 7y ago

> If you were to change the cipher you are using from one day to the next one, you would need to upgrade your WireGuard software on all those laptops, phones, etc. at the same time. That is literally impossible. Administrators who have tried this needed months to deploy configuration changes. Nonsense. That's what userspace tooling is for. You automatically deploy a new version with a new configuration file to use a new server. Over time, laptops & co migrate to it. Later on you revoke the previous version and shut down the server. It's done all the time.

cetra3 7y ago

WireGuard is very hard to manage with a pool of connected devices, especially if you don't know how many will connect ahead of time, it really needs Dynamic IPs, Routes & DNS to compete against OpenVPN. You should be able to add in hostname & credentials on the client end and let it do its magic. I also feel like the language used in wg-dynamic is very dismissive and counter productive: > WireGuard currently uses static addresses everywhere. This is because that is mostly a better way to design your network. But in some cases, insane people want dynamic IP addresses or other dynamic configuration. https://github.com/WireGuard/wg-dynamic/blob/master/docs/idea.md https://github.com/WireGuard/wg-dynamic/blob/master/docs/ide... So now I'm insane for not wanting to configure every connected client?

anderskaseorg 7y ago

“ChaCha20 is a stream cipher which are easier to implement in software. They encrypt one bit at a time. Block ciphers like AES encrypt a block of 128 bits at a time. That would need many more transistors when implemented in hardware, so larger processors come with AES-NI - an instruction set extension that performs some tasks of the encryption process to speed it up.” This entire paragraph is nonsense—that isn’t what a stream cipher means. ChaCha20 encrypts 512 bits at a time. The rest of that section goes on to describe how AES-NI is available everywhere except where it isn’t, and ChaCha20 can’t take advantage of hardware acceleration except where it can—then makes a blanket conclusion that AES will “outperform ChaCha20 in every single scenario” with all those exceptions conveniently ignored. (Are there correct, nuanced arguments to be made here one way or the other? Of course. But this article isn’t one of them.)

ccktlmazeltov 7y ago
The first paragraph makes no sense that's true, but what follows is a good point. AES-GCM is much much faster than ChaCha20-Poly1305. If: 1) your market is fragmented 2) many clients are cheap phones that don't support AES-NI 3) you can differentiate them so that you don't penalize better clients Then yeah it makes sense to use Chacha20-Poly1305 for some of these clients. But choosing Chacha20-Poly1305 over AES-GCM all the time doesn't, and I'm not sure why Wireguard does that (besides trying to be trendy).
- cakoose 7y ago
  Sure, that's a fine argument to make. But the article says "I expect AES to outperform ChaCha20 in every single scenario", even when the very next sentence talks about a scenario where that's not true.
- cyphar 7y ago
  It's to make the design simpler. If you only use one crypto algorithm there's no cipher suite negotiation in the protocol (and thus no downgrade attacks). And while AES-GCM is faster with AES-NI, ChaCha20-Poly1305 is constructed to avoid timing side-channels (so software implementations are automatically much safer by default).

abrookewood 7y ago

Slightly off topic, but does anyone know how you could configure user groups with Wireguard? So a common set of ACLs, permissions etc. It seems more geared towards a single user.

lapinot 7y ago
What do you mean by "user groups" and "ACL" in the context of VPN? In any case, the answer is most probably "write some firewall rules" (discriminating on the source IP, the ones you configured as allowed IPs in wireguard).
- abrookewood 7y ago
  I was trying to work out whether I could replace a VPN server like OpenVPN or SoftEther with Wireguard. Both of those allow you to create multiple client/users that share a set of rules. E.g. roaming Developers can connect via VPN to this resource, but not that one. WireGuard looks to be a lot lower level and probably not well suited to that task.
  - chme 7y ago
    WireGuard is a protocol with some tools to setup basic connections. What you probably want is some way to manage Wireguard peers and network zones with firewall and routing rules.

wrs 7y ago

Wireguard is early, agreed, but I totally disagree with this attitude that “real world IPSec works fine”. When I have to set up an IPSec tunnel where at least one side is a vendor I haven’t already suffered through, I always allocate at least a full day to getting it to work. Perhaps it’s because I’ve chosen obscure fly-by-night vendors like Cisco, VMWare, Microsoft, and Google. Or...maybe IPSec, in theory and practice, is a nightmare of unnecessary complexity that should be killed with fire.

1_person 7y ago
A substantial fraction of the complexity of IPsec actually is the fault of the various vendors and implementations -- and is technically the complexity of IKE rather than IPsec in most cases. It's actually quite simple under the hood and frankly can't be made much simpler while still achieving the security objectives. The often wildly overcomplicated configuration syntax together with subtle differences in implementation defaults, cipher and parameter naming are what I see creating challenges for vendor interoperability.
- wrs 7y ago
  The distinction between IKE and IPsec is the last thing on my mind when I’m in the fourth hour of debugging a connection. :) The existence of all the configuration options is the underlying problem. Well, the wealth of options plus the near-universal behavior when you have a mismatched configuration: either a vague yet misleading error message or just a silent refusal to work. Combine that with arbitrary vendor restrictions on that wealth of options and it’s just a guaranteed waste of time, E.g., neither GCP nor VMWare VeloCloud let you configure key lifetimes, so they can never connect to each other. Aside from the vendor stupidity, that’s a protocol problem: how does refusing to connect when the two sides disagree on key lifetime help security?
  - 1_person 7y ago
    Permitting key lifetime to disagree can allow an attacker to manipulate key lifetime, which could defeat perfect forward secrecy if the key lifetime is manipulated towards infinity or used to gather data for a known plaintext attack if the key lifetime is manipulated towards 0. Replay attacks also come to mind.

Mister_Snuggles 7y ago

I've been looking at WireGuard on and off but so far I'm sticking with IPSec. I currently have two use cases: 1) A road-warrior setup for iOS and MacOS devices with connect-on-demand if needed. Authentication is done using user certificates issued by an internal CA. This gives me secure access to check my security cameras, etc, and makes it completely frictionless. 2) A persistent tunnel to a cloud provider's network. The cloud provider only supports IPSec, so WireGuard isn't even an option here. This is mainly just homelab-type playing around, not serious work. I think WireGuard can do the first use case, but without centralized control over what routes, split tunnels, DNS, IP address assignments, etc, are pushed to the clients. I'd have to manage deploying all of this to the clients by hand instead of letting StrongSwan do it for me. On the IPSec side, setting everything up was a huge amount of effort. My first use case probably took a total of a day and a half (over the course of a couple of years as the solution changed and evolved) to get it into its current state. I'm not including getting the PKI stuff figured out since I wanted that for other stuff anyway. The second use case took me about three days to get set up satisfactorily. Most of this is because I can't see the logs on the cloud provider side, so debugging it is a matter of waiting, sometimes for six hours, for the tunnel to stop passing traffic, followed by tweaking settings based on what the error might be, and repeating. IPSec's complexity[0] really works against it here. I expect that WireGuard would be significantly easier for this use case if the cloud provider supported it. [0] https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection https://wiki.strongswan.org/projects/strongswan/wiki/ConnSec... - I've been staring at this page way too much lately.

geofft 7y ago

> Imagine you have a VPN server with 200 road warrior clients somewhere out there in the world - which is a very normal use-case. If you were to change the cipher you are using from one day to the next one, you would need to upgrade your WireGuard software on all those laptops, phones, etc. at the same time. That is literally impossible. Administrators who have tried this needed months to deploy configuration changes. Sometimes even middle-sized companies need years to conduce a process like this. In a world where Mario Kart Tour can get millions of people on all sorts of smartphones to update within a day of release, there is no actual reason why anyone else should be unable to. All of these businesses have painted themselves into a corner - they've said that they don't care about being able to update software within a year, and they've built processes around that, and now they whine that they can't update software within a year. Tough. Design things from day one with the assumption that updates will happen. Then you can patch software vulnerabilities in a timely fashion and not get attacked via well-known VPN software flaws like Travelex did. If you genuinely care about your business, you'll already want to figure this out. (Which is the other problem with this article: "secure" isn't really about cryptographic algorithms, these days. There are tons of good cryptographic algorithms. Just don't use the bad ones. "Secure" is about whether you're using them right, whether you've got memory safety vulnerabilities, whether you've got logic flaws, etc. Every piece of complexity in your software - including cryptographic agility - imperils "secure," and the best defense is being able to confidently apply patches to your software wherever it's being run.)

laktak 7y ago
You can also setup the new version as a new instance on a different port and run them in parallel.

jcrawfordor 7y ago

The article is obviously a promotional piece for ipfire and so exists to promote a certain angle on the topic. Even understanding this, though, it's strikes me as pretty questionable. The section discussing dynamic IP addresses seems to be based on a misunderstanding of Wireguard. The IP addresses that must be statically established in Wireguard are the addresses used inside of the tunnel, and are independent of the public (internet) IPs of the machines involved. The wg-dynamic daemon mentioned is a system for dynamically allocating IP addresses in the tunnel, and has so far not been completed, at least in part because it's not very obvious why you would want to do this (although in general the development of an in-band configuration standard for Wireguard has useful implications). Wireguard allows you to identify the endpoint using a DNS name, which means you can handle a 'server' with a dynamic IP address by dynamically updating the DNS record - a common approach that is no doubt exactly what ipfire supports doing for ipsec. In the end, though, the article just suffers from being an apples-to-oranges comparison. Wireguard is a VPN tunnel protocol implementation, ipfire is some sort of GUI frontend for managing a bunch of network tools. Of course ipfire has quite a few more features than wireguard.

tssva 7y ago
Although the article is confused regarding dynamic IP addresses your solution of identifying the endpoint using a DNS name is also not a complete solution when using Wireguard. The Wireguard tool, wg, resolves the DNS name and then sets the ip address for the endpoint which the wireguard protocol implementation then uses. Since the wireguard protocol implementation doesn't do any DNS resolution if the endpoint address changes even if the DNS record is updated wireguard will never know. Instead another tool needs to check the DNS record of the endpoint periodically either at some fixed interval and/or based upon the TTL of the DNS record. If the record changes it then needs to update the configuration of the wireguard protocol implementation.
- cyphar 7y ago
  This is not always required. WireGuard peers can roam freely very similarly to Mosh (if one peer receives an authenticated message from one of its peers from a different IP address, it will update the gateway of that peer and will send all subsequent packets to that IP address). But to be fair, this doesn't work perfectly (especially if you have certain firewall rules that block UDP packets if they're not part of the what the firewall thinks is the same "connection", if both peers change their IP at the same time, or if the peer whose IP changed was rebooted or reconfigured before the other peer received a packet from its new IP addreds) but it really does work surprisingly well. For those (important) corner-cases, I would imagine that higher-level tooling such as NetworkManager would do the DNS checks you're talking about.

notlukesky 7y ago

Does anyone have a breakdown of the different open source licenses for the other projects apart from the kernel? from wireguard.com License The kernel components are released under the GPLv2, as is the Linux kernel itself. Other projects are licensed under MIT, BSD, Apache 2.0, or GPL, depending on context.

dispose256 7y ago

Well, I can see that I am outgunned as far as advanced networking knowledge goes. I would just like to say that I did a head to head comparison between openvpn and wireguard using the same hardware, server and client endpoints. Connection from Montreal to Amsterdam. Result was that something like this: novpn=100% wireguard=95% speed, openvpn=25% speed. Enough to convince me that for my use case (simple, steady point to point) wireguard is very much the superior option.

api 7y ago

Most of this is silly, but there is one correct point: large enterprises will never use WG unless we can get NIST to approve ChaCha and C25519 under FIPS. Yes it's mostly bullshit. No it won't ever change. FIPS is a check box and its all about liability and things like insurance. It has zero to do with tech and everything to do with standards and bureaucratic and legal requirements. Nobody ever got fired for using FIPS approved stuff. Use something different like WG and it (and you) will be blamed for any breach. Note that I'm not sure to what extent this is true in Europe, but there you have another problem. In my experience European industry is just culturally super conservative and does not like to adopt new things. So even if they don't have the FIPS boat anchor, they're just terribly change-averse.

teekert 7y ago

Hmm, I really wonder what mess he is talking about: "and here we are in the middle of this mess." It takes an experienced sysadmin a whole 20 min of his life to install the program, play with it and judge it (I guess, it took me a whole evening before I understood that the client needed its own config which can be created on the server, it's nice that you can then just scan a QR code with your phone though to configure it). Or even less when he talks to colleagues. This whole sentence immediately puts me off. I'm just a home server guy, no vpn experience. Messed with WireGuard for a night and left it installed. Have been using it ever since with no issues. How did I get in the middle of this mess?

adam0c 7y ago

paid advertising?

hhamalai 7y ago

Blah, WireGuard ain't necessarily superior by technical means, but being open source & easy to use solution, its efforts are crucial for the secure communications sector to go forward. All this FUD is just telling there is a strong need for tools like WireGuard.

mikl 7y ago

This is an excellent example of motivated reasoning. The author wants to keep selling his IPSec tool and thus throws together a word salad loaded with conjecture and theoretical concerns. It appears he’s not even tried WireGuard. The argument that it does not work for road warriors is a misunderstanding of where static IPs are required (inside the tunnel, not outside). As one who has tried WireGuard, I’m happy to say it can already replace OpenVPN and IPSec for the 80% case. And not only that, it is in practical experience much easier to install and set up, and much faster to connect and has excellent latency and bandwidth. It is great for road warriors, I’ve been using it for that purpose for six months or so and have never had any problems with it. Sure, there are some VPN features WG will not implement, for those you’ll have to stick with legacy VPNs like IPSec or OpenVPN. The rest is just FUD.

larschdk 7y ago
Static IP addressing inside the tunnel is still a major pain point for significant use-cases, e.g. company-wide VPN access for all employees. How do you do static addressing for 200+ people with their own devices?
- kemotep 7y ago
  You provision them. How do you create user accounts for 200+ people? These end users likely do not already have wireguard on their devices so as part of the software rollout you assign them an ip. A /24 gives you enough addresses for over 200 people and a /8 future proofs you for a much larger company size. You can also just spin up different wireguard networks for different departments or even think about using IPV6. This is the same for any large rollout of technology really. There may be some hands on effort but nothing that couldn't be automated with a spreadsheet and a script.
puzzlingcaptcha 7y ago
>and much faster to connect and has excellent latency and bandwidth I have my own ipsec deployment and this argument always seems shaky to me. Here is how long it takes to establish ipsec connection on my laptop: https://streamable.com/27des https://streamable.com/27des The cipher suite used is aes256gcm16-prfsha384-ecp384 for IKE and aes256gcm16-ecp384 for ESP which is in line with CNSA https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa... I'm using Strongswan which I highly recommend mostly due to their comprehensive set of tests for virtually every scenario https://www.strongswan.org/testing/testresults/ https://www.strongswan.org/testing/testresults/ I did not see any meaningful difference in bandwidth between ipsec and wireguard. As a bonus, ipsec is natively supported by Windows 10. I don't use OpenVPN which I think is worse in that regard due to packet shuffling between the kernel and userspace but between ipsec and wireshark the only discernible difference for me is the effort in setting it up.

alanfranz 7y ago

There seems to be a misunderstanding of what "cryptographic agility" is, as well. Usually cryptographic agility means the ability to mix-and-match different protocols/options, e.g. use a certain key exchange algorithm with a certain symmetric encryption algorithm and/or MAC/HMAC; keysize, handshakes, options, things - everything can be negotiated by different clients, and sometimes a bad option (or a bad combination of options) can be negotiated. If you've got five key exchange algorithms, ten encryption algorithms with different key and block sizes, and ten MAC/HMAC algorithms - I'll let you calculate how many possible outcomes are there. Without cryptographic agility, this is not possible. In TLS, you would have a very specific key exchange algorithm with a very specific encryption and auth algorithm. But this does not mean that versioning is not supported. When some primitive is too old, a V2 API (again with a precise algorithm combination) can be created, and clients and servers can keep using both V1 and V2 for some time.

WhyNotHugo 7y ago

It's hard to see how you can focus on security _and_ implement something as a kernel module. A kernel module give it the highest amount of privileges it can have. Meanwhile, we all know of the "principle of least privilege". Not to mention any potential bugs can kill the entire system. While a kernel module may have some performance gains, I'm sceptical about the trade-offs here. And I definitely don't think "VPN" falls into what we usually think a kernel should be responsible for.

floatboth 7y ago
The kernel part is tiny. AFAIK, this is just like Netflix's KTLS — configuration stuff and handshakes are in userspace, only the bulk transport crypto is in kernel.

j0057 7y ago

Having to update all clients at the same time when deploying a Wireguard with different ciphers is solvable with just deploying another Wireguard server alongside the new one, right? I mean it's debatable whether one likes this approach better than more complex cipher negotiation protocols -- clearly these things should not be thought about in absolutes or "best practices", but as tradeoffs with different pros and cons. Wireguard seems to prioritize protocol complexity above upgradeability, that's not to say one is better than the other.