This is not some half-baked package. This is being developed with the intention of being considered for inclusion in the official Netgate repository (Netgate reached out to me last week). This is NOT base on wireguard-go. This uses the kernel resident loadable module if_wg.ko provided by the wireguard-kmod package which is tracking Jason Donenfeld’s work at https://git.zx2c4.com/. This is bleeding edge but arguely more secure than what shipped in 2.5.0. Because the kernel code is fresh, it includes tons of bug and security fixes as well.
Yea that was my initial call for developers…and then I ended up just jumping neck deep into pfSense internals and package development. Haha!
There are still a few breaking issues with tunnels assigned to interfaces, but otherwise it works well. I’ve been eating my own dog food for the past week on my phone with a pfSense box in Vultr for my personal VPN.
Where do we report bugs? I have installed this package and I think I have caught a bug. My router lost power at some point with the package installed and when I powered it on, it lost all the interfaces. I had to reconfigure them from cli.
I thought this was weird and I simulated this power loss by removing the cable of my router from the power source and rebooting. I got the same issue. You can try. I am on 2.5.1. I tried it with the v0.0.5_0, This doesn’t happen if i dont have the package installed
Good news everyone, initial pull request has been made! Netgate is eager to get this into their package repository. We might see it in the 2.6.0 snapshots by the weekend! Stay tuned on the Netgate Blog for an announcement soon
This looks great, and reminds me of something I’ve been confused about – how does OPNSense already have a Wireguard module? Who built it? And if someone already built it for OPNSense, why would anyone need to build it again for pfSense given their similarity?
I had read that the pfSense Wireguard implementation was the first on FreeBSD. But then what is OPNSense’s implementation? They’re also on BSD.
Also, do you know if Wireguard has opportunities for hardware acceleration? When I see specs on firewalls and routers, they often mention that IPSec is hardware accelerated, and they’ll report max throughput for IPSec separately from max throughput of the router or firewall. It would be neat if Wireguard could be hardware accelerated like IPSec.
The module in OPNSense is running in user-space, as opposed to kernel-space. All modern OSs (Windows, Linux, BSD including OSX) have a separation between the kernel and the user for security reasons. Since the networking code (interfaces, routing) all lives in kernel space, having wireguard in user space means each packet needs to be copied from the kernel protected part of RAM to the user application part of RAM, and then back again after processing. This has a performance penalty.
The PFSense Wireguard implementation wasn’t the first Wireguard for BSD and was never claiming to be. It was claiming to be the first kernel implementation.
I don’t know the actual performance penalty of kernel vs user wireguard, but many people are happy enough with the user-space implementation.
Aren’t there a bunch of user-space networking stacks now that perform faster than conventional in-kernel stacks? I’m thinking of DPDK especially, maybe netmap, and I forget one other. My impression was that these accelerated libraries have a performance advantage specifically because they’re in user space, so maybe they don’t actually copy back and forth to the kernel? I’m not sure how DPDK works, other than that it requires driver support (and there’s a ton of support now).
I thought pfSense was going to adopt DPDK a few years ago, but I lost track of what happened to that. I remember reading something about how DPDK enabled pfSense to do line rate packet filtering at 10 GbE.
The adoption of DPDK turned into the TNSR product. It won’t be in PFSense. All DPDK development is Linux focused, and they would have to be constantly porting changes if they wanted to use it on BSD.
There might be less feature support or maybe driver support on FreeBSD vs. Linux. At least there was a couple of years ago. I’m not sure about feature deltas in 2021.
