pfSense® software version 2.2.1 will be out soon. Most of the fixes are related to IPsec (esp MOBIKE support), 802.11 (the entire 802.11 / Atheros stack from 11-CURRENT is in the test builds) and PHP 5.5.22. You can follow along in Redmine.

pfSense software version 2.3 will deprecate PPTP as a supported protocol. All PPTP support will be removed in version 2.3. PPTP is a flawed, broken protocol. MSCHAPv1 was broken in 1998). Its replacement, MSCHAPv2, has been known to be weak for nearly as long. MSCHAPv2 can be brute forced in a matter of hours as was demonstrated at DEFCON in 2012. 

The above only deals with authentication. The encryption used in PPTP, MPPE, uses RC4, which is today considered quite weak. Worse there is no message authentication, so it is possible for an attacker to modify your traffic in transit, quite possibly without being detected. And RC4 is getting weaker by the day. Microsoft, for their part, recommend using L2TP or IPSec or SSTP. OpenVPNis also a possibility. We recommend L2TP/IPsec or OpenVPN, and the L2TP/IPsec support is one of the many reasons we upgraded the IPsec in pfSense 2.2 to Strongswan, rather than raccoon.

With version 2.3 we will also update all packages including: php 5.6, and all other ports that have new versions in the FreeBSD ports tree.

The other major change in pfSense version 2.3 will be a change of ‘package’ technology from PBIs to pkg(ng). We are following Baptiste Daroussin’s work on src to see if we can find a way to move even the FreeBSD base to pkg. If we can, than all components of pfSense will be available as packages, and pfSense itself can be a (meta) package. This will allow more rapid release cycles, as individual components can be tested apart from a monolithic release.

If we find we cannot go to pkg for base, a “pfsense-update” analog of freebsd-update will be developed. Part of what you should read here is that pfSense is moving even closer to its FreeBSD base.

Obviously, there will be changes to the build system required to accommodate these. If you are familiar with the pfSense build system, subsystems such as “pfPorts” will be deprecated in-favor of a much more FreeBSD-like build system. Frankly, the pfSense build system has been a hinderance to the project almost from the beginning. While we’ve made some improvements, especially during the past two years, I anticipate moving the project to something much more like Crochet with time.

But, in the end, one way or the other, pfSense should be available as a (meta) “package” on top of FreeBSD.

Finally, we understand that some people are excited about other projects’ webGUI changes. Frankly, we see this as less important that improving the security and performance of pfSense, but we do understand that making the GUI more appealing has some utility. The situation would, of course, be somewhat different were pfSense a web app. Still, we are not blind to the need. One of the great things about pfSense is that it is Open Source. Another is that it has a large community around it. To that end, we’ve been following a project by Sjon Hortensius and Sander van Leeuwen to convert pfSense to bootstrap. It should be of some interest that Sjon has also recently started fixing issues in OPNsense. Sjon and Sander do very good work. If this project can complete in-time, (and we are willing to help), we will include it in pfSense 2.3.

pfSense software version 3.0 is a longer-term project. pfSense 3.0 is a major re-write consisting of 4 major components.

First, we will be removing all of the PHP from the system. Yes, all of it.

The PHP code in pfSense supports two major functions. First, it serves to generate the HTML for the WebGUI. Second, it serves as an orchestration system, it is used to build config files for the various subsystems, (using config.xml), and serving to ensure that if a given subsystem is changed (say, an interface gets a new address) that the other systems that need to be reconfigured are reconfigured (and in certain cases, restarted).

This PHP code was, of course, inherited from m0n0wall, and has grown (organically in many cases) over the decade since pfSense was forked from m0n0wall. As such it does not use more modern architectures (such as pub-sub) which reduce the need for the whole system to function as a single, monolithic blob. Even Manuel Kasper (the original author of m0n0wall) has recently told me, “looking back I’m not very proud of the architectural mess that I created when I started m0n0wall as an inexperienced 19-year-old.”

Personally, I have no time for PHP, especially for a bunch of PHP that runs as root. So, for pfSense 3.0 Python will be used to write a new configuration and orchestration system and to expose a REST API into this system. The resulting API can be used for at least three purposes:

1) the WebGUI will be re-written to leverage this REST API. This separation should be good for the project in a number of ways. Principally, there will be a defined “control plane” for pfSense, allowing the WebGUI can be changed independently of the core project.

