
MacOS command line version of the WireGuard VPN is now available for testing - zx2c4
http://latacora.singles/2018/05/16/there-will-be.html
======
jolmg
> It’s a little hard to overstate how big a deal this is. [...] Nobody trusts
> either codebase, or, for that matter, either crypto protocol. Both are
> nightmares to configure and manage.

Those seem quite the overstatements. I don't remember having any particular
distrust in OpenVPN's codebase or protocol. I also didn't have that much
trouble configuring neither the server nor the clients. I particularly liked
how OpenVPN's configuration is basically putting command line arguments in a
file. I could test configurations by simply changing invocations of openvpn,
and when I found something I liked, I just put the options in a file and
enabled the service to use that configuration file. Compared to the
configuration of other kinds of services, OpenVPN is pretty simple.

EDIT: This is my first time hearing of WireGuard. I can't say how it compares,
but the way this reads like a sales pitch and is so dismissive of SSH and
OpenVPN, both of which I've had nothing but good experiences from, doesn't
leave a good impression on me. I mean:

> Death to SSH over the public Internet. Death to OpenVPN. Death to IPSEC.
> Long live WireGuard!

Really?

This page would've been more effective on me if it objectively described how
WireGuard was better than these technologies.

~~~
dewyatt
It's just pure marketing - create a problem where it doesn't exist, and sell
the solution.

~~~
lvh
Would you care to rebut the arguments the blog post puts forth, such as argue
that wireguard is actually harder to configure than IPSec or that the protocol
is actually less trustworthy?

IPsec’s design era, implementation size... really nothing about the thing is
even vaguely comparable.

Also: wireguard is free and open source software. So what precisely are we
(people advocating for it) selling? We paid a hell of a lot more than the cost
of an OpenVPN AS license so that everyone could get a macOS client, for free.
I don’t make a dime off of you using wireguard.

So far 100% of the deployed OpenVPN I’ve seen has had bad crypto. Wireguard
just categorically doesn’t have that problem.

------
geofft
What's the worry about SSH over the public internet? Possibly influenced by my
college's network setup, I've always been on team BeyondCorp even before
BeyondCorp was a thing. Just use some auth mechanism like SSH keys that
prevents brute-force attacks, and disable password auth.

Do pre-authentication OpenSSH vulnerabilities happen a lot, or something?

~~~
dexen
Can't speak about security aspects, but:

If you ever use SSH to tunnel/forward TCP traffic, you should be aware of
certain performance issues [1], due to TCP's re-transmit mis-behaving
(stacking) in a TCP-in-TCP scenario. Expect seemingly random delays, followed
by bursts of transmission even well below the nominal capacity of the
connection. This also causes overall increase in amount of data sent.

The same caveat applies to any other TCP-in-TCP tunnel (as opposed to the
usual TCP-in-UDP setup), unless one or both tunnel endpoints specifically
handle re-transmits properly.

