7 ms·
BoringTun, a Userspace WireGuard Implementation in Rust
- FredFS456 8y agoJason also sent an email to the WireGuard mailing list addressing this. [1] In the email, he stated that Cloudflare repeated refused to work directly with him and his team as part of the upstream project. [1] https://lists.zx2c4.com/pipermail/wireguard/2019-March/004048.html https://lists.zx2c4.com/pipermail/wireguard/2019-March/00404...
- xiphias2 8y agoLet's see how it continues, so far it looks like compatibility was an important goal of the Cloudflare team.
- newaccoutnas 8y agoYes, that's unfortunate and I think he's handled it well there. It was the same with the guy who did a windows implementation, didn't want to work with the upstream so is rife for fragmenting the protocol long-term
- _pmf_ 8y agoI don't get what's unfortunate about it. Cloudflare is probably being upfront about their implementation suiting their needs; I think it's laudable and avoids bad blood in the future, should the goals diverge. Given that WireGuard has been designed to be relatively simple, maybe multiple widely used implementations will make sure it stays that way.
- newaccoutnas 8y agoBecause they've refused to engage with the upstream, it puts them in the 'driving seat' as it were as their available resource eclipses the community's.
- SEJeff 8y agoThe official upstream windows implementation is making excellent progress however. In specific, WinTUN[1] was just released. Disclaimer: My employer sponsored a lot of the work with Jason for the windows wireguard port. (Search for "Accelerating Windows Development on https://www.wireguard.com/donations/ https://www.wireguard.com/donations/) [1] https://lists.zx2c4.com/pipermail/wireguard/2019-March/004038.html https://lists.zx2c4.com/pipermail/wireguard/2019-March/00403...
- dochtman 8y agoIt's interesting that this seems to mirror our experience with Cloudflare's Rust implementation of QUIC: https://news.ycombinator.com/item?id=19019150 https://news.ycombinator.com/item?id=19019150
- CodeWriter23 8y agoOne of CloudFlare's goals is to have a BSD-Licensed result. Seems reasonable to maintain isolation from the core WireGuard team that is publishing under GPL to support that goal, just to ensure they don't accidentally end up with GPL code in their codebase.
- nightfly 8y agoThat is a reasonable explanation, if that's the case it would be great if CloudFlare just came out and said that instead of being vague about it.
- zx2c4 8y agoWith the exception of the kernel-specific code, we're actually pushing more and more of our stuff as MIT/Apache2 licensed. If there's a project we haven't done that to yet that's not permissively licensed, just email team at wireguard dot com or ask on the mailing list. wireguard-go, for example, is MIT.
- xucheng 8y agoIt seems that the official rust implementation wireguard-rs[1] is currently GPL licensed. [1]: https://github.com/WireGuard/wireguard-rs https://github.com/WireGuard/wireguard-rs
- LinuxBender 8y agoWhat does the context switching overhead look like in this implementation, vs kernel space? Are there any throughput graphs comparing the two?
- thecompilr 8y agoIt is still quite expensive, the kernel module is still faster. Performance depends a lot on your kernel version and network card. We measured anywhere from 20% to 40% advantage to kernel module. But we are working on additional performance features, such as using send/recvmmsg and raw sockets.
- LinuxBender 8y agoThankyou, that is even better than what I would expect. I have been trying to tune around similar issues in tinc-vpn which also runs in user space and depends on newer kernels and code changes to work around.
- ilovecaching 8y agoWhy not use XDP?
- zoobab 8y agoLook at curvetun, the author used some tricks to boost the speed (PF_RING I think).
- rapsey 8y agoBlog post mentions windows support but there is no real code support for it. Will it eventually be ported?
- thecompilr 8y agoCurrently the library part supports Windows, and it can be used from C# or C++, if you want to use something like https://docs.microsoft.com/en-us/uwp/api/Windows.Networking.Vpn https://docs.microsoft.com/en-us/uwp/api/Windows.Networking.... However there is no native support for tunnel interfaces in Windows, and we are still thinking about the best way to add full support. The WireGuard project for example developed a whole new driver just for that. Don't know if we are going to follow that route.
- gok 8y agoNice, Rust is a great fit for this kind of project.
- AceJohnny2 8y agoI've been interested in using WireGuard for a while, though I don't really have a use-case for it currently. In the interest of honest understanding, what would be reasons not to use WireGuard over existing VPN software (excluding the obvious legacy interop) ?
- atonse 8y agoI am a huge fan of Wireguard and use on all the major production servers I currently manage. But user management is exactly as sophisticated as SSH key management. That is to say, easy for 2-3 people, a pain otherwise. There are attempts at creating UI based user managers for wireguard, and I hope those go somewhere. I bet the major wireguard-supporting VPN providers have solved this problem for themselves though. Update: Just wanted to add that I don't think that user management (the work of actually provisioning and managing users) should fall under the umbrella of Wireguard. It's perfect the way it is. But I suspect there will be an ecosystem of tools that come up around it.
- AceJohnny2 8y agoThanks, this is exactly the kind of useful information I was looking for. (this wouldn't be an issue for my personal use, but it's useful to be aware of it)
- jandrese 8y agoIt's not an issue for like 95% of the users, which is why Wireguard went that way. For the people who really need something better they are left to figure it out for themselves. Normally this is OK, but sometimes it leads to situations like PGP Email where key distribution is never really solved and the whole thing kind of lumbers around in a half dead state forever.
- tptacek 8y agoWireGuard is currently in a place where it works really well for site-to-site VPNs (where network/devops engineers are the only ones interacting with it directly, and it's just magic for everyone else) and for access (laptop-to-VPC) VPNs for engineers. It's not yet in a place where I'd recommend it for access VPNs for, say, support staff. It's more pleasant to use and manage than SSH or SSH tunnels (this is surprising and speaks to what an achievement WireGuard is and why people are so nuts about it), so if you calibrate your tooling/slickness expectations accordingly, you should do fine with it.
- atonse 8y agoUnfortunate that Cloudflare didn't just contribute time to the first party wireguard-rs client. But it's their wish to do what they want with their engineers. Nonetheless, it's great that Wireguard have a path to a solid user space implementation that others could build from. Jason Donenfeld's post about this surprised me when he said the go implementation is flaky. Is the health of the non-kernel parts of wireguard not great? The macOS clients work really well for me.
- zx2c4 8y agoThe Go implementation is fine. I don't think you have much to worry about. But we're pretty frequently running into limitations and fighting with the runtime; we've submitted quite a few random patches to it. I think Rust is probably a better-suited language for a high performance and relatively secure WireGuard implementation. Hence, we'd really like to have a strong first-party Rust implementation for the project.
- BFLpL0QNek 8y agoHaven't looked at the other implementations yet but with wireguard-go I've been struggling to run it as non root on OpenBSD. I've created a _wireguard user+group, setup a /dev/tun0 interface to have the _wireguard group with read/write however from the little tracing i've done it looks like I still need root when it tries to do the unix sys call to set the MTU.
- merb 8y agois really wireguard that better than other VPNs? I always wondered if there is need for a "better" vpn. I mean a more reliable VPN is probably needed, i.e. something that isn't detectable. However I guess wireguard has all the problems than most VPNs once it's known how it works it's detectable with a DPI. What I probably want to see is a VPN over h2c or over quick, its probably impossible to detect it, it looks like regular web traffic.
- akerl_ 8y agoIIRC, Wireguard doesn't target "undetectability" as a feature. Wireguard is better than other VPN software because it's intentionally minimal, with a small set of crypto in-use and simple design choices, leading to small easily-auditable codebases. It's also got a pretty straightforward set of config options without a barrage of tunables, which makes it pretty much impossible to subtly misconfigure things in a way that harms security.
- viraptor 8y agoYou'll always be able to tell VPN traffic from the rest due to behaviour patterns. If you can tell apart Netflix movies from packet sizes/timing, you can easily tell when something's a persistent tunnel for various connections (i.e. VPN). The only way would be to keep the pipe continuously saturated with some padding while you're not sending real data... But is that worth it?
- SEJeff 8y agoWireguard focuses on being a better vpn where better is vaguely defined as using modern crypto in a way that is hard to get wrong. As a result, it is a lot simpler with far fewer bells and whistles. This means it tends to be orders of magnitude faster than an equivalent usage of say openvpn (I measured 15mbps vs 52mbps awhile back with openvpn and wireguard respectively). What you want is a slightly different albeit very important problem to solve reliably.
- swinglock 8y agoYes. Besides being fast and small, it connects very quickly, does seamless roaming and works without keepalives, making it incredibly well suited for mobile clients.
- jedisct1 8y agoIs the name resemblance with GloryTun (another VPN) just pure coincidence?
- zamadatix 8y agoAccording to the blog post: "The name might sound a bit boring but there's a reason for it: BoringTun creates a tunnel by 'boring' it. And it’s a nod to Google’s BoringSSL which strips the complexity out of OpenSSL. We think WireGuard has the opportunity to do the same for legacy VPN protocols like OpenVPN. And we hope BoringTun can be a valuable tool as part of that ecosystem." so coincidental.
- gorset 8y agoNice to see more userspace implementations of wireguard. I've been testing out wireguard's linux kernel module, but experienced too much jitter due to wireguard not respecting isolcpus. Probably possible to make the kernel module behave, but working with userspace is so much easier. Wireguard-go seems to behave (the drop in performance is not necessarily a showstopper), although the description says that it shouldn't be used on Linux :-) Would be nice if a high performance rust implementation can become a real alternative. A userspace implementation shouldn't need to be much slower than a kernel module if network card with kernel bypass is available, if you really need that extra performance.
- zoobab 8y agoAny Dockerfile?
- zamadatix 8y agoOpen Issue https://github.com/cloudflare/boringtun/issues/38 https://github.com/cloudflare/boringtun/issues/38
- zoobab 8y agoOpenVPN is a piece of shit performance wise, the best userspace VPN tool I tested was curvetun. It was moving encrypted gigabit speeds with very low CPU usage on MIPS openwrt routers. http://netsniff-ng.org/ http://netsniff-ng.org/
- geogriffin 8y agoLooks like pretty good code, but interesting that they only have a few dependencies and decided to implement a lot of stuff, like kernel polling, themselves rather than using the mio crate. I wonder why. They also implemented the noise handshake in a non-generic way tightly coupled to wireguard protocol, again written themselves instead of using an external dependency, which I think is also the approach other wireguard implementations have taken.. which is fine, but harder to independently verify. There's a lot of code there.
- thecompilr 8y agoI have been getting the mio question a lot. Mio, in theory, is not very far off of what I ended up implementing, but it is missing a few features that I really needed, and building those features on top of Mio would be harder than just using epoll/kqueue directly. Also I don't understand the fear people have of using epoll/kqueue. Those are very basic features that every engineer has to know how to use. So what are the features: No locks - Mio polls under lock, but epoll/kqueue are multithread safe by nature as long as you use the correct filters. Mio has considerable overhead over pure epoll/kqueue. No need for tokens, instead I store closure pointers. Real zero overhead. Of course I could cast pointers to usize and use as Mio tokens, but I would still have to build the ownership model on top, which is most of the work anyway. Timers in Mio run in a thread??? I use platform idiomatic conventions instead, which with kqueue require direct access to kqueue. Signal handlers, can't make idiomatic one with Mio (or maybe I missed how). Same with notifications. Could use something awkward like a channel, but prefer idiomatic approach.