The newest pfSense Community Edition release is now out. This version is dubbed the pfSense CE 2.5.2 release. This is a minor release but it is bringing back Wireguard support as an experimental add-on. For those who missed this, CE is effectively the “free” pfSense edition when pfSense 2.5 was released with more bifurcation between the CE and Plus variants.
pfSense CE 2.5.2 Released
This is a dot release, but it is important. There are a few new features in the new version, and one we want to make our readers aware of. The key items Netgate highlighted are:
- WireGuard can now be installed as an experimental add-on package
- Additional hardware support
- Fixes for AES-NI encryption
There were also a large number of dynamic DNS updates. These include new support for:
The solution already supports a number of dynamic DNS providers, but this is good to see since it provides more options for folks.
Since we have a bit of experience with this after the FreeNAS Corral fiasco, and we had users request that we do this, we wanted to see what would happen to users who deployed pfSense 2.5 with Wireguard and who were stuck using the first implementation. For those that missed it, pfSense and FreeBSD pulled back on kernel WireGuard support. Still, that took some time so we wanted to take a look at what the experience is if you saw the kernel support, deployed Wireguard, and then got stuck with an unsupported Wireguard solution when support re-emerged.
For those that want to deep dive into the updates, you can find the release notes here.
pfSense CE 2.5 to pfSense 2.5.2 Wireguard Upgrade
We have a test node setup with pfSense 2.5.0 with kernel Wireguard since we wanted to see what would happen when support came back.
When one goes through the upgrade process, here is what they see:
The upgrade ultimately fails. Please note this was the same as we saw in pfSense 2.5.1 so this behavior is completely expected.
For those early kernel Wireguard adopters that are stuck, the configuration is not imported into the experimental add-on in the new version. There are a number of reasons that this makes sense since it would involve an upgrade plus add-on step and is only relevant for a smaller number of users as a one-time task.
Our best advice given what we are seeing is to not hope for an easy upgrade path. Instead, it is probably worth setting up OpenVPN, using that connection to remotely do upgrades, then re-enabling Wireguard through the OpenVPN tunnel. That somewhat defeats the purposes, but it is likely what will need to be done. We wanted to do this quick test over a period of time just to see what the outcome would likely be and it seems like we have an answer.
from Hacker News https://ift.tt/3hLkf2d
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.