This morning, WireGuard’s founding developer Jason Donenfeld announced a functional kernel implementation of his WireGuard VPN protocol for the FreeBSD 13 kernel. This is great news for BSD folks – and users of based routing devices. in BSD and distros, such as pfSense and opnSense.
If you are not familiar with WireGuard, it establishes connections more quickly than traditional VPNs, such as OpenVPN. It is also, in our personal experience, extremely more reliable when managing a large number of connections. Its author used to spend several hours a month bombing machines and manually reinstating broken OpenVPN tunnels, even after write watchdog scripts to try to automatically detect and restore them – eliminating everything and replacing this monitoring network of several hundred machines with the WireGuard-based infrastructure, reducing this to “zero hours a month”.
In addition to performance and reliability, WireGuard features modern protocols, versioned encryption that literally cannot be configured incorrectly, and a much cleaner and lighter code base than most competitors – Linus Torvalds once declared that it is “a work of art “compared to OpenVPN and IPSec.
Kernel policy
Although WireGuard first got to the Linux kernel, its inclusion in the FreeBSD kernel has long been in the general roadmap. In February 2020, FreeBSD developer Matt Macy released the first WireGuard-related commit for FreeBSD. Macy’s work was commissioned directly by Netgate, the company behind the distribution of BSD-based pfSense routers.
After almost a year of work, Macy’s port was imported into the kernel scheduled for FreeBSD 13.0-RELEASE, which is expected to be released in 15 days. Unfortunately, there was a problem – after Jason Donenfeld from WireGuard himself analyzed it along with several FreeBSD and OpenBSD developers, he was judged to be not ready for primetime:
I imagined strange voices from the Internet sneering: “this is what gives C a bad name!” Random sleeps have been added to “fix” race conditions, validation functions that have just returned true, catastrophic cryptographic vulnerabilities, entire parts of the protocol not implemented, kernel panics, security bypasses, overflows, random printf instructions deep in the cryptographic code, the most spectacular overflowing buffer and all the litany of terrible things that go wrong when people are not careful when writing C.
This, understandably, presented a major problem for Donenfeld – although the WireGuard protocol itself is open source, a project involves more than its code. Much of what drove WireGuard’s meteoric rise in the first place was its brevity and code correctness, as assessed by Linux founder Linus Torvalds and reflected by the reliability of the project and the lack of major flaws since it became popular. A less than stellar implementation on FreeBSD could damage the WireGuard brand – possibly irrevocably.
This left the port of FreeBSD between a rock and a difficult situation – Donenfeld believed that the code sponsored by Netgate was not ready for public consumption, but Netgate had already announced support for WireGuard in the next pfSense 2.5.
Aware of Netgate’s exposed position, Donenfeld sought out leading FreeBSD developers, Kyle Evans and Matt Dunwoodie, and the three plunged into a crazy week-long race to bring the problematic code up to par. Donenfeld describes a part of the process:
… there were 40,000 lines of optimized cryptographic implementations taken from the Linux kernel compatibility module, but not really connected properly, and mutilated beyond the maze fixes of Linux → FreeBSD ifdefs. I ended up replacing this with a 1,800 line file, crypto.c, containing all the cryptographic primitives needed to implement WireGuard.
This is very much in line with Donenfeld’s usual coding modus operandus—The reason WireGuard on Linux has 4,000 lines of code versus 400,000 on OpenVPN has a lot to do with eliminating inherited fragments and replacing them with code sufficiently focused to get the job done.
Unfortunately for Netgate, neither their sponsored code nor the week-long sprint from Donenfeld, Dunwoodie and Evans seem likely to reach FreeBSD 13.0. Presented with a deeply flawed port and another massively rushed revision, the FreeBSD team will likely disable the WireGuard module entirely for 13.0-RELEASE and revisit for 13.1-RELEASE.
Past controversy and current development
This collaboration was clearly not smooth. Donenfeld expressed some frustration at Netgate’s failure to contact him directly and – once he discovered his commissioned door – an apparent lack of interest in working with him:
They did not bother to contact the project. Okay, I thought, I’ll look around 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, any code that was around it was incorporated into the FreeBSD tree and the developer in charge of writing it moved on.
This is a very 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 lines of communication and a minimum of ego, there is usually a way to resolve this type of conflict – but a problematic story like that of Netgate can easily damage those lines of communication.
Despite the comings and goings, this port should be considered a classic success story for the development of open source software. The initial Netgate developer commission initiated an extremely valuable addition to the FreeBSD kernel. This commission, in turn, attracted interest and subsequent mainstream work from the leading developers of WireGuard and FreeBSD, and will eventually result in a reliable, high-quality WireGuard port for users of FreeBSD – as well as Netgate.