This morning, Jason Donenfeld, development developer of WireGuard, announces a working in-core implementation of its WireGuard VPN protocol for the FreeBSD 13 core. This is good news for BSD people – and users of BSD-based routers and distros like pfSense and opnSense.
If you are not familiar with WireGuard, it can connect faster than traditional VPNs like OpenVPN. In our personal experience, it is overwhelmingly more reliable if you manage a large number of connections. Your author has usually spent a few hours a month repairing machines and even manually repairing broken OpenVPN tunnels after to write watchdogs to automatically detect and relocate it – to tear it all out and replace this several hundred machine monitoring network with WireGuard-based infrastructure, which reduces to ‘zero hours per month’.
In addition to performance and reliability, WireGuard offers modern protocols, version crypto that literally cannot be set up incorrectly, and a much cleaner, lighter code base than most competitors – Linus Torvalds once declared it a work of art compared to OpenVPN and IPSec .
Politics at its core
Although WireGuard first ended up in the Linux kernel, its inclusion in FreeBSD’s kernel has long been on the general roadmap. In February 2020, FreeBSD developer Matt Macy pushed the first WireGuard-related commitment to FreeBSD. Macy’s work is directly commissioned by Netgate, the company that distributes the BSD-based pfSense router distribution.
After nearly a year of work, Macy’s gateway has been introduced to the kernel scheduled for FreeBSD 13.0 RELEASE, which is expected to launch in 15 days. Unfortunately, there was a problem – after WireGuard’s own Jason Donenfeld reviewed it with several FreeBSD and OpenBSD developers, it failed for the first time:
I imagined strange internet voices shouting, “this is what gives C a bad name!” Random sleeping places have been added to “fix” racial conditions, validation functions that are just right, catastrophic cryptographic vulnerabilities, unimplemented parts of the protocol, kernel panic, security redirects, overflow, random printf statements deep in the crypto-code overflow , and the whole litany of horrible things that go wrong when people are not careful when writing C.
This is, understandably, a big problem for Donenfeld – although the WireGuard protocol itself is open source, there is more than one code in a project. Much of what prompted the meteoric rise of WireGuard in the first place was the brevity and correctness of the code, as judged by Linux founder Linus Torvalds and reflected by the project’s reliability and lack of major bugs since it became popular has. A less-than-stellar implementation in FreeBSD could damage WireGuard’s brand – possibly irrevocably.
This left the FreeBSD gate between a rock and a hard place – Donenfeld felt the Netgate-sponsored code was not ready for public consumption, but Netgate has already announced WireGuard support in the upcoming pfSense 2.5.
Mindful of Netgate’s exposed position, Donenfeld reached the core of FreeBSD developers Kyle Evans and Matt Dunwoodie, and the three embarked on a crazy, week-long sprint to bring the problematic code up to standard. Donenfeld describes one part of the process:
… there are 40,000 lines of optimized crypto implementations drawn from the Linux kernel reconciliation module, but not really properly connected, and irreparably with Linux → FreeBSD ifdefs mails. I wound up replacing it with an 1800 line file, crypto.c, which contains all the cryptographic primitives needed to implement WireGuard.
This is very much in line with Donenfeld’s usual coding operand mode– The reason why WireGuard on Linux is 4,000 code rules for OpenVPN’s 400,000 has a lot to do with eradicating inherited cruft and replacing it with just enough strictly focused code to do the job.
Unfortunately for Netgate, it does not look like his sponsored code or the week-long sprint by Donenfeld, Dunwoodie and Evans will make it into FreeBSD 13.0. The FreeBSD team, presented with one deeply flawed port and another major upheaval, will most likely disable the WireGuard module for 13.0-RELEASE and visit again for 13.1-RELEASE.
Controversy in the past and current development
It was clear that this collaboration was not smooth. Donenfeld expressed frustration over Netgate’s failure to reach out to him directly, and – once he discovered their mission – a lack of interest in working with him:
They did not bother to reach out to the project. That’s fine, I thought, I’ll reach out and see if I can help and coordinate. What followed the following year was a series of poor communication – unanswered messages, code reviews ignored, something like that. […] At some point, the code that was there merged into the FreeBSD tree and the developer who had to write the task continued.
This is a fairly typical open source conflict of interest – project A hires developer B to do x hours of work, but related project C says it takes x * 2 hours of work to do it right. With good communication lines and a minimum of ego, there is usually a way to resolve this kind of conflict, but a problematic history like that of Netgate can damage those communication lines.
Despite back and forth, this gateway should be considered a classic success story for open source software development. Netgate’s initial developer commission turned the ball around for an extremely valuable addition to the FreeBSD core. The commission has again aroused interest and great follow-up work from both WireGuard and FreeBSD core developers, and it will ultimately result in a reliable, high-quality WireGuard gateway for users of FreeBSD as well as Netgate.