2) the REST API can be used by people in the field of devops to automate the configuration of (potentially many) instances of pfSense. There has been a long-rumored “pfCenter” project, but no good way to implement same. With the REST API in-place, “pfCenter” can become a reality. In addtion, plugging into other Open Source orchestration systems such as Chef, Puppet, and Ansible, or (my favorite), Saltstack (yea, python!) becomes much more possible. (If you happen to be at SaltConf next week, be sure to find me and say ‘Hi’.)

3) More automated testing can be performed. While we’ve started on a test suite, and this has provided some early fruit. See the paper: “Measure Twice, Code Once: Network Performance Analysis for FreeBSD” to be presented at AsiaBSDcon in March. Of possible interest, the testing performed for this paper shows that pfSense is much faster than both FreeBSD 11-CURRENT and OpenBSD 5.6 on the same C2758 hardware.

Though the early results are good, much more can be done. By having a REST API, we can use Conductor and similar tools to configure pfSense, generate test coverage, and then reconfigure pfSense for the next tests. We have also recently obtained copy of Ixia BreakingPoint Virtual Edition to perform further validation of the results of each build. We will be running this on a cluster of rack-mount Intel NUCs, purpose-built for this exercise and dedicated to semi-continuous testing.

Second, the package system from FreeBSD will be brought fully to bear. The ideal here is that “pfSense” is, itself, a package on top of FreeBSD. Releases as installable images would still occur, but overall the large majority of users should be able to move to something with much a more rapid and granular rate of change compared to the existing mechanism.

Third, the core of pfSense (pf, packet forwarding, shaping, link bonding/sharing, IPsec, etc) will be re-written using Intel’s DPDK.

DPDK is a set of libraries and drivers for fast packet processing. It was designed to run on any processors knowing Intel x86 has been the first CPU to be supported. Ports for other CPUs like IBM Power 8 are in-progress.

We have a goal of being able to forward, with packet filtering at rates of at least 14.88Mpps. This is “line rate” on a 10Gbps interface. There is simply no way to use today’s FreeBSD (or linux) in-kernel stacks for this type of load. Since this work is only available on certain, select Ethernet cards (mostly 1Gbps/10Gbps/40Gbps Intel interfaces as well as various VMware and Xeon ‘virtualization’ NICs. Other vendors, including Broadcom, Myrianet, Chelsio and Cisco have shown interest. This also means that the underlying kernel and system will be 64-bit only.

And finally, pfSense will move to use even more advanced encryption techniques for IPsec, TLS and OpenVPN. It should be well-known by now that Netgate and the FreeBSD Foundation co-sponsored a project to enable AES-GCM for IPsec, enabling faster encryption speeds on Intel and AMD processors that support AES-NI instructions. On a pair of fast quad core Xeon systems we can run IPsec at over 2Gbps now. More speed is possible, and I expect the first results showing this to be a port of Intel’s “QuickAssist”. On a C2758, this should provide around 8Gbps of IPsec throughput. Other, more exotic QuickAssist hardware exists to take this throughput to 40Gbps and beyond. Additionally, more speed can be had from better “pipelined” implementations of AES-GCM and AES-CBC on existing and near-future Intel CPUs. In particular, SHA1 and SHA256 can be accelerated via AVX2 instructions, reducing the time required for AH processing in IPsec (and its similar processing in OpenVPN and OpenSSL) on processors that support AVX/AVX2.

The overriding goal here is to be able to provide commodity systems that can run IPsec, OpenVPN and https (TLS) at rates exceeding 10Gbps.

Since there are a very large number of existing systems that can’t run DPDK, and that aren’t able to run 64-bit code, pfSense 2.x will continue as a separate, parallel train. You will not be abandoned if you can’t run (or don’t want to run) the 3.0 release, and yes, we will bring the API and webGUI back to pfSense 2.x after it is implemented on 3.0, so even pfSense 2.x will eventually have all of the PHP removed.

Finally, since I mentioned OpenSSL, let me say this: Other projects may explore alternative implementations of OpenSSL (e.g. LibreSSL), but pfSense is unlikely to do this for three reasons:

1) OpenSSL had its issues, but a good, long-time (> 30 year) friend named Rich Salz is now leading the development there. I’ve known Rich since 1985, and I trust his leadership of the OpenSSL project.

2) Intel is focused on OpenSSL, as is the Linux Foundation, and their funding. There will be more test path coverage and more performance work in OpenSSL than any other implementation.

3) I don’t like the attitude of the people behind the LibreSSL project. Talking smack about the project you forked from is bad form. I’ll say no more than to quote Frank Zappa on the subject.

So, Get on the bus. :-)