I’m happy to announce the release of pfSense® software version 2.2! This release brings improvements in performance and hardware support from the FreeBSD 10.1 base, as well as enhancements we’ve added such as AES-GCM with AES-NI acceleration, among a number of other new features and bug fixes. Jim Thompson posted an overview of the significant changes previously.
In the process of reaching release, we’ve closed out 392 total tickets (this number includes 55 features or tasks), fixed 135 bugs affecting 2.1.5 and prior versions, fixed another 202 bugs introduced in 2.2 by advancing the base OS version from FreeBSD 8.3 to 10.1, changing IPsec keying daemons from racoon to strongSwan, upgrading the PHP backend to version 5.5 and switching it from FastCGI to PHP-FPM, and adding the Unbound DNS Resolver, and many smaller changes.
The following shows a graphical representation of the past year of 2.2 development, by redmine ticket stats.
This release contains four low-impact security fixes.
- openssl update for FreeBSD-SA-15:01.openssl
- Multiple XSS vulnerabilities in web interface. pfSense-SA-15_01
- OpenVPN update for CVE-2014-8104
- NTP update FreeBSD-SA-14:31.ntp - though these circumstances don’t seem to impact pfSense.
New Features and Changes
The list of new features and changes in 2.2 is available here. We encourage everyone to review this list before upgrading.
pfSense software is Open Source
For those who would like the source changes in full detail, the main repo is available on Github, and the tools repo is freely available for immediate access after completing an ICLA or CCLA and submitting a License Agreement.
As always, you can upgrade from any prior release directly to 2.2. The Upgrade Guide covers everything you’ll need to know for upgrading in general. There are some areas where you will want to exercise additional caution with this upgrade.
Clear your Browser Cache After Upgrade
While the most popular packages should be fine, lesser-used ones may not have been updated by their maintainer, or may not be well-tested and have issues. If you’re dependent on packages, we encourage you to test your combination of packages before upgrading in production.
The change from racoon to strongSwan as the IKE keying daemon brings a variety of enhancements, including IKEv2 support, AES-GCM and more. As with any significant change in this area, caution is warranted especially if you’re doing anything atypical. The types of problems that may be encountered fall into three categories.
- Behavior changes triggering bugs in remote endpoint - It’s possible behavior changes between strongSwan and racoon will trigger bugs in the remote endpoint. The only confirmed instance of this we have seen is an issue in racoon with aggressive mode and NAT-D. If you have remote IPsec endpoints that are pfSense 2.1.5 or earlier, and are using aggressive mode, you’ll want to change those to main mode (all other settings can be left as is). Main mode is preferable for site to site VPNs anyway.
- Problems with rekeying with multiple phase 2 entries on a single phase 1 in some cases with IKEv1 - while many circumstances with multiple P2s on a single P1 work fine, there is an outstanding rekeying problem in some circumstances. Especially where you have several P2s on a single P1, we advise caution on upgrading at this time. Where both endpoints support IKEv2, changing from IKEv1 to IKEv2 will prevent this from being an issue. We have an open bug on this which we expect to have addressed in a future 2.2.1 release.
- Behavior changes where an incorrect configuration that worked before no longer will - There may be things that worked with racoon which were technically not configured correctly, but still worked. The only instance of this we’ve seen is for mobile IPsec clients, where Internet traffic could pass in some circumstances without having specified 0.0.0.0/0 as the local network in the mobile phase 2 configuration. If your mobile IPsec clients need to access the Internet via IPsec, your mobile phase 2 must specify 0.0.0.0/0 as the local network.
Heads up for Xen users
The FreeBSD 10.1 base used by pfSense 2.2 includes PVHVM drivers for Xen in the kernel. This will cause Xen to automatically change the disk and network device names during an upgrade to pfSense 2.2, which a hypervisor should not do but Xen does. The disk change can be worked around by running /usr/local/sbin/ufslabels.sh before the upgrade to convert the fstab to UFS labels rather than disk device names. The NIC device change will require an interface re-assignment to the xn interfaces. Note there have been significant performance issues reported in Xen with this NIC change. You will likely want to change your Xen setup to not use the PVHVM NICs for your pfSense VMs.
Limiters not working with High Availability
If you’re using limiters and high availability (CARP+pfsync+config sync), do not upgrade at this time. We have an open bug on a crash in this circumstance.
LAGG LACP Behavior Change
LAGG using LACP in FreeBSD 10.0 and newer defaults to “strict mode” being enabled, which means the lagg does not come up unless your switch is speaking LACP. This will cause your LAGG to not function after upgrade if your switch isn’t using active mode LACP. You can configure a tunable pre-upgrade to retain the existing behavior after upgrade. See the Upgrade Guide for details.
pfSense software is Open Source
For those who wish to review the source code in full detail, the changes are all publicly available in three repositories on GitHub:
- Main repository - the web GUI, back end configuration code, and build tools.
- FreeBSD source - the source code, with patches of the FreeBSD base.
- FreeBSD ports - the FreeBSD ports used.
Downloads are available on the mirrors as usual.
Downloads for New Installs and Upgrades to Existing Firewalls – note that it is typically easier to use the auto-update functionality, then there is no need to download anything manually. Check the Firmware Updates page for details.
Supporting the Project
Our efforts are made possible by the support of our customers and the community. You can support our efforts via one or more of the following.
- Official appliances direct from the source. Our appliances are the fast, easy way to get up and running with a fully-optimized firewall.
- Commercial Support – Purchasing support from us provides you with direct access to Netgate Global Support.
- Professional Services – For more involved and complex projects outside the scope of support, our most senior engineers are available under professional services.