Enlarge /. FreeBSD will get its own WireGuard module in the kernel in the near future, thanks to a sponsored code contribution from Netgate, followed by additional code and a review by Jason Donenfeld and several FreeBSD and OpenBSD developers.
This morning, WireGuard founding developer Jason Donenfeld announced a working in-core implementation of its WireGuard VPN protocol for the FreeBSD 13 kernel. This is great news for BSD users – and users of BSD based routing appliances and distributions like pfSense and opnSense.
If you're not familiar with WireGuard, connections will be established faster than traditional VPNs like OpenVPN. In our personal experience, it is overwhelmingly more reliable even when managing a large number of connections. Its author spent several hours a month bombarding machines and manually rebuilding broken OpenVPN tunnels, even after writing watchdog scripts to try to automatically detect and rebuild them. The surveillance network with WireGuard-based infrastructure reduced this to "zero hours per month".
In addition to performance and reliability, WireGuard offers modern protocols, versioned crypto that literally cannot be set up incorrectly, and a much cleaner and lighter code base than most of its competitors – Linus Torvalds once declared it a "work of art" compared to OpenVPN and IPSec.
Policy in the kernel
Although WireGuard first landed in 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 for FreeBSD. Macy's work was commissioned directly from Netgate, the company behind the BSD-based pfSense router distribution.
After almost a year of work, Macy's port has been imported into the kernel planned for FreeBSD 13.0-RELEASE, which is expected to start in 15 days. Unfortunately, there was an issue – after WireGuard's Jason Donenfeld reviewed it with several FreeBSD and OpenBSD developers, it wasn't rated for prime time:
I imagined strange internet voices mocking, "That gives C a bad name!" Random hibernation states have been added to "fix" the race conditions, validation functions that have just returned real ones, catastrophic cryptographic vulnerabilities, entire parts of the protocol that were not implemented, kernel panics, security bypasses, overflows, random printf statements deep in the Cryptocode, the most spectacular buffer overflows, and the whole litany of horrific things that go wrong when people aren't careful when writing C.
Understandably, this was a big problem for Dönfeld – although the WireGuard protocol itself is open source, a project contains more than just code. Much of what primarily fueled WireGuard's meteoric rise is its brevity and code correctness, which was rated by Linux founder Linus Torvalds and is reflected in the project's reliability and lack of major flaws since its popularity. A less than outstanding implementation in FreeBSD could damage the WireGuard brand – possibly irrevocably.
This left the FreeBSD port stuck between a rock and a hard place – Donenfeld believed the Netgate sponsored code wasn't ready for public consumption, but Netgate had already announced support for WireGuard in the upcoming pfSense 2.5.
Given Netgate's exposed position, Donenfeld reached out to FreeBSD core developers Kyle Evans and Matt Dunwoodie, and the three of them went on an insane weeklong sprint to update the problematic code. Dönfeld describes part of the process:
… 40,000 lines of optimized crypto implementations were pulled from the Linux kernel compatible module, but not properly wired and irreparably distorted with labyrinths from Linux → FreeBSD ifdefs. I've replaced this with a 1,800 line file [crypto.c] that contains all of the basic cryptographic elements required to implement WireGuard.
This is in line with Donenfeld's usual coding mode – the reason WireGuard has 4,000 lines of code on Linux for OpenVPN's 400,000 has a lot to do with removing inherited Cruft and replacing it with just enough focused code to get the job done.
Unfortunately for Netgate, neither the sponsored code nor the weeklong sprint from Donenfeld, Dunwoodie, and Evans seem to make it into FreeBSD 13.0. The FreeBSD team will most likely completely disable the WireGuard module for 13.0-RELEASE and revisit it for 13.1-RELEASE with a badly bugged port and another massive overhaul.
Past Controversy and Current Development
This collaboration was clearly not going smoothly. Dönfeld expressed frustration at Netgate's failure to contact him directly and – as soon as he discovered their commissioned port – about a supposed lack of interest in working with him:
They didn't bother to achieve the project. That's okay, I thought, I'll 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 added to the FreeBSD tree and the developer who wrote 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 some way to resolve this type of conflict – but a problematic story like Netgate's can easily damage those lines of communication.
Despite the back and forth, this port should be viewed as a classic success story for open source software development. The initial developer commission from Netgate kicked off an extremely valuable addition to the FreeBSD kernel. This commission, in turn, generated interest and important follow-up from both WireGuard and FreeBSD core developers and will ultimately result in a high quality, reliable WireGuard port for FreeBSD users as well as Netgates.