WireGuard Removed from pfSense CE and pfSense Plus Software
-
Since I'm not using Wireguard on 2.5, should I just leave my setup as is, or should I download a fresh image that has Wireguard removed and reinstall?
-
@satcat16609 I asked the same question in response to the Twitter post about this. No response yet. I assume they will push an update that will remove it but I could be wrong.
-
I had already reverted back to IPsec from a test site I had using WG. I had found that whenever I made any small changes on the remote router, Windows RDP sessions to that site would disconnect momentarily.
For now I get as good performance with IPSec and OpenVPN (which are both easier to setup and manage).
-
how does this impact the 2.6.x snapshots?
-
We are working as quickly as we can to get to a release candidate where WireGuard is removed. That said, we do not advise users to run any RC in production. RC’s are meant for early look and testing purposes. Of course, some users may choose to run on RCs, and that is certainly their right. Post successful RC testing, we’ll march towards a new release.
As for current installations that have WireGuard, we’ve updated our March 16 blog to ask users to exercise caution with regards to the use of jumbo frames above the stated MTU size.
-
@gabacho4 I do have config backups but I'm generally suspicious of restoring partial configs like that, especially on our main firewall. I'll probably have to give it a try though. It's virtual so at least I can snapshot it before I restore it like I do with all major updates & package updates.
-
This post is deleted! -
So just so I'm understanding, Netgate is still committed to delivering Wireguard support on pfSense whenever it is accepted upstream?
-
Can we expect Wireguard to be reintroduced into pfSenseCE/Plus?
And if so then when approximately? -
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 !