WireGuard in the kernel is on its way to FreeBSD and the pfSense router

This morning, WireGuard’s founding developer Jason Donenfeld announced a working kernel implementation of his WireGuard VPN protocol for the FreeBSD 13 kernel. This is great news for BSD users and routing device users. based on BSD and distributions such as 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, extremely more reliable when handling a large number of connections. Your author would spend several hours a month bombing machines and manually re-establishing broken OpenVPN tunnels, even after writing monitoring scripts to try to detect and restore them automatically – by tearing up everything and replacing that monitoring network of several hundred machines with an infrastructure based on WireGuard, it reduced that number to “zero hours per month”.

In addition to performance and reliability, WireGuard brings modern protocols, versioned cryptography that literally cannot be configured incorrectly, and a much cleaner and lighter code base than most of the competition – Linus Torvalds has it. once declared “a work of art” compared to OpenVPN and IPSec.

Politics in the Core

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 engagement to FreeBSD. Macy’s work was commissioned directly by Netgate, the company behind the distribution of BSD-based pfSense routers.

After nearly a year of work, the port of Macy’s has been imported into the kernel slated for FreeBSD 13.0-RELEASE, which is scheduled for launch in 15 days. Unfortunately, there was a problem – after WireGuard’s Jason Donenfeld reviewed it with several FreeBSD and OpenBSD developers, it was deemed not ready for prime time:

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

This, naturally, 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 is its brevity and code accuracy, as rated by Linux founder Linus Torvalds and reflected by the reliability of the project and the absence of major flaws since. her popularity. A less than stellar implementation in FreeBSD could damage WireGuard’s brand – perhaps irrevocably.

This left the FreeBSD port stuck between a rock and a hard place – Donenfeld thought the Netgate sponsored code was not ready for public consumption, but Netgate had already announced WireGuard support in the upcoming pfSense 2.5.

Realizing Netgate’s exposed position, Donenfeld reached out to leading FreeBSD developers Kyle Evans and Matt Dunwoodie, and the three embarked on a mad week-long sprint to get the problematic code up to par. Donenfeld describes part of the process:

… there were 40,000 lines of optimized crypto implementations pulled out of the Linux kernel compatibility module but not really wired correctly, and mutilated beyond repair with the mazes of Linux → FreeBSD ifdefs. I ended up replacing it with an 1800 line file, crypto.c, containing all the cryptographic primitives needed to implement WireGuard.

This is very much in line with the usual Donenfeld coding operating mode—The reason WireGuard on Linux is 4,000 lines of code versus 400,000 in OpenVPN has a lot to do with eliminating legacy cruelty and replacing it with just enough well-targeted code to get the job done.

Unfortunately for Netgate, neither its sponsored code nor the weeklong sprint of Donenfeld, Dunwoodie and Evans looks likely to become FreeBSD 13.0. Presented with a 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 current development

This collaboration clearly did not go smoothly. Donenfeld expressed some frustration over Netgate’s inability to contact him directly and – once he found out about their port going live – a perceived lack of interest in working with him:

They didn’t bother to contact the project. It’s okay, I thought, I’ll reach out and see if I can help and coordinate. What followed over the next year was a series of poor communications – unanswered messages, ignored code reviews, that sort of thing. […] at one point, the code that was lying around was merged into the FreeBSD tree and the developer writing it 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 the jobs well. things. 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 Netgate’s can easily damage those lines of communication.

Despite the back and forth, this port should be considered a classic success for open source software development. Netgate’s initial development committee got the ball rolling for an extremely valuable addition to the FreeBSD kernel. This commission has in turn generated major interest and follow-up work from the core developers of WireGuard and FreeBSD, and it will ultimately result in a reliable, high-quality WireGuard port for FreeBSD users – as well as for Netgate.