Further (a roadmap for pfSense)

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.  There is even an online service to break it.

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.  OpenVPN is 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.  🙂

Share this Post:

40 Responses to “Further (a roadmap for pfSense)”

  1. NimaMHD Says:

    Good job again PFsense team,but remove PPTP is very bad, this protocol is still used by many big organisations, and this is not what we (network managers) decided to use, and it will cause remove PFsense from their network for a buggy PPTP. in my opinion PFsense must support PPTP but warn users about those vulnerabilities like so far.

    Big Thanks.

  2. Jens G. Says:

    As a quick question: can AES-GCM and usage of AES-NI / QuickAssist be used in OpenVPN yet? It didn’t seem that way in 2.2, so is that an oversight on my part or do you plan to include that in say 2.3 or 2.x or 3.0?

    Or is IPSEC the way to go with C2758 and pfSense 2.2 for getting the most bandwith out of encrypted traffic yet?

  3. Sam Says:

    So excited by everything in this post (except salt stack).

    Keep up the great work!

  4. jb Says:

    Nice roadmap !

    Any idea of a macro planning yet ?

  5. Jongle Says:

    Thanks for taking the time to type and post this extensive road ahead description Jim 🙂

  6. Mickey Knox Says:

    Thanks !

  7. Chad Robinson Says:

    I love the roadmap for 3.0, thanks so much for sharing it with us!

  8. michael Says:

    Hi team,

    The ideas for the new GUI sounds very interesting. Have you thought of, to raise security even further, encapsulating plugins in their own environments only allowing communication to the core through the REST API?

  9. ignis Says:


    Do I understand correctly that all the network hardware support from FreeBSD will be dropped in favour of Intel hardware and several other vendors that I fear will port only their new/high end products to DPDK? Does this mean that pfSense 3.0 will not work with any low-end/cheap/older NICs? Do you have metrics on what part of the pfSense community uses 32-bit hardware and Realtek/3Com, etc. NICs?

  10. Ben Cook Says:

    Wow. Ambitious. I like this project’s attitude. 🙂

  11. A Web Developer Says:

    I am so excited for the upcoming updates especially on the make over. We will have our startup company by mid this year and been using pfsense 2.2 and everything is working pretty well based on the services that we are running. Hope it will be a success and somehow contribute to the foundation.

  12. jb Says:

    @Jens G.

    AES-NI is working fine for me on 2.1 (some modifs to do) & 2.2 (without any modif) with openvpn

  13. Nick Says:

    Awesome stuff! Really excited for 3.0!

  14. ugur Says:

    wow! big thanks.

  15. Max Says:

    Exciting roadmap!

    I’m using pfSense 2.2 in Virtualbox as a router/shaper form my home connectivity, it’s rock solid, and it’s working like a charm!

  16. infex987 Says:

    excellent work, since I met pfsense every day I feel much better

  17. Miguel Gonçalves Says:

    A big, big thank you the developers of pfSense!!! You guys have been doing an awesome job!

    I recently ditched thousands of euros of Cisco hardware (2 ASA5510 and 3 ASA5505) for pfSense boxes and I couldn’t be happier!

    Installation was a breeze and configuration with the GUI is super easy.

    I paid for the Gold Subscription and now I have the configuration of my 5 firewalls auto backed up on every change. Great, great, great!

    Just hope I never, ever need to return to Cisco.

  18. Emanuel Says:

    First of all it is great that there is a post 2.x vision for the future, but I would not call it a road-map ;-). As far as I understand you plan to start from scratch for 3.0 and to re-implement the current pfSense functionality within the new architecture while the 2.x branch is kept stable.

    As much as I love your ideas for 3.0 it bears a big risk to fail if the implementation of 3.0 delays and 2.x has to suffer from a feature freeze for too long time.

    I’m pretty sure you have talked about this in the teams already, so I wish you all the best for this ambitious goal.

  19. Edmund Says:

    That sounds like a well planned vision for the future and I look forward to following it – I suspect that you are going to need to keep PPTP support in the project simply because so many things use it, even though they shouldn’t – I’d suggest that you consider that Frank Zappa quote might align with your own statement too? Your thoughts on LibreSSL are appreciated – I kinda agree with them but sometimes a little stress is good for us, even if we don’t like it at the time.

    Overall – to quote Micheleen “Impetuous! Homeric!” (The Quiet Man).

  20. Epilas Says:

    What about multipath in the kernel??? My biggest issue is that i cannot have quagga OSPF load balance over more than one link. Other than that been using pfsense for more than 3 years now and LOVING it.

  21. Fabrice VINCENT Says:

    Excellent news ! I think this is exactly what PfSense needs !

    I did a pilot last year with PFsense 2.1 for configuring 5 Pfsense HA clusters on our various location. It didn’t went through because of the GUI and the absence of API or CLI for config management.
    I’m currently testing a MikroTik based setup for my need, so I won’t wait for PFsense 3.1.1 . But I look forward to test drive with it once it is available.

    All the best to you folks as you engage this hard but stimulating journey !
    I’ll keep watching (sadly I have no time to contribute)

  22. Adam Says:

    I left Sonicwall E Class and Cisco ASA 550x for PfSense.
    I am 100% satisfied.
    Thank you to all the developers of PfSense.

  23. Jim Thompson Says:

    > As a quick question: can AES-GCM and usage of AES-NI / QuickAssist be used in OpenVPN yet?

    AES-NI doesn’t accelerate today’s OpenVPN much because of the overhead of encrypt-then-MAC. The encrypt (AES-CBC) mode can be accelerated via AES-NI, but the MAC (SHA1 and friends) can not. This is why AEAD modes (Authenticated Encryption with Additional Data) like AES-GCM are important. AEAD support is due to be part of OpenVPN 2.4

    A recent preview of that code is here: https://github.com/syzzer/openvpn/tree/aead-cipher-modes8

    QuickAssist will accelerate both AES and SHA1, so a functional QAT driver would make OpenVPN go faster today.

    That all said, OpenVPN has certain architectural issues (the tun/tap interface, and double context switches per packet) that will serve to limit performance. These can be overcome via kernel-bypass networking, a la netmap or DPDK. It’s on the roadmap, but after the above DPDK work.

  24. Jim Thompson Says:

    > Do I understand correctly that all the network hardware support from FreeBSD will be dropped in favour of Intel hardware and several other vendors that I fear will port only their new/high end products to DPDK? Does this mean that pfSense 3.0 will not work with any low-end/cheap/older NICs?

    The DPDK work will be an acceleration option. Most of “pfSense 3.0” will be about the rewrite (in python), the orchestration re-work, and the additional work on speeding up (and securing) crypto.

  25. EricE Says:

    @NimaMHD – I have no sympathy for those not wiling to move off of PPTP.

    It **DOES NOT WORK**

    It’s Y2K all over again. Everyone knew it was coming for DECADES but for far too many systems the can was kicked down the road – repeatedly – until it turned into a crises mere years before the deadline. Yes, on a whole we collectively did a good job getting everything fixed or rigged with duct tape to not blow up – but it was damn sloppy.

    Running PPTP with the known issues is damn sloppy too and I don’t blame Jim and the crew not wasting more time and resources enabling software that fundamentally **DOES NOT WORK**. What’s the point of offering security software that’s not secure?

    If your org won’t move off of PPTP that’s the fundamental problem, not that they are dropping support for PPTP before you.

  26. rich breton Says:

    It’s my understanding after talking at length with netgate that the QuickAssist Driver will not be included in the free version of pfsense, how many of these goodies will we not get but instead be reserved for the version of pfsense that comes from your appliances you sell on your store?

  27. pfSense Digest » Bootstrapped webGUI update Says:

    […] I wrote back in February, one of the big changes coming to pfSense is a conversion of the webGUI to Bootstrap.  Sjon […]

  28. Ciro Says:

    The REST API would be an enabler for Neutron integration, it can make PFsense the default networking component for Openstack solutions..

  29. Jim Thompson Says:

    Rich Breton I don’t know who you spoke with. I don’t have any record of exchanging email with anyone named “Brenton”.
    The DPDK acceleration will *NOT* (emphasis *NOT*) be (as you state), “reserved for the version of pfsense that comes from your appliances [we] sell on [our] store”.

    Given that I don’t know who you are, or what your agenda is, I don’t think further engagement in public is wise. You may, of course, contact me via email to discuss (wait for it…) further.

  30. Jim Thompson Says:


    We do understand. Thanks!

  31. MattP Says:

    This sounds really good. Just bought a Xeon-D system to run in the core of a 10Gb network, and going to be very interested to see what I can push through with just 2.2. No encryption overhead, just pure packet filtering.

    Is there any kind of timeline on 3, Jim?

  32. pfSense Digest » pfSense around the world, better IPSec, tryforward and netmap-fwd Says:

    […] in February, I wrote a blog post that discussed our plans for pfSense software version 2.3, which is now in alpha, and our plans for […]

  33. Frank Schuhmann Says:

    Well done pfSense Team,

    so we could have a really good watch out for all four brand new techniques
    that are available on the market to join in the pfSense code to speed up many
    things and not only one, this is a really fine way you were choosing to go. Tnx.

    As I was reading out of this Blog the following info will be finding their way
    into the pfSense code to speed up many things really hard.

    – The AES-NI is offering hardware encryption support to all platforms that are
    supporting it.

    – Intel’s DPDK will speed up massively the Layer3 routing part as I understand it
    right and such things connected to the routing part in the 10 GBit/s to 40 GBit/s
    area using the AVX/AVX2 registers in the Intel and AMD CPUs.

    – The Intel QuickAssist will be able to speed up massively the compression and
    decompression part and helps gaining the entire throughput of connections.

    – CPUs with many cores would be supported better, than now and the entire
    pfSense system will be run much more smooth and liquid.

    So the brand new Xeon D-15xx platform with 16/32 CPU Cores, AES-NI,
    Intel QuickAssist, AVX/AVX2 and 10 GBit/s adapters would be then one
    of the best options or platforms to go? Or the brand new Intel Skylake
    Xeon E3-12xxv5 together with an Intel QuickAssist adapter?

    Get it working, I would be really interested in such new functions, options and

    Cheers Frank

  34. Tavis Says:

    +1 for disliking the removal of PPTP VPN support, regardless of it’s inherent security issues.
    And disliking the removal of NUT.

    I do like the new interface however.

  35. Chris Buechler Says:

    Tavis: PPTP is past time for removal, long past time to move on. Nut is coming back sooner than later.

  36. blueKobold Says:

    Hello all together,

    it is really great to read about the future plans of pfSense and for sure I would love the
    point with Intel´s QuickAssist and the DPDK part that is very nice sounding.

    Would it perhaps be to much to think about speeding up the entire WebGui
    by using Ajax instead of HTML, or the part (rubric) with the shown VLANs
    connections? Perhaps I don´t know to less about coding but it is looking as
    a cheap and fast way to speed up the entire WebGui that must be even then
    reloaded again and again.

    Cheers Frank from Germany

  37. caofg Says:

    Nice roadmap ! REST API is good!

  38. cloudist Says:

    Where to access the REST API documentation? I am trying to work with using API but can’t find any documentation. Please help!!!

  39. ChrisC Says:

    Hi Jim

    Having migrated myself to pfSense since start of January it is proving to me a very handy firewall device for home use.

    Good to see there is a roadmap in place which shows you are committed to the project, regarding PPTP I understand thats a decision that had to be made.

    People can still connect to PPTP from windows desktops. Sadly I also have a business that provides me services using PPTP for their VPN but luckily I dont have to use it much.

  40. Sandor Says:

    Hi, Any idea when this project will kick off? Can’t wait to start contributing to it on GitHub 🙂

Please don’t post technical questions or off-topic comments. It is far more likely that your questions and concerns will be addressed effectively through one of our support channels.

Leave a Reply