
Why Not WireGuard - executesorder66
https://blog.ipfire.org/post/why-not-wireguard
======
jcrawfordor
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
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
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.

~~~
jcrawfordor
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.

------
anderskaseorg
“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
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).

~~~
cyphar
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).

~~~
ccktlmazeltov
I would expect most clients to have hardware support for AES-GCM.

~~~
cyphar
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.

------
jchw
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
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
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
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.

~~~
vetinari
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...](https://community.ui.com/questions/L2TP-unusable-on-
Fedora/d91fb0a7-0507-4c6d-be7f-259d2df8edc4), where people butcher it and end
up using 3DES and DH group 2. Yay, great for security.

------
geofft
> _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
You can also setup the new version as a new instance on a different port and
run them in parallel.

------
mikl
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
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
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.

------
bscphil
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.

~~~
StavrosK
I was in the same boat as you, so I wrote stuff up so you don't have to
wonder:

[https://www.stavros.io/posts/how-to-configure-
wireguard/](https://www.stavros.io/posts/how-to-configure-wireguard/)

It takes hours to set up if you don't know how (and the docs aren't amazing),
but it should take you ten minutes using my article.

~~~
vxNsr
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.

~~~
TheKitchenSinc
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](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](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.

------
JumpCrisscross
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
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.

------
wrs
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
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
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
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.

~~~
wrs
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?

------
teekert
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?

------
dispose256
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
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.

------
microcolonel
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)

------
danielheath
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).

------
Havoc
>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
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_w...](https://www.reddit.com/r/WireGuard/comments/d8k605/gigabit_wireguard_performance_on_sbcs/)

~~~
Havoc
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.

~~~
jsight
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
Managed 250 with a rasp4. Mostly because that was fiber line speed at the
time. I suspect they can do 500ish

------
alanfranz
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.

------
eeZah7Ux
> 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
> 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
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/ide...](https://github.com/WireGuard/wg-
dynamic/blob/master/docs/idea.md)

So now I'm insane for not wanting to configure every connected client?

------
Mister_Snuggles
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/ConnSec...](https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection)
\- I've been staring at this page way too much lately.

------
hhamalai
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.

------
j0057
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.

------
FDSGSG
>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
The author seems to have enough experience with IPSec that people would
dismiss his first-hand experience or benchmarks as biased anyway.

~~~
gonzo
> 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
> 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.)

------
WhyNotHugo
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
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.

------
notlukesky
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.

------
mrkurt
(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.

------
abrookewood
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
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
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
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.

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

~~~
kylek
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
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
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.

------
adam0c
paid advertising?

