WireGuard Removed from pfSense CE and pfSense Plus Software

KOM

@gabacho4 So I finally bit the biscuit and tried to restore my old OpenVPN config. It went exactly as I expected it would. It didn't restore the OpenVPN interface, nor the rules on WAN or the OpenVPN interface. For added fun, the service hung on startup with:

Options error: Unrecognized option or missing or extra parameter(s) in /var/etc/openvpn/server1/config.ovpn:34: data-ciphers (2.5.0)

Looks like I'm nuking the whole damned thing and recreating it from scratch, just like I knew I would. I could try kludging it together but I just don't trust it at this point that I haven't been left with a FrankenVPN install.

Edit: If anyone cares, the solution was to remove AES-128-CBC from my list of ciphers.

Ofloo

WireGuard was one big security blunder ! I still remember that it was thanks to netgate that we got wireguard into FreeBSD kernel. Makes you wonder what they where thinking at netgate. And how poor their code review is that it got in their code base.

"Should WireGuard again be accepted into FreeBSD, we will re-evaluate it for inclusion in a future version of pfSense software."

Probably a long time. You should be able to install it as a package though.

pkg search wireguard
wireguard-2,1                  Meta-port for Wireguard
wireguard-go-0.0.20210323,1    WireGuard implementation in Go
wireguard-kmod-0.0.20210323    WireGuard implementation for the FreeBSD kernel
wireguard-tools-1.0.20210315_3 Fast, modern and secure VPN Tunnel
wireguard-tools-lite-1.0.20210315_3 Fast, modern and secure VPN Tunnel (lite flavor)

https://www.theregister.com/2021/03/23/freebsd_130_no_wireguard/

Gertjan

@kom said in WireGuard Removed from pfSense CE and pfSense Plus Software:

It went exactly as I expected it would.

I stopped reading at that point and took a snip of my coffee.

Glad you figured it out.

For info : OpenVPN 2.5.0/1 did change a lot of things.

JeGr

@ofloo said in WireGuard Removed from pfSense CE and pfSense Plus Software:

Makes you wonder what they where thinking at netgate. And how poor their code review is that it got in their code base.

You should perhaps check your facts before coming to rant. Netgate sponsered the development, yes. They didn't develop it themselves. The developer applied it as pull request for the next FreeBSD kernel, that got approved(!) from the FreeBSD team not Netgate! They then pulled it (prematurely as I personally think) into the snapshots for 2.5. Yes you could blame them for that, but on the other hand, if I had funded the development of that and it was approved just in time to perhaps get into testing/snapshots of a new release I'd perhaps did the same. Yes they didn't look at all the code. But so did many others that should have in the first place and as a distribution, that builds upon FreeBSD, I'd think that they - like many others - will not go over every single line of code of the kernel, all userland and apps again but rely on upstream (e.g. FreeBSD) quality control. One can critisize that they were too quick to include it in 2.5 but otherwise, the whole process and "blunder" was a "no-no" from FreeBSD and how they handled commit/pull request and inclusion of new code. If it's so easy to get bad code into the kernel, then the procedures and "gatekeepers" of kernel code should definetly be evaluated and thought over. I certainly doubt that everyone using FreeBSD as upstream or BaseOS is checking every bit of kernel code or module again, so that could have hit others like Juniper or Cisco as well. But blaming that whole thing on Netgate or pfSense like your comment suggests (poor review quality, code base etc.) is nonsense.

Your linked packages are the old wireguard-go implementation BTW, that already existed for over a year or two and are e.g. used by OPNsense. Netgate didn't want to use them because they are (slower) userland implementations of WG instead of running it in Kernel space with full speed and flexibility like on Linux. Those aren't packages of the "new" rewrite of the kernel module. Those should come lateron (at least that was the last thing I read about the "rewrite" of the WG module).

Cheers

Ofloo

@jegr You can twist it and turn it however you like, for a company who deals in security, this should never of happened.

And that's not a rant that's just a fact !

JeGr

@ofloo said in WireGuard Removed from pfSense CE and pfSense Plus Software:

@jegr You can twist it and turn it however you like, for a company who deals in security, this should never of happened.

That has nothing to do with "twist and turn". If I import things from upstream I have to trust someone. You can't/don't check every kernel bit and neither do others like Juniper et al. Those are all companies "dealing in security" and with tremendous MORE manpower than Netgate, but they don't get that kind of heat when their products fail or have bugs over and over again.

Just brought it in perspective. "Never happen" simply is nonsense in security. If things that shouldn't break or code be working 100% all the time there would be no security problems.

Ofloo

@jegr I'm not saying all code is 100% secure, but if you see how long or how fast it took for that crap code to implemented. Try and bullshit your way around it

It was rushed and should never of happened !

JeGr

@ofloo said in WireGuard Removed from pfSense CE and pfSense Plus Software:

@jegr I'm not saying all code is 100% secure, but if you see how long or how fast it took for that crap code to implemented. Try and bullshit your way around it
It was rushed and should never of happened !

Huh? Did you read any article about that whole thing? That code wasn't rushed. It was dragged and at the end the dev even had no zest anymore to finish it, so he made it work somehow and be done with it. Yes. The dev did that, nothing to do with Netgate at that point. Then a maintainer/gatekeeper for FreeBSDs Kernel took that bad code, pulled it in and introduced it into FreeBSD kernel. That again was no employee or person related to Netgate. That was what I was talking about. I agree: it should not have happened - but upstream! That code shouldn't have met any criteria for inclusion into kernel space or kernel mods. But someone - don't want to blame but just a fact - took a nap and didn't check on the code. Someone signed off on it being included into FBSD13-current without simple checking. And that should have consequences for the future. 4 or 6 eyes checking has a reason and that's what you get when it's skipped.

Ofloo

@jegr The code was rushed into the kernel, it was rushed for production release. Also FreeBSD didn't release it, Netgate did. It was pulled from the 13 release.

I've been using FreeBSD since 4.x and known about pFsense when it was still m0n0wall. So for me it was a surprise that it happened.

JeGr

@ofloo said in WireGuard Removed from pfSense CE and pfSense Plus Software:

Also FreeBSD didn't release it, Netgate did. It was pulled from the 13 release.

To quote you: it should never have been in the release in the first place! And I already said: I'm with you that it was rushed into the release (and was quite a surprise in the announcement) and was there too early. Full ack there. But I don't only hope Netgate will learn from that but also FreeBSD itself. That wasn't a stellar performance for all participants ;)