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.
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.
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.
Right, the free roaming tends to be on "the other side" though. This is a bit confusing to talk about because Wireguard does not have a concept of "client" and "server" and either side can nominally initiate the tunnel. However, in roaming configurations, typically only one side will have the information to initiate the connection (endpoint) and so there's a tendency to call this the "client."
The non-roaming end (end with a known endpoint) will update the IP of the roaming end every time a handshake occurs. The issue the OP is getting at though is when both ends are roaming. In this case the, er, "more roaming" peer needs some way to find the other peer. There are a lot of technically interesting ways that we could solve this problem, but in practice it's pretty much always solved by dynamically updating a DNS record. I would say Wireguard handles this scenario about as well as anything else (maybe a little worse, see sibling comment).
Another approach would be using a "meet-me" relay with a fixed IP, such as TURN. This also has the advantage of handling NAT on both sides (which would be a common issue with a roaming-to-roaming situation). I can't think of any reason it's impossible to run Wireguard through TURN but I can't find any examples of anyone doing so, likely in part because the TURN client is usually embedded in the application and is a bit complicated. Still, might be a hobby project to implement it for Wireguard.
This is an issue, but in typical dynamic IP situations the IP tends to only change when there's some sort of disruption that prevents renewal and not very frequently (e.g. I've held a Comcast consumer IP for over a year before), which tends to mitigate this effect since the IP changing "out from underneath" the tunnel won't occur. Most dynamic DNS schemes, with DNS caching added on top, also tend to result in pretty long (hour +) delays on IP updates to DNS which further make this a bit of a non-issue.
That said, I do believe both IPv6 and OpenVPN will have this exact same problem - IP change will not be reflected until something forces setup to repeat. The difference would be that these, at least I do believe, will re-resolve on retries. Wireguard doesn't really have a sense of "retrying the connection" which makes it sort of philosophically difficult for it to do so.
One very common scenario where WireGuard fails - you have a WG persistent VPN enabled and you actually move into the network that has the VPN endpoint. The IP of WG endpoint changes from a public one to a local one.
This keeps happening to me all the time, and it is no problem.
Once I move into the network that has the respective VPN endpoint, the subnets that are routable via wg become routable via ethernet/wifi which have higher priority, so the traffic will go directly.
Yet still it spreads lies. There's not only 4 pieces of information needed to establish IPsec (they even cannot count as they mention 5 pieces). In addition to named remote and local IP addresses, subnets and a pre-shared key you also need:
* mode of operation (transport or tunnel)
* exchange mode (base, main, aggressive or ikev2)
* policy mode of operation (encrypt and/or protect - yes encryption is optional with IPsec)
* Phase 1 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds
* Whether you/remote uses a PFS (if so, then also DH Group)
* Phase 2 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds
* Whether or not to use NAT traversal (changes the protocols and ports needed to be opened on the firewall(s))
If you don't know some of these parameters chances are you won't be able to establish the tunnel no matter how hard you try.
Plus you need to know all the vendor quirks as establishing IPsec from Cisco to Fortigate or Sophos is not straightforward.
Then you may end up playing with NAT-exclusions, SNAT/DNAT if both sides of the tunnel have the same or overlapping IP ranges.
Setting up IPsec is definitely not an exchange of 4 parameters...
I think the point is that if you “WireGuard-ify” IPSec and just fix all those parameters (e.g. take the vendor defaults) then you’re left with 5 pieces of information.
If the value of WG is just that it forces all these parameters to be static then the best thing we could do is come up with the “WireGuard” IPSec profile call it a day.
Are you saying that fixed parameters chosen for no apparent reason by the WireGuard developers are better than modularity and interoperability of IPsec?
What if in a few months ChaCha20 gets proven insecure due to collisions found or easy factorisation? What can WireGuard offer to mitigate that?
Shouldn't then also browsers implement only TLS1.3 and ed25519 ciphers because they are currently the most secure?
> .. for no apparent reason by the WireGuard developers...
It's a very weird assertion that the Wireguard devs just threw the software together at random, choosing parameters for "no apparent reason".
> What if in a few months ChaCha20 gets proven insecure due to collisions found or easy factorisation? What can WireGuard offer to mitigate that? Shouldn't then also browsers implement only TLS1.3 and ed25519 ciphers because they are currently the most secure?
Ultimately, it's a value judgement. You can either have resistance to downgrade attacks (which have themselves proven to be quite problematic), or you have interoperability across multiple versions and configurations of endpoints. Increase the configurability of the protocol, and you massively increase the complexity. Increased complexity means increased testing burden and ultimately increased risk.
If Wireguard needs to be fixed in a backwards-incompatible way, then we'll find ourselves with a new version of Wireguard that doesn't work with the old version.
> new version of Wireguard that doesn't work with the old version.
Right, and maybe this is actually in improvement in security overall but it just externalizes the downgrade attack since once there are multiple versions of WG floating around with different vendors/clients only supporting a specific version you end up similarly vulnerable since you need to run multiple WG endpoints of different versions.
And since it’s a kernel module you’ve made the hassle of doing so very annoying compared to one line in a config file.
IPSec feels messy and complex specifically because the world is messy and complex. WG is fantastic and I love it dearly for “the 90% case” where I have total control over all peers.
>TLS is famously susceptible to downgrade attacks.
The article is from 8 years ago so I would suggest that the fame has mostly faded. TLS downgrade attacks are not a thing in practice. A system with non-upgradable and broken crypto is much worse than something that requires a MITM attack to get at the broken crypto. I am not sure why there are opinions to the contrary. In either case you still have to fix things. The non-upgradable case will just be much much harder.
Absolutely not! What I mean is that I don’t think that IPSec having a bunch of tunables like this should count as harshly as the parent implies when it comes to configuration complexity because WireGuard isn’t all that different — the tunables are just chosen earlier in a way that’s not user-visible.
“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.)
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).
That's only true if most of your clients aren't mobile devices. That's why Google pushed for ChaCha20-Poly1305 standardisation and usage with TLS several years ago.
ChaCha20-Poly1305 outperforms AES on mobile devices where it matters most. The article espouses a desktop-centric view of the world that is completely obsolete.
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.
4) you have customers with DSL or cable, with cheap routers, that run some 800 MHz MIPS or ARMv6 CPU. Dual core, if they are lucky. Think of the tp-links and netgears out there.
Compared to these routers, you average cheap cellphone is overpowered. 800 Mhz single or dual core is circa 2012 smartphone.
And this is on the gateway, not on the client, potentially serving several clients. Chacha20-Poly1305 absolutely murders AES there. AES won't even saturate 20MBit+ upload.
Didn't read the article but "They encrypt one bit at a time" is exactly what stream cipher is, that is, a PRNG. The resulting stream of bits from PRNG is XORed with cleartext bits to produce ciphertext bits.
Dan Bohen told me that in Stanford Cryptography courses.
That’s clearly not the way the author intends us to interpret “one bit at a time”. They intend it as some kind of explanation for why ChaCha20 is slow. (In reality, bitwise XOR is one of the fastest operations a computer can perform; it runs with as much of a parallel speedup as you have parallelism to give it, and it’s utilized extensively by practically every cipher including AES.)
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.
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
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.
Single client implementation is the easy part. The hell starts when you need to use several different clients (think iOS, Android-built in or Strongswan, Windows, Linux Libreswan or Strongswan, also throw in several appliances by different vendors) and each of them has different ideas about what is acceptable in their algo list[1].
And that's just cipher negotiation. Don't get me started, what the clients expect to be in the certificates as CN and SAN. You have IPSec gateway behind NAT (so the internal IP of the gateway is different than the public IP), with dynamic IP, so you need to use DNS instead of fixed IP? Good luck with configuring your Windows clients.
[1] I.e. libreswan has deprecated MD5 and SHA1 in their default algo list; if you need them, you must find out how to configure the client that uses it as a backed. Ubiquiti routers on the other hand support SHA1 as their strongest auth algorithm, so there is no match, leading to forum posts like this: https://community.ui.com/questions/L2TP-unusable-on-Fedora/d..., where people butcher it and end up using 3DES and DH group 2. Yay, great for security.
> 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.)
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.
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.
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?
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.
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.
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.
> 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.)
This looks great, thanks! One quick note: one often-unnoticed thing that OpenVPN currently has in its favor is how robust it is in the face of users with different sets of needs or competency levels.
This comes out in, for example, the "Accessing your home LAN" part of your article. It has a bunch of iptables magic that I understand, but presumably shouldn't have to in order to use WireGuard. Actually, the device that makes the most sense to use as a WireGuard server is my router, which is based on BSD; so presumably I'd need modify your commands to get this working on my OS! With OpenVPN, on the other hand, I can literally install a package for my firewall (OPNsense) and it's all done for me with a few clicks. That's what I mean by robustness: I'm capable of getting OpenVPN working on just about any computer, including my GUI based BSD router. WireGuard just doesn't have that yet.
Can attest to wireguard being simple once you know it but horrible to get working the first time.
I did, however, make it harder for myself by setting it up on a Unifi gateway. Where every push of an invalid config would put the gateway in a boot loop, bricking my internet connection for a few minutes.
Thanks for writing this up - you did a great job. I came across it on a DDG search when I was exploring WireGuard and as a result, I found it easy to setup!
Do you know of anything like this available for windows? all the guides are for linux, but I use windows for my every day laptop, I'd also like to set this up for my phone and obviously iOS doesn't really have a cli.
For what it's worth this did seem easy to follow, I just know that when I tried to follow a guide similar to this one a while back I couldn't get it to work for a windows client.
Are you just looking to set it up with iOS and Windows clients? If the Wireguard server is running Linux, an easy way to copy the config over to an iOS or Android device is to use qrencode. For example, `qrencode -t ansiutf8 < $config_file` will output a QR code that can be scanned from the Wireguard app to automatically import as a new tunnel.
I used StavrosK's guide (thank you!) to put together two scripts a while back, one for generating a new server config file, and one to generate a new client config, outputting the config to a file as well as to a QR code on stdout. You can copy the client.conf file over to the Windows machine and import the configuration via the "Import tunnel(s) from file..." option in the Wireguard client, or scan the QR code output from the mobile device clients via "Create from QR code".
Here's my script for generating a client cert: https://cdn.seedno.de/txt/wireguard-certgen. It assumes Wireguard is already configured on the server on interface wg0, and is using the default port of 51820/UDP, though both are configurable via variables. For reference, the accompanying setup script is https://cdn.seedno.de/txt/wireguard-setup. Both scripts require a bit of customization to match your environment (you may want to be particularly careful with the iptables firewall PostUp/PostDown commands), but hopefully they can serve as a starting point to figure out any issues you encountered last time you tried.
I just found this[0] article on setting up WireGuard on Windows, I haven't followed or even studies it too closely, but hope it helps with the Win specific things.
Totally off topic but this is my favorite article to come across when looking around at various networking related things.
It always sends me down a rabbit hole of watching and listening to recordings of people shouting perkele. I always trying to think of a similar word in US English but never can think of anything.
I setup a server and got three engineers connected in an afternoon. I've never been that successful with an IPSec deployment. The hardest part for me was coming up with a way to link IPs, keys and users. I wrote a small Python script and store the peer info in a small DB. Not super difficult and the engineers using it took less than 10m each. Mac, Linux and windows. Pretty impressed.
What's missing for me:
* a good "connected" indicator
* session tracking/logging
Pretty sure I can solve the tracking problem with iptablea or some not very clever network monitoring software.
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.
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.
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?
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.
Or just have both sides pick the lowest/highest proposed lifetime with a fixed minimum/maximum. Or just don’t have lifetime be configurable, because what is the point?
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.)
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.
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.
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?
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.
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).
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.
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.
> 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.
> 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.
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.
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.
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.
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.
> 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] will support vector versions of the AES-NI (VAES) and PCLMULDQD (VPCLMULDQD) instructions. These have been timed at over 150Gbps. Yes, that's correct.
> 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.)
You don't need to try WireGuard to understand it will not be as fast as bump in the wire IPsec implemented in ASIC, which is available today from literally dozens of vendors at 100Gbps+.
It is also possible to recognize without trying WireGuard that it has more protocol overhead, access to fewer ciphers than IPsec, and access to no ciphers that IPsec does not support. This means that IPsec encryption will be as fast or faster in all cases and IPsec framing will be more efficient in all cases, all else being equal.
>You don't need to try WireGuard to understand it will not be as fast as bump in the wire IPsec implemented in ASIC, which is available today from literally dozens of vendors at 100Gbps+.
But what does that have to do with anything? Wireguard certainly doesn't compete with IPsec ASICs.
>all else being equal
Unfortunately we live in the real world where this assumption doesn't hold true.
> But what does that have to do with anything? Wireguard certainly doesn't compete with IPsec ASICs.
I appreciate that you are not making that claim and I'm glad that we agree. However, that "WireGuard is faster than IPsec" is exactly what the authors are claiming without qualification, and supporting with controversial data, on the official website. As such I believe examination of the claim is justified.
> Unfortunately we live in the real world where this assumption doesn't hold true.
Yet we are in a rational discussion of the merits of the two protocols, in which outliers that introduce additional variables should be first discovered, then examined individually, rather than dismissing the first order effects out of hand on the supposition that outliers influenced by additional variables may exist.
>However, that "WireGuard is faster than IPsec" is exactly what the authors are claiming without qualification
The same blog post also extensively discusses OpenVPN, then goes on to state "Is WireGuard faster than other VPN solutions? Simple answer: It isn't."
This question presented in the post wasn't "Is WireGuard faster than all other VPN solutions?"
>Yet we are in a rational discussion of the merits of the two protocols, in which outliers that introduce additional variables should be first discovered, then examined individually, rather than dismissing the first order effects out of hand on the supposition that outliers influenced by additional variables may exist.
Are we discussing protocols or the implementations? One of these seems far more practical to me.
I'd personally love to see this benchmark where a sane IPsec configuration running on regular commodity hardware beats WG throughput.
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.
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.
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.
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.
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).
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.
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.
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.
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).
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.
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).
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.
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.
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.
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.