pfSense 2.0.1 release is now available. This is a maintenance release with some bug and security fixes since 2.0 release. This is the recommended release for all installations. As always, you can upgrade from any previous release to 2.0.1, so if you haven’t upgraded to 2.0 yet, just upgrade straight to 2.0.1. For those who use the built in certificate manager, pay close attention to the notes below on a potential security issue with those certificates.

Change list

The following changes were made since 2.0 release.

Improved accuracy of automated state killing in various cases (#1421)

Various fixes and improvements to relayd

Added to Status > Services and widget

Added ability to kill relayd when restarting (#1913)

Added DNS load balancing

Moved relayd logs to their own tab

Fixed default SMTP monitor syntax and other send/expect syntax

Fixed path to FreeBSD packages repo for 8.1

Various fixes to syslog:

Fixed syslogd killing/restarting to improve handling on some systems that were seeing GUI hangs resetting logs

Added more options for remote syslog server areas

Fixed handling of ‘everything’ checkbox

Moved wireless to its own log file and tab

Removed/silenced some irrelevant log entries

Fixed various typos

Fixes for RRD upgrade/migration and backup (#1758)

Prevent users from applying NAT to CARP which would break CARP in various ways (#1954)

Fixed policy route negation for VPN networks (#1950)

Fixed “Bypass firewall rules for traffic on the same interface” (#1950)

Fixed crash/panic handling so it will do textdumps and reboot for all, and not drop to a db> prompt.

Fixed handling of hostnames in DHCP that start with a number (#2020)

Fixed saving of multiple dynamic gateways (#1993)

Fixed handling of routing with unmonitored gateways

Fixed Firewall > Shaper, By Queues view

Fixed handling of spd.conf with no phase 2’s defined

Fixed synchronization of various sections that were leaving the last item on the slave (IPsec phase 1, Aliases, VIPs, etc)

Fixed use of quick on internal DHCP rules so DHCP traffic is allowed properly (#2041)

Updated ISC DHCP server to 4.2.3 (#1888) – this fixes a denial of service vulnerability in dhcpd.

Added patch to mpd to allow multiple PPPoE connections with the same remote gateway

Lowered size of CF images to again fix on newer and ever-shrinking CF cards.

Clarified text for media selection (#1910)

Notes for certificate generation vulnerability

Certificates generated with the built-in certificate manager in all 2.0 versions prior to 2.0.1 are excessively permissive for non-CA certificates. These certificates can be used as a certificate authority, meaning a user can use their own certificate to create chained certificates. We have defaulted OpenVPN on 2.0.1 and newer versions to not accept chained certificates, which mitigates this. However, if untrusted users have certificates generated from 2.0 release, we suggest re-generating all your certificates and issuing new ones. Certificates generated by easy-rsa and imported into 2.0 are not affected.

If using certificates generated on pfSense for other purposes, you should revoke those and issue new certificates generated on 2.0.1. You must utilize a CRL in that case. To be on the safe side, you may want to start from scratch with a new CA and certificates after deleting all your existing ones if this applies to you.

Thanks to Florent Daigniere for bringing this issue to our attention and helping confirm our resolution.

Upgrade considerations

It is very important to read the upgrade guide before performing an upgrade for those still on 1.2.x versions.

Download

NOTE: With 2.0 release and newer versions, we’re now also building the oft-requested nanobsd embedded version with VGA! You’ll find alternate builds with VGA in the filename, which are the VGA-enabled versions. Only use these on hardware with VGA video. The regular serial version must be used on all hardware that has only a serial port, like the popular PC Engines and Soekris models amongst others, as they will not boot or function correctly otherwise.

Was that bug already present in v1.2.3? Since that would probably explain why pfSense (both v1.2.3 and v2) suddenly started sending out so much DHCP requests in a certain amount of time that my ISP pulled the plug temporarily…

Weird something if the above bug was indeed the cause: clean install of v2(.0) did not solve it, switched to IPFire because of this problem.

Is it possible to upgrade NanoBSD console version from 2.0 to 2.0.1 using gitsync? I have customized it for a bit and don’t want to lose all changes when upgrading as it overwrites the whole slice. Also re-configuring snort from scratch(again) is a nuisance

Bart: that one was not present in 1.2.3. I didn’t see it generate a large volume of DHCP requests as it effectively took down the NIC entirely under that circumstance, but that’s somewhat dependent on NIC driver, it potentially could.

I tested pfsense version 2.0.1 and I have tried Packet haproxy but it has a capacity problem is a layer 7(http) load balancer can not feature add to the cookie (example:cookie SERVERID insert indirect….)

The 2.0.1 update not only blew up our current 2.0 pfSense system, totally corrupting pfsense, (not to mention the a loss/corruption of all packages) but it won’t run after clean install from the i386 iso. Looks like it needs more work. And where did the install option for a single core cpu go?

Jeff: there are no such known issues, definitely something we would have encountered long ago if it were a general problem. Please post details to the forum or list.

Ryan: none of the 2.0.1 changes would do anything remotely close to something along those lines, but I’m sure what’s happening is you have a mess of unstable packages on there that caused havoc for you. There are no major changes in 2.0.1 vs. 2.0, definitely not anything that would cause that kind of issue. There is no longer a uniprocessor kernel because it’s unnecessary.

Good time to again remind people – watch VERY closely what packages you install. If they aren’t labeled as “stable”, they can very easily regress your entire system to beta or alpha or completely destroy it. The bulk of them are not developed by us, they’re from outside contributors who generally don’t have anywhere near the level of QA and review we have on the base system.

We run the psense firewall utilizing PFSYNC Master and Slave nodes for redundancy with redundant WAN links to boot.
Both instances are VMWare 5.0 virtual machines.
To test the new version, I created two new Virtual Machines with 2.0.1 and then Restored the last saved configurations from 2.0.
As usual, this takes some time and does seem to cause installed packages to be uninstalled and reinstalled.
However, no problems were encountered.
I would always encourge testing, with a backup and recovery strategy ready to go before applying any patch or upgrade to anything.

No unstable packages. All were release and stable. While the auto downloaded update was botched for whatever reason, we did partially find the cause of not being able to install. Bad ide cable or drive. We replaced both and it installed and restored fine. That might have caused the botched upgrade too. Hate it when hardware failure happens right when you update/upgrade something.

Thanks for the follow up, Ryan. Drive failure would definitely cause a failed upgrade, actually it isn’t too uncommon when you have a drive failure to not discover it until you try to upgrade. Depending on what packages you have installed, the disk may almost never get touched short of boot time and upgrades. And a good lesson for all – don’t be so quick to assume the software is to blame.

Thomas: auto-update pulls from where you tell it to pull from, you picked the i386 update URL manually if you upgraded amd64 and it went to i386. The default auto-update URL keeps you on the same architecture. 1.2.3 is i386-only, so not sure how you’re thinking it changed architectures, its auto-update will keep you on the same architecture as well (i386 only in that case).

I upgraded recently to 2.0.1 from 1.2.3 by using the auto-upgrade feature in the WebUI. It was smooth and perfect. No issue was encountered at all.
Great job. Congratulations. You never disappoint us, guys.

When we move offices I would like to build new firewalls using pfSense, but we need some level of PCI-DSS compliance. As far as I can see pfSense ticks the right boxes, but I would like some confirmation that there is no reason not to use it.

Paul: Yes, pfSense does serve as the firewalls in numerous PCI compliant environments, including some very high transaction level ones that get the highest levels of auditor scrutiny, so it’s definitely a suitable platform. PCI is about a lot more than what firewall you use though. Post to the forum or list to get into more detailed discussion, and maybe get some feedback from users who have PCI compliant networks.