[HN Gopher] PfSense - WireGuard Returns as Experimental Package
___________________________________________________________________
PfSense - WireGuard Returns as Experimental Package
Author : vermaden
Score : 46 points
Date : 2021-05-09 12:07 UTC (10 hours ago)
(HTM) web link (www.netgate.com)
(TXT) w3m dump (www.netgate.com)
| ianlevesque wrote:
| It's odd that they mention working with Christian McDonald and
| not Jason A. Donenfeld or Matt Dunwoodie. The module they
| reference appears to be https://www.freshports.org/net/wireguard-
| kmod/ which itself came from the work the latter two did here
| https://git.zx2c4.com/wireguard-freebsd/log/
|
| And indeed just three days ago the work was announced on the
| wireguard list
| https://lists.zx2c4.com/pipermail/wireguard/2021-May/006711....
| SigmundA wrote:
| Probably because Scott Long considers Jason Donenfield an
| "attacker" of PfSense, FreeBSD and Netgate:
|
| https://www.netgate.com/blog/painful-lessons-learned-in-secu...
| frickinLasers wrote:
| 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=Netga
| te-...
| screamingninja wrote:
| > I've since stopped using pfsense
|
| I find myself in the same boat. What do you use/recommend
| instead?
| seized wrote:
| 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.
| kayson wrote:
| The only thing holding me back from opnsense is that
| there's no pfblockerng...
| eddyg wrote:
| AdGuard Home is in the OPNsense community repo and a very
| nice alternative:
| https://www.routerperformance.net/opnsense-repo/
| LeoPanthera wrote:
| 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...
| seized wrote:
| 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.
| 0x000000E2 wrote:
| I'm an OpenWrt hawk, they have a plugin for DNS based
| blocking if you end up going that direction https://githu
| b.com/openwrt/packages/tree/master/net/adblock/...
| azinman2 wrote:
| I thought opnsense had various issues too? I can't
| remember what, exactly, but perhaps it was around
| security or performance?
| seized wrote:
| None that I have ever heard of. It uses HardenedBSD but
| they're dropping that soonish.
| Marsymars wrote:
| 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.
| efxhoy wrote:
| 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.
| kryptn wrote:
| Not me personally, but I have a couple friends that have
| started using VyOS and they seem pretty satisfied.
|
| https://vyos.io/
| _joel wrote:
| Perhaps https://opnsense.org/ ?
| 0x000000E2 wrote:
| 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
| forcemajeure wrote:
| "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"
|
| Doesn't sound very professional!
| comboy wrote:
| 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).
| gtirloni wrote:
| kernel vs user-space implemention.
| comboy wrote:
| Oh, and why would you want to have it as part of the kernel?
| 0x000000E2 wrote:
| 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)
| gonzo wrote:
| Even Donenfeld has said the Userspace implementation in Go
| isn't very good.
| atatatat wrote:
| Is it even 1.0 yet...?
| messe wrote:
| 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]
| SigmundA wrote:
| Performance:
|
| https://www.netgate.com/blog/wireguard-in-
| pfsense-2-5-perfor...
| carlhjerpe wrote:
| DPDK is fast in userspace by taking ownership of devices
| (I believe) so that there's no context switching anyways.
| tlamponi wrote:
| 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
| 0x000000E2 wrote:
| 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
| gonzo wrote:
| > use Linux kernel for routing when they need to operate
| above layer 3.
|
| What could you possibly mean by this?
| 0x000000E2 wrote:
| 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
| gonzo wrote:
| Nothing there was DPDK, just FreeBSD kernel networking.
|
| The Wireguard implementation in VPP runs at about 5Gbps
| in a simple single-stream iperf test.
| SigmundA wrote:
| 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?
| gonzo wrote:
| 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.
| SigmundA wrote:
| 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.
| SigmundA wrote:
| 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/
| gonzo wrote:
| There is already an implementation of Wireguard in VPP,
| which runs over DPDK.
___________________________________________________________________
(page generated 2021-05-09 23:02 UTC)