PfSense – WireGuard Returns as Experimental Package(netgate.com)
netgate.com
PfSense – WireGuard Returns as Experimental Package
https://www.netgate.com/blog/pfsense-wireguard-returns-as-an-experimental-package.html
42 comments
Probably because Scott Long considers Jason Donenfield an "attacker" of PfSense, FreeBSD and Netgate:
https://www.netgate.com/blog/painful-lessons-learned-in-secu...
https://www.netgate.com/blog/painful-lessons-learned-in-secu...
Ars Technica wrote a report on the debacle[1], and I've since stopped using pfsense. I was already on the fence following their move away from open-source with "pfSense Plus"[2].
[1] https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
[2] https://www.phoronix.com/scan.php?page=news_item&px=Netgate-...
[1] https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
[2] https://www.phoronix.com/scan.php?page=news_item&px=Netgate-...
"you either have a commit bit (enabling you to commit code to FreeBSD's repositories) or you don't. It's hard to find code reviews, and there generally isn't a fixed process ensuring that vitally important code gets reviewed prior to inclusion"
> I've since stopped using pfsense
I find myself in the same boat. What do you use/recommend instead?
I find myself in the same boat. What do you use/recommend instead?
Perhaps https://opnsense.org/ ?
OpnSense has long been the better option. It forked from pfsense years ago and has been better for a long time. Netgate engaged in some shameful behavior after the fork, their mistreatment of Jason isn't their first instance.
The only thing holding me back from opnsense is that there's no pfblockerng...
I don't use opnsense but a quick google revealed the following, is this not functionally the same?
https://www.cjross.net/dns-security-and-adblock-with-opnsens...
https://www.cjross.net/dns-security-and-adblock-with-opnsens...
AdGuard Home is in the OPNsense community repo and a very nice alternative: https://www.routerperformance.net/opnsense-repo/
Unbound has a block list feature and there are several other options. None are quite to the same level as far as I know, but the rest of OpnSense makes up for it.
I'm an OpenWrt hawk, they have a plugin for DNS based blocking if you end up going that direction https://github.com/openwrt/packages/tree/master/net/adblock/...
I thought opnsense had various issues too? I can’t remember what, exactly, but perhaps it was around security or performance?
None that I have ever heard of. It uses HardenedBSD but they're dropping that soonish.
Not me personally, but I have a couple friends that have started using VyOS and they seem pretty satisfied.
https://vyos.io/
https://vyos.io/
I swear by OpenWrt. It's not just for wifi routers. It's a regular Linux distro you can run on X86 too.
My favorite thing about OpenWrt is SQM CAKE, state of the art traffic shaping. A panacea for slow links
My favorite thing about OpenWrt is SQM CAKE, state of the art traffic shaping. A panacea for slow links
I'm in the same boat. As soon as I find time I'm nuking my pfsense router and installing OpenBSD. I just need it to do NAT, DHCP and always work. I don't need a fancy web-ui, traffic graphs or anything like that, I thought I did when I installed pfsense ~10 years ago but the only time I've logged in for any reason was when it stopped working for some reason (usually the ISP's fault).
OpenBSD's history is impeccable and I really don't want to have to think about my router after initial setup other than installing updates once in a while.
OpenBSD's history is impeccable and I really don't want to have to think about my router after initial setup other than installing updates once in a while.
For my home use, I just switched to an Eero device. Not quite the same product categories, but my priority was software security, meaning that there are a very small number of workable options for home use.
Works fine on opnsense.
But I'm pretty sure I've seen wireguard settings on pfsense a few months ago (non-commercial version)? So what is new here?
Btw, I'm wondering what HN folks think but I'm leaning to basically go full wireguard. I don't see why I wouldn't want it basically everywhere. It simplifies network management, makes things more explicit. There don't see to be any performance issues (running production database through it right now), and when running it at home it can even make my Internet seem faster when tunneling through it (probably because of some suboptimal TCP settings somewhere along the way, which seems common).
But I'm pretty sure I've seen wireguard settings on pfsense a few months ago (non-commercial version)? So what is new here?
Btw, I'm wondering what HN folks think but I'm leaning to basically go full wireguard. I don't see why I wouldn't want it basically everywhere. It simplifies network management, makes things more explicit. There don't see to be any performance issues (running production database through it right now), and when running it at home it can even make my Internet seem faster when tunneling through it (probably because of some suboptimal TCP settings somewhere along the way, which seems common).
kernel vs user-space implemention.
Oh, and why would you want to have it as part of the kernel?
As the other poster said, performance. The idea behind wireguard was that it would be a VPN protocol small enough to implement securely in kernel space.
[deleted]
DPDK is fast in userspace by taking ownership of devices (I believe) so that there's no context switching anyways.
My understanding is DPDK has much smaller set a supported nic's since it doesn't use the kernel drivers for the card along with all the other things that the kernel provides.
Wireguard in kernel gives great performance while just working if your kernel is already working on the hardware. Wireguard is so small it is considered easy to audit so is a prime candidate for kernel implementation.
DPDK is listed as an "Exotic" todo for Wireguard:
https://www.wireguard.com/todo/
Wireguard in kernel gives great performance while just working if your kernel is already working on the hardware. Wireguard is so small it is considered easy to audit so is a prime candidate for kernel implementation.
DPDK is listed as an "Exotic" todo for Wireguard:
https://www.wireguard.com/todo/
There is already an implementation of Wireguard in VPP, which runs over DPDK.
Throwing out a few points regarding DPDK/low overhead data/event exchange between kernel and userspace:
1. It is faster if you make it so, i.e., you need to invest quite some work to get to a point where it's faster than kernel - but yea, with that you can make it go brrrrrrrt in quite a few use cases, it's more like an SDK.
2. Some NICs support loading a smaller program to operate directly on the NIC, e.g., through eBPF - nothing gets faster than that as it avoids that (some) traffic hits the CPU at all. But again, it's work to create and maintain and only feasible for specialized stuff.
3. Note that with Linux[0] a lot of the context switch overhead can be avoided by leveraging the state of the art async framework IO-uring, BSD may already have or get something similarily[0]. I recommend reading the paper of the original author[0], it's fascinating IMO.
[0]: I know this is about BSD, so somewhat off-topic, but still shows that most of the context switch complexity can be avoided while not re-inventing the wheels in user-space.
[1]: https://kernel.dk/io_uring.pdf
1. It is faster if you make it so, i.e., you need to invest quite some work to get to a point where it's faster than kernel - but yea, with that you can make it go brrrrrrrt in quite a few use cases, it's more like an SDK.
2. Some NICs support loading a smaller program to operate directly on the NIC, e.g., through eBPF - nothing gets faster than that as it avoids that (some) traffic hits the CPU at all. But again, it's work to create and maintain and only feasible for specialized stuff.
3. Note that with Linux[0] a lot of the context switch overhead can be avoided by leveraging the state of the art async framework IO-uring, BSD may already have or get something similarily[0]. I recommend reading the paper of the original author[0], it's fascinating IMO.
[0]: I know this is about BSD, so somewhat off-topic, but still shows that most of the context switch complexity can be avoided while not re-inventing the wheels in user-space.
[1]: https://kernel.dk/io_uring.pdf
I'll add that with DPDK you end up needing your own TCP stack if you're doing anything above layer 3.
TCP is a beast with opportunity for countless subtle bugs. The Linux kernel is perhaps the best implementation there is. Many userspace implementations are simplified and missing features.
Even giants like Cloudflare use Linux kernel for routing when they need to operate above layer 3. They only use DPDK for very low level features.
DPDK has its place but for most use cases you need to man handle TCP and you're better off using kernel packet handling for that
TCP is a beast with opportunity for countless subtle bugs. The Linux kernel is perhaps the best implementation there is. Many userspace implementations are simplified and missing features.
Even giants like Cloudflare use Linux kernel for routing when they need to operate above layer 3. They only use DPDK for very low level features.
DPDK has its place but for most use cases you need to man handle TCP and you're better off using kernel packet handling for that
> use Linux kernel for routing when they need to operate above layer 3.
What could you possibly mean by this?
What could you possibly mean by this?
When they need to handle UPD and TCP. Cloudflare's web application firewalls run at TCP and HTTP layer and use tuned Linux kernels for processing, not DPDK and userspace TCP as some think
Their line rate stuff for flood mitigation uses DPDK or similar
Their line rate stuff for flood mitigation uses DPDK or similar
Nothing there was DPDK, just FreeBSD kernel networking.
The Wireguard implementation in VPP runs at about 5Gbps in a simple single-stream iperf test.
The Wireguard implementation in VPP runs at about 5Gbps in a simple single-stream iperf test.
5Gbps on what hardware and how does that compare to the kernel implementation on the same hardware? Curious to know how big a difference DPDK makes. Also what about cpu time, I know typically DPDK takes more CPU due to polling, normally want to dedicate cpus to DPDK right?
Very new Xeon at 3.5GHz. 5.75gbps.
Kernel Wireguard is almost 3gbps.
But Wireguard is mostly held back by the slow crypto implementation, which is CPU-bound.
AES-GCM IPsec on the same hardware is 19.5gbps, limited by the 25gbps NIC, using again, single-stream iperf with ipsec in VPP.
DPDK only needs dedicated cores for the poll mode drivers, and these days the Intel and mellanox NICs can be run in interrupt mode.
Kernel Wireguard is almost 3gbps.
But Wireguard is mostly held back by the slow crypto implementation, which is CPU-bound.
AES-GCM IPsec on the same hardware is 19.5gbps, limited by the 25gbps NIC, using again, single-stream iperf with ipsec in VPP.
DPDK only needs dedicated cores for the poll mode drivers, and these days the Intel and mellanox NICs can be run in interrupt mode.
I thought interrupt mode reduced performance, that was the tradeoff, is the throughput your quoting in interrupt or polling mode?
Good numbers either way, but you again much more limited hardware support since the drivers need to be DPDK specific.
Good numbers either way, but you again much more limited hardware support since the drivers need to be DPDK specific.
You can also run VPP over AF_PACKET (slower, but faster than the kernel) of AF_XDP (almost as fast as DPDK interrupt mode.)
But Wireguard is still crypto-limited, the AES-GCM result proves it.
But Wireguard is still crypto-limited, the AES-GCM result proves it.
Wireguard isn't doing to bad considering its not hardware accelerated like AES-GCM.
Also looks like AF_PACKET and AF_XDP are basically an alternative to DPDK with similar functionality but built into the kernel using kernel drivers, new to me.
Also looks like AF_PACKET and AF_XDP are basically an alternative to DPDK with similar functionality but built into the kernel using kernel drivers, new to me.
I've given up on Xsense distros and use OpenWrt. It's Linux based so Wiregaurd is in kernel and easy to setup.
I keep trying to get people to try it out :) . I left pfSense community years ago when drama started and it became clear somebody was commercializing it.
Linux based distros have better features and hardware compatibility these days anyways. BSD is slowly dying (at risk of downvotes here)
I keep trying to get people to try it out :) . I left pfSense community years ago when drama started and it became clear somebody was commercializing it.
Linux based distros have better features and hardware compatibility these days anyways. BSD is slowly dying (at risk of downvotes here)
And indeed just three days ago the work was announced on the wireguard list https://lists.zx2c4.com/pipermail/wireguard/2021-May/006711....