Yes. The code you're running is described as having "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"

This is a kernel RCE just waiting to happen.

Anyone who wants to be able to throw some crypto CVEs on their resume could do worse than spending some quality time with this code.

> random sleeps added to “fix” race conditions

That's just horrifying. It shows someone who knows next to nothing about multithreaded code and is kludging their way through. Not someone you want within a hundred feet of anything other than maybe front-end web, and even there they're going to be the kind of person who blocks the node.js event loop (because async coding is like the junior cousin of multithreading).

It's a userland implementation. This is for the in-kernel implementation. It should be faster. Also, there are some comments that the userland version is rather hacky and probably should be transitioned away from once you can.

OPNSense (the pfSense fork) is using the userland version. pfSense 2.5 is using this kernel code - https://docs.netgate.com/pfsense/en/latest/releases/2-5-0.ht...

"pfSense® Plus software version 21.02 and pfSense Community Edition (CE) software version 2.5.0 include a major OS version upgrade, a kernel WireGuard implementation..."

The userland version is also from the original author of WireGuard and not that bad actually.

I'm currently running it in an OPNsense box to serve our internet needs. I have a connection that without VPN can push through about 400-800 Mbps, and when I put the VPN on for all traffic, I can still push 400-800 Mbps through my connection.

The in-kernel version can do the same with less CPU usage, and can probably drive multi-gigabit connections without any trouble.