WireGuard Could Soon Be On Its Way To The Linux Kernel

[starshipeleven]

Can this thing be made cross-platform compatible at the protocol level so we could have non-Linux clients using it?

Yes, it's planned to have some Rust/Go/Haskell implementations too. https://www.wireguard.com/xplatform/

Additionally, I'm not 100% sure why it has to be in-kernel to work. That seems to open additional potential security holes above & beyond the headaches you can already get with something like OpenVPN.

Because it uses in-kernel crypto infrastructure. How does that open security holes? It's just making calls to the kernel.

The userspace implementations will not have comparable performance, but will be good enough for clients and low-traffic servers.

[L_A_G]

Maybe I'm wrong, but to me OpenVPN has always felt more than a bit hacked-together and that was only enforced a couple of months ago when I needed to cross-compile it for an ARM-based system. Not only did I get a first hand experience in how heavily reliant on OpenSSL, I got a very good lesson in why Meson exists (cross compiling it with GNU Make is a surprisingly huge pain in the you-know-what).

Considering this, I hope WireGuard is as good as people say it is.

[parad0x]

I already run wireguard in my lede(openwrt) router. and on all my main machines, rpi. it's awesome.
The only thing I miss is the possibility to specify multiple possible endpoints for a peer.

[uid313]

On GitHub and Docker Hub there are some docker images that you can just get that is configured with Libreswan that you can upload to Amazon, Azure, or any other cloud that does Docker.

https://github.com/hwdsl2/docker-ipsec-vpn-server

[FishB8]

Been using this for about 6 months. Very fast and easy to manage. Even set up a vxlan overlay network on top of the wireguard vpn connections between multiple servers in different locations. Road warrior roaming between different ip connections works seamlessly. Can't say enough good things about the project and Jason Donenfeld.

[notanoob]

Yes, it's planned to have some Rust/Go/Haskell implementations too. https://www.wireguard.com/xplatform/
Because it uses in-kernel crypto infrastructure. How does that open security holes? It's just making calls to the kernel.

It could open up security holes in how wireguard is implemented in kernel. See if wireguard calls a proven to be safeish kernel crypto API then there's no assurance of no bugs in the wireguard usage of that API. But the rust implementation sounds very nice, especially over openVPN.

The userspace implementations will not have comparable performance, but will be good enough for clients and low-traffic servers.

It doesn't need to be in the kernel and it could have much better performance and cross-platform compatibility for unix systems if it used crypto-dev to access in kernel API's for crypto. It also would then get hardware acceleration for crypto when available making it even faster.

[zx2c4]

it could have much better performance and cross-platform compatibility for unix systems if it used crypto-dev to access in kernel API's for crypto

This isn't actually true at all in the context of a virtual network device, since doing it in userspace still presumes the requirement of a the tun device, hence context switches and memory copies, which are massive overheads. On this basis, alone, I don't think what you're saying is correct.

I've just spent 5 minutes looking at the cryptodev-linux driver source, which isn't a lot of time, but from a cursory glance, adding cryptodev into the mix would actually result in even worse performance, since it'd add an additional context switch, and it's not obvious to me how CIOCAUTHCRYPT could be made to work with splice(2) and the WireGuard Protocol so as to entirely avoid all context switches / userspace processing. As far as I can see, it looks like there are even TLS-specific and SRTP-specific rules in the cryptodev module itself, in order to speed up those use cases. If you have specific ideas that I might have overlooked during a quick glance on how this could be used to entirely eliminate all context switches and memcpys, without introducing new kernel code, please do let me know.

[notanoob]

as to entirely avoid all context switches / userspace processing. As far as I can see, it looks like there are even TLS-specific and SRTP-specific rules in the cryptodev module itself, in order to speed up those use cases. If you have specific ideas that I might have overlooked during a quick glance on how this could be used to entirely eliminate all context switches and memcpys, without introducing new kernel code, please do let me know.

Well I was originally mentioning it for the userspace implementations of Wireguard in rust or some such language. You wouldn't have to deal with as much of the context switching if you used a entirely userspace application. It would also be slightly more secure in that it doesn't have access to the rest of the kernel functions. Just those from userspace unless it is run as root or with SUID enabled. I wonder why openVPN doesn't do something like this? Or maybe they do and I am just not aware of it.

[zx2c4]

You wouldn't have to deal with as much of the context switching if you used a entirely userspace application.

This is where I believe you're a bit confused about how userspace virtual networking drivers work, and the requirements for TUN-based devices, such as OpenVPN. VPN tunnel interfaces give you a virtual network interface. If you do it in the kernel, great, no additional context switches. If you do it in userspace, then you're stuck with drivers/net/tun.c, with context switching and memory copying overhead. That's just how it is.

If you want to go further, or think my explanations here aren't very good, you can find me on IRC -- I'm zx2c4 on Freenode in #wireguard.

[starshipeleven]

It could open up security holes in how wireguard is implemented in kernel. See if wireguard calls a proven to be safeish kernel crypto API then there's no assurance of no bugs in the wireguard usage of that API.

It has a tiny codebase as it uses kernel features to do the leg work. It is MUCH easier to audit and keep in check than multi-headed monsters like OpenVPN+OpenSSL.

It doesn't need to be in the kernel and it could have much better performance

This is plain wrong, anything is faster if properly integrated and run in-kernel.

cross-platform compatibility for unix systems

Quite frankly, I'm sick of performance/security-critical cross-platform programs being done for ideological reasons (to not leave out BSDs or something).
To be cross-platform you can't use many neat Linux kernel features that do impact performance/security and make your life easier. As long as you are making basic stuff like commandline tools it's ok, but for anything serious no.

In the case of Wireguard it's likely much better (and imho easier/safer) to have a FreeBSD "port" or "equivalent" (re-written) that is customized for FreeBSD kernel.
At the end of the day the only thing that matters for Wireguard is the protocol it shows to other nodes on the network, any program using that protocol can communicate, regardless of it being running in Linux, on with Rust on Windows or in FBSD.