WireGuard Removed from pfSense CE and pfSense Plus Software
-
How about a compromise? How about only displaying the VPN > WireGuard UI if the kernel module is available? Additionally, require manual intervention to install it? Like having to download, compile and load the code manually from the shell. That way we can continue testing the implementation and netgate can continue working on it.
Also, is redmine still the place to report bugs? I've got a few but uncertain now if they are worth reporting...one has to do with a race situation when using DNS Resolver with WireGuard endpoints that are FQDNs. In this case, it seems that WireGuard is trying to resolve DNS but unbound is either not started or not started completely...the fix is to not use FQDNs as endpoints for me.
-
According to what I've read here and there, I prefer to see it removed and wait for it. Better collaborative work with cleaned, audited and well written code for a future release will be beneficial. It's not always easy to step back but it's sometimes a better solution.
-
Does build 2.5.1.r.20210320.0824 still contain Wireguard? I'm not ready to give it up just yet!
-
@dsp3 said in WireGuard Removed from pfSense CE and pfSense Plus Software:
Does build 2.5.1.r.20210320.0824 still contain Wireguard? I'm not ready to give it up just yet!
Hi,
Yes is gone on 2.5.1 RC and 2.6.0 DEV :) -
Just caught up.
That went well.
Does anyone or has anyone posted anywhere about the risk we're exposing keeping it running? I'm way more stable than I ever was on OpenVPN so I'm hugely reluctant to swap back to it.
If it's theoretical (as has been suggested) and it's just generally poor implementation I can live with that until it's sorted in FreeBSD and ported back in. I understand why Netgate want to pull it, it's the right thing for them to do for them, but I'm not so sure I need to for my use.
As for the drama, it was an interesting few hours of reading. Netgate don't seem to have all that much respect in the FreeBSD development community with many allegations of high handed and arrogant dealings. Being an outsider it's hard to work out who's at fault without any of the history but that blog post was a difficult read and certainly didn't do Netgate any favours.
G
-
@xxgbhxx I agree it is all a bit of a sad story. I fully understand Netgate's position and those of the various developers involved.
It is a bit of a shame that those of us who jumped in quickly (and in my case found Wireguard to work well as a VPN to connect in and through our home networks) will now have to revert to OpenVPN (which works - although the upgrade to 2.5 did temporarily cause some problems in my case).
I'm only a home hobbyist so I cannot complain and I certainly want well engineered code with a solid foundation. Perhaps the lesson is not to jump to quickly in future.
-
@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.
-
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/
-
@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.
-
@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
-
@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 !
-
@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.
-
@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 !
-
@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.
-
@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.
-
@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 ;)
-
C cmcdonald unpinned this topic on
-
U USofA1984 referenced this topic on
