This morning, WireGuard founding developer 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 such as pfSense and opnSense.

If you’re not familiar with WireGuard, it establishes connections more quickly than traditional VPNs like OpenVPN. It’s also, in our personal experience, overwhelmingly more reliable when managing large numbers of connections. Your author used to spend several hours a month shelling into machines and manually re-establishing broken OpenVPN tunnels, even after writing watchdog scripts to attempt to detect and re-establish them automatically—tearing it all out and replacing this several-hundred-machine-monitoring network with WireGuard-based infrastructure cut that down to “zero hours per month.”

In addition to performance and reliability, WireGuard brings modern protocols, versioned crypto that literally cannot be set up incorrectly, and a far cleaner, lighter codebase than most competitors—Linus Torvalds once declared it “a work of art” by comparison to OpenVPN and IPSec.

Politics in the kernel

Although WireGuard landed in the Linux kernel first, 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 commit to FreeBSD. Macy’s work was directly commissioned by Netgate, the company behind the BSD-based pfSense router distribution.

After nearly a year’s work, Macy’s port was imported 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 alongside several FreeBSD and OpenBSD developers, it was judged unready for prime time:

I imagined strange Internet voices jeering, “this is what gives C a bad name!” There were random sleeps added to “fix” race conditions, validation functions that just returned true, catastrophic cryptographic vulnerabilities, whole parts of the protocol unimplemented, kernel panics, security bypasses, overflows, random printf statements deep in crypto code, the most spectacular buffer overflows, and the whole litany of awful things that go wrong when people aren’t careful when they write C.

This, understandably, presented a major problem for Donenfeld—although the WireGuard protocol itself is open source, there is more to a project than its code. Much of what propelled WireGuard’s meteoric rise in the first place is its brevity and code correctness, as assessed by Linux founder Linus Torvalds and reflected by the project’s reliability and lack of major flaws since becoming popular. A less than stellar implementation in FreeBSD could damage WireGuard’s brand—possibly irrevocably.

This left the FreeBSD port caught between a rock and a hard place—Donenfeld believed that the Netgate-sponsored code wasn’t ready for public consumption, but Netgate had already announced WireGuard support in the upcoming pfSense 2.5.

Mindful of Netgate’s exposed position, Donenfeld reached out to core FreeBSD developers Kyle Evans and Matt Dunwoodie, and the three dug in for a mad, week-long sprint to bring the problematic code up to par. Donenfeld describes one part of the process:

… there were 40,000 lines of optimized crypto implementations pulled out of the Linux kernel compat module but not really wired up correctly, and mangled beyond repair with mazes of Linux→FreeBSD ifdefs. I wound up replacing this with an 1,800 line file, crypto.c, containing all of 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 is 4,000 lines of code to OpenVPN’s 400,000 has much to do with stripping out inherited cruft and replacing it with just enough tightly focused code to do the job.

Unfortunately for Netgate, neither its sponsored code nor the week-long sprint by Donenfeld, Dunwoodie, and Evans seem likely to make it into FreeBSD 13.0. Presented with one deeply flawed port and another massively rushed overhaul, the FreeBSD team will most likely disable the WireGuard module entirely for 13.0-RELEASE and revisit for 13.1-RELEASE.

Past controversy and present development

This collaboration clearly wasn’t all smooth sailing. Donenfeld expressed some frustration concerning Netgate’s failure to reach out to him directly, and—once he’d discovered their commissioned port—a perceived lack of interest in working together with him:

They didn’t bother reaching out to the project. That’s okay, I figured, I’ll reach out and see if I can help and coordinate. What followed over the next year was a series of poor communications – messages unanswered, code reviews ignored, that kind of thing. […] at some point, whatever code laying around got merged into the FreeBSD tree and the developer tasked with writing it moved on.

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 lines of communication and a minimum of ego, there’s usually a way to resolve this kind of conflict—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 success story for open source software development. Netgate’s initial developer commission got the ball rolling for an extremely valuable addition to the FreeBSD kernel. That commission in turn attracted interest and major follow-on work from both WireGuard and FreeBSD core developers, and it will eventually result in a high-quality, reliable WireGuard port for FreeBSD’s users—as well as Netgate’s.