This morning, WireGuard founder Jason Donenfeld announced a working, in-kernel implementation of his WireGuard VPN protocol for the FreeBSD 13 kernel. This is great news for BSD folks – and users of BSD-based routing appliances and distros like pfSense and opnSense.
If you’re not familiar with WireGuard, it establishes connections faster than traditional VPNs like OpenVPN. It is also, in our personal experience, overwhelmingly more reliable at managing large numbers of connections. Your author used to spend several hours a month shelling machines and manually repairing broken OpenVPN tunnels, even after writing watchdog scripts to try to detect and reset them automatically – taking it all out and replacing this surveillance network of hundreds of computers with WireGuard-based infrastructure reduced that to ‘zero hours per month’.
In addition to performance and reliability, WireGuard offers modern protocols, versioned crypto that literally can’t be misconfigured, and a much cleaner, lighter codebase than most competitors – Linus Torvalds once called it “a work of art” compared to OpenVPN and IPSec.
Politics at the core
Although WireGuard was the first to get into the Linux kernel, its inclusion in the FreeBSD kernel has long been on the general roadmap. In February 2020, FreeBSD developer Matt Macy pushed the first WireGuard-related commit to FreeBSD. Macy’s work was commissioned directly from Netgate, the company behind the BSD-based pfSense router distribution.
After nearly a year of work, Macy’s port was imported into the kernel planned 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 was found to be unready for prime time:
I imagined strange internet voices yelling, “This is what gives C a bad name!” Added random sleeps to “fix race conditions”, validators that just returned true, catastrophic cryptographic vulnerabilities, whole parts of the protocol not implemented, kernel panics, security bypasses, overflows, arbitrary printf statements deep in cryptocode, the most spectacular buffer overflow, and the whole litany of terrible things that go wrong if people aren’t careful when they see C.
This was understandably a big deal for Donenfeld – while the WireGuard protocol itself is open source, there’s more to a project than just the code. Much of what propelled WireGuard’s meteoric rise in the first place is the brevity and correctness of the code, as reviewed by Linux founder Linus Torvalds and reflected by the project’s reliability and lack of major flaws since it became popular. . A less-than-great implementation in FreeBSD could damage WireGuard’s brand – possibly irreversibly.
This left the FreeBSD port trapped between a rock and a hard place – Donenfeld believed the Netgate-sponsored code wasn’t ready for public consumption, but Netgate had already announced WireGuard support in the upcoming pfSense 2.5.
Aware of Netgate’s exposed position, Donenfeld reached out to key FreeBSD developers Kyle Evans and Matt Dunwoodie, and the three dug in for a frenzied week-long sprint to bring the problematic code up to scratch. Donenfeld describes part of the process:
… there were 40,000 lines of optimized crypto implementations taken from the Linux kernel compat module, but not really plugged in properly, and corrupted beyond repair with mazes of Linux → FreeBSD ifdefs. I eventually replaced this 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 mode operand-the reason WireGuard on Linux is 4,000 lines of code to OpenVPN’s 400,000 has a lot to do with removing inherited cruft and replacing it with just enough tightly targeted code to do the job.
Unfortunately for Netgate, neither the sponsored code nor the week-long sprint by Donenfeld, Dunwoodie, and Evans seem likely to make it into FreeBSD 13.0. Presented with a very flawed port and another massively rushed overhaul, the FreeBSD team will most likely disable the WireGuard module completely for 13.0-RELEASE and revisit for 13.1-RELEASE.
Past controversy and current development
Obviously, this collaboration did not go smoothly. Donenfeld expressed some frustration at Netgate’s failure to contact him directly, and—once he discovered their assignment—a perceived lack of interest in working with him:
They didn’t bother to contact the project. That’s okay, I thought, I’ll get in touch and see if I can help and coordinate. What followed over the next year was a series of bad communications – unanswered messages, ignored code reviews, that sort of thing. […] at some point, the code lying around was merged into the FreeBSD tree and the developer in charge of writing it moved on.
This is a pretty 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 get it right. With good lines of communication and a minimum of ego, there is usually a way to resolve these kinds of conflicts, but a problematic history like Netgate’s can easily damage those lines of communication.
Despite the back and forth, this port should be considered a classic open source software development success story. Netgate’s initial developer committee got the ball rolling for an extremely valuable addition to the FreeBSD kernel. That committee, in turn, attracted interest and great follow-up from both WireGuard and FreeBSD core developers, and it will ultimately result in a high-quality, reliable WireGuard port for FreeBSD users – as well as for Netgates.