The FOSDEM web site includes a synopsis of this talk [0], along with the video, slides (PDF) [1] and a "demo screencast" (MP4/video) [2].
It's a good talk and WireGuard is quite interesting. IPSec, OpenVPN, et al., are great but I definitely think there's a need for a high-performance, high-security, easy to configure VPN.
The demo is only two and a half minutes long, check it out.
Edit: Also found zx2c4's technical whitepaper, "WireGuard: Next Generation Kernel Network Tunnel". Just started to look over it but it appears to have all the juicy details.
"IPSec, OpenVPN, et al., are great but I definitely think there's a need for a high-performance, high-security, easy to configure VPN"
I really like sshuttle.[1] Very simple - just point it at any host anywhere on the net that has an sshd running.
We (rsync.net) have recently sponsored some bug fixes and freebsd-specific improvements that allow --dns to work as well as generalized UDP tunneling. I'm testing it right now ...
A long-time kernel developer happened to be sitting next to me, while I was listening to this talk at FOSDEM last weekend, and he politely pointed out after the talk (paraphrasing): "Hmm, I'm not quite convinced -- this lives in the Kernel, and if it's compromised, then it's game over."
PS: Day-21 of QEMU Advent Calendar 2016 was WireGuard (contributed by: Jason A. Donenfeld and Stefan Hajnoczi) -- http://www.qemu-advent-calendar.org/2016/#day-21 -- "This image runs iperf inside containers & prints out the performance statistics along with commands used to configure the VPN."
I'm really thrilled with WireGuard. It's small, easy to audit, easy to setup, and it is using the Noise protocol which uses trusted cryptography primitives by DJB. I hope it can be merged into the mainline Linux kernel once it stabilizes.
i've read up on wireguard a week or so ago. it seems awesome. i've rarely been so excited about new software/protocol. the design philosophy feels so right.
a few months ago i concluded i needed a secure vpn to servers. ipsec seemed the better option. but i haven't set it up yet. it all seems so complicated for what i want to achieve: a simple secure tunnel between a few machines.
hopefully we'll get easy to use software for macos/windows. no idea how hard that is to create (i.e. adding tunnel types to these OS'es so you can easily add a tunnel and configure them).
Have a look at zerotier then. It's user space, so no kernel requirements. It's super simple: start up the servers and join a network you create on the website. All the traffic still goes directly if possible. Lots of clients available for popular platforms.
ZeroTier is cryptographically inferior to Wireguard, but also isn't really a VPN: it has centralized configuration and rendezvous. If you're running VPNs to get the US Netflix from your UK vacation, this is probably fine. If your VPN is how remote employees access your prod network, it is way less fine.
I think it's a bit unfair to judge ZeroTier in comparison to VPNs, because that's not strictly speaking what it's trying to be. I like overlay networks!
I actually would love to hear more about your perspective on the crypto used in Zerotier and why it shouldn't be used for remote workers and those sorts of things.
I've been a user for quite a while and it's been really nice (and generally I've really only had trouble using Zerotier on really locked down wifi networks), but given their Technical FAQ info it sounds pretty convincing to a lay non-security-expert person that it is relatively secure:
https://www.zerotier.com/tech_faq.shtml#security
As far as using it for remote workers, in comparison to how our current VPN option at work functions (currently a SonicWall Firewall/VPN) it definitely seems to work more easily/consistently so it's been something I've wanted to share so we can try out (but if there are big security issues with doing so I'm sure myself and others would love to get your thoughts on Zerotier in particular).
I agree about the cryptography part of course. But I'm not sure about other points. You can run your own directory nodes, rather than use the public ones, so in practice the model looks like OpenVPN replacement. Is there a reason apart from the cryptography part why you wouldn't want to use it for remote workers?
Sure, it does much more, and it's probably better to call it an SDN / overlay. But if you can call OpenVPN a VPN, then I think ZT can do VPN as well.
Your comment would be just as informative if it ended after the first sentence.
The presentation answers most of this:
* An extremely small, auditable-in-an-afternoon codebase. The code is 1% as large as XFRM/StrongSwan IPSEC.
* Designed from inception to eliminate memory corruption and state machine bug classes; for instance, all allocation is per-peer at-config static.
* A simplified, modern crypto stack with no cipher agility and thus no downgrade attacks (and, again, an extremely small codebase) --- this also drastically simplifies configuration.
* A DOS-resistant forward-secure protocol based on Trevor Perrin's NoiseIK.
* Direct integration into the Linux networking stack, so that VPN tunnel interfaces appear to management tools just like other interfaces, and policy can be expressed using standard iptables and IP routing tools rather than poorly duplicated in the VPN software.
I didn't write "runs in kernel" as a benefit. I wrote "directly integrated with Linux networking stack". It's actually not the case that the other VPN alternatives integrate as seamlessly with Linux networking tools as Wireguard.
Yes, I understand the performance gain. But the difference here with respect to management, presumably, would be that when this is loaded/compiled in the kernel, less userspace setup would be required -- correct? I'm assuming it would just show up like an available network device at boot. I need to watch the talk still.
I know doing the same for TUN/TAP is not a leap really, but it's one more thing to have to consider. Also I have no idea what the performance implications of TUN/TAP are either (although I frequently use both, I've never measured it).
> But the difference here with respect to management, presumably, would be that when this is loaded/compiled in the kernel, less userspace setup would be required -- correct? I'm assuming it would just show up like an available network device at boot.
No, you have to explicitly add the interface with the wg command, much like you have to explicitly run a command that starts a TUN/TAP VPN. And once those commands are run, both WireGuard and TUN/TAP interfaces look just like normal interfaces and can be managed using standard tools.
WireGuard could be implemented in user space and be just as easy to use and manage. The only benefit from running in kernel space is performance.
But I'm sure we'll look at wireguard again at some point, but while the website says this: "WireGuard is not yet complete. You should not rely on this code." I'll stick with being conservative and using what we already know and trust.
Candidly: it seems weird to me that anyone would prioritize something like DMVPN over escaping the IPSEC ecosystem as soon as possible. IPSEC --- including Cisco's IPSEC products --- is terrifying.
So I've caught flack for choosing an OpenSSH "native" VPN (where it sets up TUN/TAP for you on both ends, etc..) over IPSec before.
While I'm sure it's probably lower performance, if you've ever done more than just plug and play some Cisco IPSec stuff (e.g. manually implement IPsec on Linux), it is terrifying in its complexity, IMO, for something you depend upon so critcially.
It's not just a performance problem. OpenSSH's VPN works by encapsulating either IP packets (tun) or Ethernet frames (tap) in TCP. Now you suffer from head of line blocking and nested congestion control. If you want an easy to use userspace VPN use OpenVPN. It may be bloated, but it works a lot better than IP over TCP can ever work.
ipsec/ike2/isakmp are implemented in kernel afaik, with userspace tools to control them and they're used pretty heavily in commercial scenarios(for office to office vpn or vpn into cloud tenancy etc). OpenVPN/Tinc etc are userspace and seem to be popular for consumers as they require less coupling and relatively easy to setup.
In terms of whether that's good or bad, it depends on your requirements and what's optimal to you. If you think about the problems in OpenSSL, which backs OpenVPN, then that's been a fairly large attack surface vector. Compare that to ipsec/ike2 kernel related vectors and weigh up the setup/learning/deployment costs of both.
Security wise? Doesn't matter. WireGuard does not add any meaningful attack surface, and you'd be pretty screwed anyway if your non-kernel-level VPN server got hacked.
Performance wise? If you want it to be usable it's pretty necessary.
It's a good talk and WireGuard is quite interesting. IPSec, OpenVPN, et al., are great but I definitely think there's a need for a high-performance, high-security, easy to configure VPN.
The demo is only two and a half minutes long, check it out.
Edit: Also found zx2c4's technical whitepaper, "WireGuard: Next Generation Kernel Network Tunnel". Just started to look over it but it appears to have all the juicy details.
[0]: https://fosdem.org/2017/schedule/event/wireguard/
[1]: https://fosdem.org/2017/schedule/event/wireguard/attachments...
[2]: https://fosdem.org/2017/schedule/event/wireguard/attachments...
[3]: https://www.wireguard.io/papers/wireguard.pdf