[1] [http://sites.inka.de/bigred/devel/tcp-
tcp.html](http://sites.inka.de/bigred/devel/tcp-tcp.html)

~~~
sneak
SSH tunnels do not do TCP-in-TCP. They just take the content of a tcp stream
(not the packets) and forward them over an ssh channel.

~~~
dexen
You are partially wrong.

OpenSSH, and the SSH standard in general, support "multiplexing SSH
connections", where several remote shell sessions share single TCP connection.
This is unaffected, as there's only one TCP layer in play. For OpenSSH this is
options "-M" and possibly "-J" (not sure).

Another, unrelated functionality is a straight-up TCP tunneling over the SSH
connection. This is an actual TCP tunnel, with all the advantages and warts of
the setup. With OpenSSH, it's options "-L" and "-R". Those options take
host:port arguments, and do proper TCP-level forwarding, encrypted and
compressed like any other SSH stream, layered over any transport your SSH
happens to be using. Which typically is also TCP, thus creating a TCP-in-TCP
scenario.

There's also "-w" which tunnels tun(4) connection, over which you could end up
sending TCP traffic.

Note that neither 'authentication agent forwarding' nor 'X11 forwarding' have
anything to do with any network tunneling; those just pass small chunks of
meta-data out-of-band.

~~~
geofft
> _With OpenSSH, it 's options "-L" and "-R". Those options take host:port
> arguments, and do proper TCP-level forwarding, encrypted and compressed like
> any other SSH stream, layered over any transport your SSH happens to be
> using. Which typically is also TCP, thus creating a TCP-in-TCP scenario._

I don't believe this is right - the thing tunneled over SSH is the data
flowing within the TCP connection, not the TCP connection itself. If I do `ssh
-L8080:foo:8080 bar.example.com` and then connect to
[http://localhost:8080/](http://localhost:8080/), then my browser's TCP
connection terminates at my _local_ SSH process, which decapsulates the TCP
stream and sends it over SSH. Then the SSH server on bar creates a new TCP
connection to foo.

Therefore there isn't TCP inside TCP. There are three TCP connections
connected in series: my browser to ssh on localhost (HTTP inside TCP, ssh to
foo (HTTP inside SSH inside TCP), and sshd on foo to web server on bar (HTTP
inside TCP).

Therefore the "TCP-in-TCP" problem, where a delayed/dropped packet creates
backoff in both the inner and outer TCP connections, doesn't apply. When my
browser sends a packet, it is immediately and reliably ACKed by the ssh
process running on my local machine. That ssh process might fail to get the
resulting encrypted packet to foo, but that only affects a single TCP
connection, the one from my laptop to foo:22. The browser sees a slow
connection, but it sees it being slow at the application layer, not at the TCP
layer.

So I think 'sneak is mostly right with the exception of ssh -w, which is a
relatively new feature (and not what I was asking about at the top of the
thread, in any case).

~~~
sneak
Yes, thank you for typing that out so that I don’t have to.

Also, -w is some new nonsense that nobody should really be using except in
some super dumb and hacky situations where there is no other option.

------
dguido
FYI AlgoVPN has Wireguard support in a PR right now. It should get merged
within a week once it gets more testing:
[https://github.com/trailofbits/algo/pull/910](https://github.com/trailofbits/algo/pull/910)

~~~
mbesto
This is super cool. So if I understand right, I can:

1\. Use Algo CLI to spin up a server on DO, AWS, etc specifically to pass
through traffic.

2\. Use `wg` CLI to connect to that server and pass my MacBook traffic to that
new server

3\. Dispose the server when I'm done using Algo.

~~~
zx2c4
Yep! Usually all you need is `wg-quick up myserver` and `wg-quick down
myserver` -- the wg-quick(8) command wraps all the others for the most common
trivial use cases.

By the way, I believe
[https://github.com/StreisandEffect/streisand](https://github.com/StreisandEffect/streisand)
has support for WireGuard (in addition to a billion other things...).

~~~
mbesto
Just set up, this is amazing. Thanks for sharing.

------
guy98238710
In my experience, people use VPNs as an excuse to push weak host security
through review. Eventually, everyone dismisses all security concerns with
"it's behind VPN". And then they connect to the VPN with their malware-ridden
computers. People are also surprised that whatever they run inside supposedly
sandboxed VM actually gets full access to the VPN. And then there are
configuration errors that can lead to surprising effects like forwarding all
traffic from one's home computer through company's network filter/sniffer.

For these reasons, I always recommend running everything with public IP
address. No more excuses. It's public, so security is a must. No more
surprising network flows. Cloud-based monitoring tools can access the servers.
Limited access can be granted to non-core team members and computer-illiterate
staff.

~~~
tptacek
For organizations with extremely sophisticated security teams, pretty far
beyond the industry norm for "unicorn" startups (which themselves tend to have
security teams with 10+ people on them, meaning millions of dollars of annual
spend on security), this makes sense.

But for other companies, _when they haven 't been architected from the
beginning to carefully support this access model_, this is terrible advice.
Just awful. Converting a company with a VPN/private deployment environment
model directly to a "YOLO BeyondCorp" model will get that company owned up.

Further: if the primary things people need to get into private IP space for
are (1) developer access and (2) access for non-technical staff to admin
interfaces, the win just isn't there, even if done correctly, for most
companies with the BeyondCorp model. It costs more to keep that model secure
than it does to set up a system of VPNs for private access.

~~~
kdv
I'm certainly comfortable with WireGuard for machine to machine connections,
but I don't see how it would replace traditional VPN w/ 2FA (e.g OVPN w/ Duo)
for non-technical staff to access internal apps (at least without something
similar to PAM)

~~~
tptacek
When non-technical people get VPN access, it's almost always to access a small
selection of specific applications. Lock their VPN connections down and
implement 2FA (or, more realistically, 2FA-enabled SSO) for the applications
rather than the VPN connection.

The 2FA VPN thing is, I think, a consequence of how hard it is to set up VPNs.
Companies share VPN infrastructure between developers (who need relatively
unfettered access) and non-technical staff, because maintaining multiple VPN
configurations is so painful. WireGuard fixes that problem.

This is what I'm talking about when I say that WireGuard is a big deal. The
current situation, with 2FA logins to very powerful VPN connections, is deeply
suboptimal, and is what BeyondCorp was a response to in the first place.

If I was asked by a client today to design a remote access solution for
customer support people to access an internal admin app, I might try to devise
a site-to-site system (in which case I'd happily use WireGuard) --- deploying
host-based VPN for support staff seems like a nightmare. But even if I
couldn't, what I could do now that WireGuard is available is retain OpenVPN
but drastically ratchet down what it has access to, SAML-ize the admin
applications, and migrate developers to WireGuard environments.

------
gok
> TODO: this should use scutil and be slightly more clever. But for now we
> simply overwrite any _manually set_ DNS servers for all network services.
> This means we get into trouble if the user doesn't actually want DNS via
> DHCP when setting this back to "empty". Because macOS is so horrible to deal
> with here, we'll simply wait for irate users to provide a patch themselves.
> [1]

So the setup script completely deletes all your manual DNS settings without
warning you.

[1] [https://git.zx2c4.com/WireGuard/tree/src/tools/wg-
quick/darw...](https://git.zx2c4.com/WireGuard/tree/src/tools/wg-
quick/darwin.bash?id=a0d5736e11e1e70189393fc8803c2c1500c87d3e)

~~~
zx2c4
Pointed out on the mailing list, too.

Did you make a concerted effort to link to the file revision that doesn't
contain the fix for that?

Anyway, this is taken care of now, and will be released with the next
snapshot.

[https://git.zx2c4.com/WireGuard/commit/?id=b39298dfb540ad9c7...](https://git.zx2c4.com/WireGuard/commit/?id=b39298dfb540ad9c751e15585f4b95acb071ca84)

~~~
gok
Sorry I wasn’t trying to be a dick, all software has bugs, just thought people
might want to know before they try it. Thanks for fixing it.

------
baobrien
Is this a kernel implementation of WireGuard for MacOS, or is it one of the
two ongoing userspace implementations? I probably missed it, but I didn't see
a separate repo for it at [https://git.zx2c4.com/](https://git.zx2c4.com/) .

On that note, can anybody say how far along the userspace rust implementation
is? How hard it'd be to port the MacOS version to FreeBSD?

~~~
zx2c4
The macOS client mentioned in the article uses the Go implementation:

[https://git.zx2c4.com/wireguard-go/about/](https://git.zx2c4.com/wireguard-
go/about/)

It should be very easy to port to FreeBSD, and I'd like to make this happen.
Care to help?

~~~
e12e
Hey! I was just sitting here grumbling to myself:"I whish they'd prioritise a
solid portable user-space version" \- and it turns out you did!

How realistic is it to get this running on Windows 10?

~~~
kim0
Maybe try running it under subsystem for Linux!

------
sneak
Not to diminish this important work at all, just a question for HN: do I have
a minority viewpoint in thinking key-based SSH to a bastion host and
forwarding traffic via SOCKS (ssh -D) or ProxyCommands serves 99% of the use
cases for a sysadmin’s need for a VPN? (Corp networks and L2 privacy needs
notwithstanding.)

Edit: If so, why?

~~~
StavrosK
I think the answer is mostly that it's hard to route most traffic over SOCKS,
most applications don't obey the system-wide proxy settings, you might be
leaking DNS queries, things like that.

~~~
cookiecaper
Still not as thorough as a full-fledged "real" VPN, but for most ad-hoc
purposes, something like sshuttle [0] works well and doesn't require
application-specific configuration.

[0]
[https://github.com/sshuttle/sshuttle](https://github.com/sshuttle/sshuttle)

~~~
rsync
I am very excited about sshuttle (and in fact, rsync.net has sponsored work on
it).

The most compelling aspect of sshuttle, in my opinion, is that _any host
running sshd_ can be an endpoint - no software is required. As long as the
sshd in question has python available, you can use it as an endpoint.

------
kevin_nisbet
@lvh

What are your thoughts on the wireguard homepage effectively saying it's not
ready for production use?

I've looked at using wireguard on a few occasions, but it's always sounded not
ready for production usage reading through it. Looking forward to the point
where I can though.

~~~
zx2c4
We're just conservative. At some point we'll change the webpage.

~~~
lvh
(Since GP asked me specifically: I completely agree with Jason here.)

------
gepeto42
I have not tried WireGuard yet. Is it more reliable than existing methods over
"bad Wi-Fi"?

I find that one of the best ways to make bad hotel or plane Wi-Fi completely
unusable is to use a VPN, and having something more reliable on bad links
would be great.

~~~
hamandcheese
WireGuard uses UDP and is effectively "connectionless" meaning there is no
persistent connection to be maintained. It also allows for seamless IP address
roaming (your peer doesn't care if two messages come from two different IPs so
long as they are signed with the right key).

In short, I expect it to have no meaningful degradation when on a bad network
(so long as they don't block the traffic or have overly hostile NAT).

~~~
gepeto42
That is exactly what I was hoping for.

Too bad it'll take forever before iOS can use it, because the current state of
VPN on Wi-Fi is terrible (I understand that is not the first thing WireGuard
is looking to solve, but it'll be great when it gets there).

~~~
benjaminl
ZeoTier, which also uses UDP, has an iOS app. So it is possible if the dev
team wants to prioritize it.

~~~
grumblez
It wasn't a whole lot of fun trying to connect code designed to operate at L2
(ZeroTier) with the L3 tun adapter they give you in iOS and Android.
Fortunately that code doesn't have to be touched too often though :)

~~~
hamandcheese
Fortunately WireGuard only encapsulates at L3, if I’m not mistaken :)

------
zimbatm
The real competitor, which the article doesn't talk about is
[https://www.zerotier.com/](https://www.zerotier.com/) . Is is also open-
source and have been available on macOS, iPhone, Android, Windows on top of
Linux for many months now. It is easy to install and use. Deals with punching
NAT and does smart routing when both devices are on the same network.

I don't know how well it compares in terms of performance and crypto, it would
be nice to know.

~~~
tptacek
Where is ZeroTier's protocol documented? All I could find was a document that
said it was custom, and "like IPSEC". What could ZeroTier do _as a VPN
protocol_ that would make it better than WireGuard, which has a pedigreed
protocol that, in its WireGuard incarnation, has had multiple rounds of formal
validation?

I wrote the article we're commenting on. Why would I take the time to talk
about something like ZeroTier? WireGuard solves the problem I'm talking about
decisively.

I'm prepared to hear something about ZeroTier that makes it interesting in the
WireGuard setting, but I am not interested in a long list of non-VPN non-
access-tunnel features that ZeroTier might have that WireGuard lacks, because
lacking random features is exactly the point of WireGuard.

~~~
api
No RFC-type document yet but quite a bit of commenting here:

[https://github.com/zerotier/ZeroTierOne/blob/master/node/Pac...](https://github.com/zerotier/ZeroTierOne/blob/master/node/Packet.hpp)

There is also a higher-level description of the entire system here:

[https://www.zerotier.com/manual.shtml](https://www.zerotier.com/manual.shtml)

ZeroTier solves a broader set of problems than WireGuard and has SDN-type
network flow rules, security tap capability, and is a full L2 emulation layer
with support for multicast.

From what I've seen the WireGuard protocols are excellent and the
implementation is very nice and clean. A core ZeroTier implementation to
support a simple L3 VPN use case could be as short as WireGuard but that would
be without all the rules engine, multicast, etc. stuff.

~~~
tptacek
Just the .cpp code, not counting the .hpp code (which is full of code,
including lots of memcpy's) in the node/ subdirectory of this repo is
something like 4x the entire size of Linux WireGuard. The crypto protocol is
undocumented, but the maintainer is playing games with things like the Salsa
round count (which is fine, but I mean, speaks to a mindset). I might poke at
it for sport at some point, but I don't see how I could ever recommend it.

~~~
api
I am the primary maintainer. :)

A minimal implementation could be much shorter, but the ref implementation is
not minimal and includes a lot of features that go far beyond the scope of
WireGuard.

Salsa20/12 is standard and according to the docs is considered secure. I
recall that DJB initially specified the cipher with 12 rounds but added 8 more
for margin. There are Salsa20/12 implementations in many crypto libraries. The
best public cryptanalysis on Salsa breaks 8/20 rounds with a time difficulty
of 2^251.

Personally I think concern over algorithm strength is usually misplaced as
long as you're using an algorithm that is not known to be very weak (e.g. DES,
RC4). Halfway decent cryptographic algorithms are almost never broken.
Implementations and protocols are broken all the time.

One thing we did to guard against protocol issues was to implement what DJB
calls "boring crypto." The cryptographic encapsulation is dirt simple
Salsa20+Poly1305 constructed exactly as in the NaCl secret box functions, and
nothing more. We've resisted adding more advanced features to the
cryptographic layer because so far they haven't really been necessary and the
risk is not worth the small benefit they may have.

At the time this was designed (started in 2010) Salsa20/12 was the best option
to achieve high performance across a variety of devices including ARM phones
and slow VMs with a clean and small code base. If it were written today it
would probably use ChaCha20 (faster) or AES-GCM since almost everything worth
mentioning has hardware AES now. We will likely rev the crypto at some point
but would also like to upgrade the asymmetric cipher as well. Waiting to see
if the Goldilocks curves (curve448) get added to the NIST standard. They are
proposed but not yet approved. If they are we'd probably go to
curve448+AES256-GCM with a longer IV.

That being said we're not solely oriented toward crypto and generally tell our
users not to rely on network crypto as their only line of defense. Network
crypto is sort of analogous to hard drive encryption. It protects you from
people who don't have access to anything, but won't save you once someone gets
any access beyond the perimeter. We advocate the use of encryption and
authentication within networks as well if you care about security. This also
guards against the discovery of a bug in any layer-- if someone breaks one
layer they are confronted by another layer.

An RFC-style write-up has been on the to-do list forever, but the to-do list
is very long.

~~~
tptacek
None of this is wrong (avoid GCM).

I've been poking around for about 30 minutes and I'm still not sure I
understand what the key agreement protocol is. I'm trying to follow starting
from _doHELLO and you're losing me somewhere amidst the moons and worlds and
stuff.

~~~
api
An identity is a public key. An address is a hash of that public key. Key
agreement is just SHA512(Curve25519(my secret + your public)). Public keys are
looked up from addresses via "upstream" nodes by the sender. An upstream node
is typically one of our root servers unless someone has added their own.

Crypto here is fairly dirt simple as I said. It's just ECDH with two
Curve25519 keys and then go.

The moons/worlds stuff is just some odd terminology for how to define upstream
nodes. We are dumping that in favor of something more straightforward in the
future. Most users don't need to care about it.

I'd like to avoid GCM but we also may have a need for FIPS compliance in the
future. Yes I know that FIPS basically mandates weaker crypto... or at least
crypto that is easier to implement wrong... but if it's not FIPS it isn't
"enterprise" to some (clueless) people. Then you have organizations mandated
to use FIPS crypto by forces beyond their control.

~~~
tptacek
There are no ephemeral keys at all? It's just static-static DH?

~~~
api
Not in 1.2. This is planned for 1.4. It's fairly prominent in the manual.

It was left out of the original design since ephemeral negotiation means state
and therefore latency and stalls if packets are dropped. The present design
leaves it out as part of a design that prioritizes instantaneous connectivity.

When we do add it we will probably add a network level config option to select
whether forward secrecy is required. If it's off it will work instantly and
then lazily upgrade. If this option is on it will wait.

As I said though I don't see network level (L2/L3) encryption as being worth
much more than whole disk encryption. Each really secure thing should have
it's own secure authenticated session that would be secure enough over the
open Internet. That way a network compromise or trojan is not instantly fatal.
We pretty much tell everyone this.

~~~
tptacek
Have you considered just, you know, adopting the WireGuard protocol and then
building something on top of it to coordinate connections?

I built something like this (in C++, no less!) back in 2000. After the company
failed, I always felt like we had made a mistake not just shipping the
absolute simplest possible message forwarder, and then implementing the
control plane for it in a reasonable high-level language. (In fact: an early
team member pushed us to do that, and I shot them down.)

~~~
monkeywork
This may come off as rude ... but tptacek there is a fine line between being
enthusiastic and aggressively dickish. All over this thread you have been
PUSHING hard... way harder than you should have to if your product is as good
as you are touting. It's one thing to promote, but what I've read all over
this post (not just this thread) is someone whose personality REFUSES to allow
them to even give a small inch in a debate -- feels a drive to be right no
matter the cost. That makes me question how likely you are to take input from
people who can / want to help ...

Friendly advice -- roll yourself back down to an 8 or 9.

~~~
tptacek
WireGuard isn't "my" project. I have no formal relationship with the
developer, other than that we like his work so much we've contributed a bit to
its development (less than others).

You're not being rude. But I have no plans to give an inch on this discussion.
If that's problematic for you, you're welcome to use the HN votey-buttons as
you see fit.

~~~
monkeywork
Just letting you know that your comments/attitude/etc are likely hurting the
cause you are championing. Your volume of replies, the tone you take in them,
and the way you react makes it seem like you ARE deeply part of the project...
Thus I (and likely many others) associate you with it. I don't care what you
comment - be a dick to the fullest if that's your thing - I was simply letting
you know the impression you are leaving out there.

------
kdv
Is there any info on how many concurrent clients the WireGuard server can
handle? I'd be interested in hearing if anyone has used this for management
traffic to a large (>100) number of devices

Edit: ..and if so, how they handled IP assignment and key distribution.

~~~
zx2c4
Linux kernel module supports 2^20 (1048576) peers per interface. Go userspace
version supports 2^16 (65536) peers per interface. Both limits can quite
easily be raised if necessary.

~~~
kdv
Edited my question above for clarity. Any info on performance, key management,
and managing peer address assignment in larger deployments?

------
rauhl
> But the most important use case for VPNs for startups is to get developers
> access to cloud deployment environments, and developers use MacOS, which
> made it hard to recommend.

What’s that?

> … developers use MacOS …

Not all developers! I’ll believe that _many_ developers use macOS. It’s even
possible that _most_ developers conducting certain kinds of development use
macOS. But not all developers do. I don’t. Noöne on my last team did (we were
Linux-only). Several folks on my current team don’t.

~~~
tptacek
If your developers use Linux, they've already had a mature WireGuard
implementation for months. It may even land in the mainline Linux kernel (I
hope it does).

I don't have advice for developers on Windows right now, but we haven't run
into any of those at Latacora; you can assume we're broadly writing for an
audience of the kinds of startups we serve.

~~~
zx2c4
We'll have a Windows client in due time.

------
craftyguy
Is support for this in the Linux kernel yet? The lack of acceptance there is a
major reason why I haven't tried this out yet.

~~~
hamandcheese
But why? Its still very easy to install. Is it just a matter of not trusting
kernel extensions?

~~~
craftyguy
> But why?

Principle. I strongly believe that software which runs in kernel space must
adhere to the same standards (for better or worse) as the kernel. For Linux
kernel modules, this means being accepted into the upstream kernel, and
demonstrating a history of maintaining compatibility with the mainline kernel.

I've been burned a lot in the past by companies releasing their own modules,
and quickly failing to keep up compatibility with the mainline kernel
versions. Not going to make that mistake again.

~~~
zx2c4
That's a fine and fair principle. I understand where you're coming from, and
getting this mainlined is important to me too.

But for the record, we're maintaining meticulous compatibility with all
kernel.org kernels back to 3.10 and up to whatever the most recent RCs are (at
the moment, 4.17-rc5). We also support the frankenkernels from ubuntu, redhat,
and suse. We have a build and run-in-a-vm CI box testing all these kernels for
every commit and on a bunch of architectures:
[https://www.wireguard.com/build-status/](https://www.wireguard.com/build-
status/) And because we're actively working on upstreaming this, you can be
sure that this is going to continue working with upstream.

Also, this isn't a "company releasing their own modules" situation, providing
some kind of throw-it-over-the-fence corporate crap code. I'm a kernel
developer with a decent amount of upstream code, and the work I do is nearly
always for upstream kernels.

~~~
craftyguy
Sure. But I am still looking forward to seeing it in the kernel tree before
trying it out.

------
oedmarap
> Death to OpenVPN.

> ...nightmares to configure and manage.

This opinion seems a bit overdone. OpenVPN is one of the simplest and robust
VPN protocols to setup and manage in my experience.

If you've had issues with OpenVPN, there are simpler options like Angristan's
OpenVPN script [0] on GitHub to get you started.

I'm not arguing against WireGuard's use case as it's a nifty tool and viable
option. While it's codebase is indeed smaller in size, denigrating a proven
tool like OpenVPN or assuming that everyone is incapable of managing it
because it's "complex" is both unnecessary and incorrect.

[0] [https://github.com/Angristan/OpenVPN-
install](https://github.com/Angristan/OpenVPN-install)

~~~
tptacek
WireGuard is simpler to set up (it's hard to imagine something being simpler
to set up than WireGuard, since its configuration is literally the minimum
amount of information you'd need to build an encrypted tunnel), should be more
robust in practice because of its transport model, is much faster, and is
_optimally secure by default_.

I understand why people like OpenVPN --- their alternative before OpenVPN was
IPSEC, which is a nightmare. What we're telling you is that there's something
even simpler than OpenVPN, and it has the virtue of being materially more
secure.

People should stop using OpenVPN as soon as they can.

~~~
tssva
WireGuard is easy to setup for particular use cases. A small number of
dedicated links or a small number of mobile users.

WireGuard provides the foundation of a complete VPN service. It doesn't
provide features such as user management and authentication, key management,
ip address assignment, client configuration distribution, end-user friendly
VPN clients, support for easily implementing complex split-routing and dns
configurations for VPN end users. And most of those things aren't in progress.
And it is likely there will be multiple solutions competing to provide these
on top of WireGuard, so there may never be on true flavor WireGuard solution.
Also once these are in place the overall attack surface expands to be closer
to OpenVPN and IPsec.

Other issues include lack of support for multicast which means IPv6 which
requires multicast is mostly supported but not completely which can cause
issues in some circumstances.

Accomplishing some simple tasks like using a floating route to provide
failover across two WireGuard links isn't possible. WireGuard interfaces don't
go down unless you manually tear them down, so you either have to run another
tunneling protocol over the WireGuard links and assign your routes to those
interfaces which can go down or use a dynamic routing protocol. And WireGuard
has a few caveats when being used with certain dynamic routing protocols which
starts to make it as complicated as OpenVPN or IPsec at scale.

Currently there is an issue being discussed on the WireGuard mailing list
regarding there currently being a requirement for time to be set on devices
before establishing a first connection to a peer. This is because of an anti-
replay requirement WireGuard has for initial packets which IPsec and OpenVPN
don't. This is impacting a group that was hoping to use WireGuard to encrypt
the traffic across a community wireless mesh network. The devices used in such
networks often don't have a realtime clock. There are potential workarounds
but again suddenly the simplicity advantage starts to slip away.

I think Jason has done great work, I like WireGuard and I use WireGuard, but
it is not near ready to replace OpenVPN or IPsec in most circumstances.

~~~
tptacek
I was careful when I wrote this to talk about who this is important to:
startups that use VPN technology as part of their remote access strategy.
Community wireless mesh networks might need to keep using OpenVPN, or
whatever. But none of the problems you're discussing impact the core use case
startups have for VPNs, which is getting support people to admin apps and
developers to deployment environments.

------
ekianjo
Why death to SSH though?

~~~
CiPHPerCoder
It's not "death to SSH", it's "death to SSH over public Internet".

Instead, what you'll want to be doing is SSH over WireGuard.

~~~
spacenick88
But my SSH already uses Public Keys and ChaCha20/Poly1305 so that's really the
last protocol I worry about sending through hostile territory

~~~
atonse
With Wireguard I believe you can go further and your servers can have only
private IPs. And it's all seamless.

~~~
pritambaral
But the servers have to have a public IP to terminate the wireguard link, or
be connectable from a machine that does. Exactly like SSH, be it via a bastion
host or direct.

------
hapnin
I'm not as well versed as many here (I'm an advanced amateur) but have some
understanding of networks and crypto and am trying to wrap my head around
this.

Can Wireguard be described as an encrypted, stateless, roaming, keypair based
UDP tunnel?

~~~
tptacek
It's a routed tunnel, which is what distinguishes VPNs from encrypted tunnels.

------
ollybee
A benefit unmentioned in this article is full IP roaming on both ends. That is
good on its own but combined with the Android support has some very
interesting possibilities.

~~~
aorth
Yes! Like `mosh` for your VPN. Pretty cool.

------
locusm
Hopefully this means its coming to FreeBSD/pfSense also.

------
StavrosK
Does anyone have detailed instructions/guide on how to set Wireguard up to
allow my laptop to VPN back to my house through an always-on host there
(basically two Ubuntu machines)? I'm not great at networking and I'd rather
not spend hours breaking my entire network trying to set this up.

The "getting started" guide on the website already assumes you can set up your
own routing across the different subnets.

~~~
number6
Just follow the instruction on the video. That's all there is to get it
running.

The archlinux wiki also give some tips but it is really simple

~~~
hamandcheese
The video merely connects two hosts (IIRC). If you want what you expect from a
normal client-server VPN acting as a gateway to a private network, you'll need
to enable IP forwarding on the "server" and ensure routes are correctly
configured on the "client".

~~~
number6
Here is a blog post on this topic:

[https://vincent.bernat.im/en/blog/2018-route-based-vpn-
wireg...](https://vincent.bernat.im/en/blog/2018-route-based-vpn-wireguard)

Didn't tried it myself but it looks solid

------
mmebane
Is there any hope for an implementation that can be run on a Windows/macOS
machine as an unprivileged user, and exposed as a SOCKS5 proxy? I often find
myself wishing for an isolated VPN experience which applies only to a
particular browser, but to all traffic in that browser. Something like Tor
browser, but with my VPN instead of Tor.

------
textmode
[https://en.wikipedia.org/wiki/Back_to_My_Mac](https://en.wikipedia.org/wiki/Back_to_My_Mac)

For comment/discussion.

Not a "recommendation", nor a positive/negative opinion.

Believe it has never been discussed on HN before.

------
jedisct1
And for a VPN with multipath support, check out Glorytun:
[https://github.com/angt/glorytun](https://github.com/angt/glorytun)

Used by OVH routers to efficiently aggregate multiple physical links.

------
joshbaptiste
Most of the time I do not need my whole ip stack to be forwarded over a secure
channel but simply HTTP/s .. here is where SSH/socks proxying suits well for
me in hotels etc..

~~~
lvh
Have you tried both? Particularly on bad hotel WiFi and roaming, wireguard
perf is not comparable to SSH proxying.

~~~
joshbaptiste
ah gotcha.. ok I'll setup wreguard tonight as there is really no need to route
everything via a "tun0" if I don't need to anyway, when I think about it.

------
sandGorgon
it'll be very useful if they build user-facing enterprise security from the
get-go.

How do you build SAML, Oauth/Google-Auth, 2-factor support into a VPN from the
ground up ?

------
euroclydon
Elsewhere in the Latacora blog, Threat Modeling is said to be bad. I'm
interested in a succinct explanation why it's not a useful activity.

------
rdtsc
Any experience with this in an enterprise / DoD domain? ChaCha-Poly algorithm
is not FIPS-140-2 validated from what I understand.

------
kim0
Great news! I wish more smart people would put more effort to technically stop
repressive regimes from blocking VPNs like WG.

------
Bud
So can we get WireGuard as a commercial service? Will anyone roll it out that
way?

~~~
zx2c4
Yes.

[https://mullvad.net/en/blog/2017/9/27/wireguard-
future/](https://mullvad.net/en/blog/2017/9/27/wireguard-future/)

[https://www.azirevpn.com/wireguard](https://www.azirevpn.com/wireguard)

[https://www.privateinternetaccess.com/blog/2018/01/private-i...](https://www.privateinternetaccess.com/blog/2018/01/private-
internet-access-proud-supporting-wireguard-project/)

[http://blackholecloud.com](http://blackholecloud.com)

And more on their way.

------
tzakrajs
macOS _

------
pdxpatzer
If WireGuard is so great (rethorical position, not actually doubting it is)
why isn't there a Kickstart effort or some angel funding to speed up its
development to all platforms ?

~~~
lvh
Wireguard has taken third party funds to expedite development, but as far as I
know the author is pretty adamant all the implementations are freely available
and open source, so maybe angel funds aren’t the best direct way forward.

Disclaimer: I’m a principal at Latacora and we paid the author some money to
make native Mac clients happen. There’s also a VPN provider who paid money
toward development.

I’d rather they did it right than rush it to meet a kickstarter date.

~~~
codezero
Private Internet Access was one of the vpn providers.
[https://www.privateinternetaccess.com/blog/2018/01/private-i...](https://www.privateinternetaccess.com/blog/2018/01/private-
internet-access-proud-supporting-wireguard-project/)

