I’ve built my first pfSense router almost a decade ago. Fun fact is that the device is still working flawlessly, Alix2d13 is a beast. At that time 100 Mbps was more than enough compared to the offerings of the ISPs. Fast forward ten years, my WAN links are above this speed. CPU and RAM combined with the embedded architecture impose heavy limitations on the plugin options.
Still remember the time when equipped with console cable hooked to the Alix running pfSense v 1.2.2. Holding tight to my hard copy of pfSense The Definitive Guide to the Open Source Firewall and Router Distribution Book. I’ve typed on the terminal. These days are long gone.
Currently running on a Dual Core Intel CPU with 8 GB RAM and SSD, pfSense is v 2.4.4. The book is freely available online. It makes very little sense to me writing tutorials on how to do this and that any more. The only exception are some obscure cases that are rare and sharing them will be mutually beneficial.
In retrospective PfSense has gone a long way for the past 9 years. The project changed hands and lost some of its founding father. These changes steered the project in a direction that is not so much to my liking. To get a taste please review the following quotes:
pfSense 2.5 and AES-NI
pfSense version 2.5 will be based on FreeBSD 12, which should bring route-based IPsec, along with support for our integrated management platform, NRDM (more about this soon), and a number of other features.
With the increasing ubiquity of computing devices permeating all areas of our lives at work and at home, the need for encryption has become more important than ever. Desktops, laptops, smart phones, tablets, and many other devices all share this need to be able to encrypt sensitive information. Without encryption, everything you send over a network (or even store on a local storage device) is in the open, for anyone to read anytime he wants to read or even change it.
While we’re not revealing the extent of our plans, we do want to give early notice that, in order to support the increased cryptographic loads that we see as part of pfSense version 2.5, pfSense Community Edition version 2.5 will include a requirement that the CPU supports AES-NI. On ARM-based systems, the additional load from AES operations will be offloaded to on-die cryptographic accelerators, such as the one found on our SG-1000. ARM v8 CPUs include instructions like AES-NI that can be used to increase performance of the AES algorithm on these platforms.
The AES-NI instruction set extensions are used to optimize encryption and decryption algorithms on select Intel and AMD processors. Intel announced AES-NI in 2008 and released supported CPUs late 2010 with the Westmere architecture. AMD announced and shipped AES-NI support in 2010, starting with Bulldozer.
Please remember these requirements when you are considering components for your pfSense system.
There have been some concerns expressed about the requirement for AES-NI (or other offload) with pfSense 2.5, as announced two days ago.
Some complained that, since they don’t use VPN, they don’t need AES-NI. While I wasn’t quite ready to say more about the “3.0” effort, it is the reason for the new requirement for pfSense 2.5 and beyond.
With AES you either design, test, and verify a bitslice software implementation, (giving up a lot of performance in the process), leverage hardware offloads, or leave the resulting system open to several known attacks. We have selected the “leverage hardware offloads” path. The other two options are either unthinkable, or involve a lot of effort for diminishing returns.
So why the requirement?
Future versions of pfSense have a new management model. We’re leveraging YANG, via RESTCONF.
The webGUI will be present either on our cloud service or on-device, both talking to the ‘back-end’ (written in ‘C’) on the device via a RESTCONF interface. This is just as I said back in February 2015.
We’re leveraging AES-GCM inside TLS as the transport layer, because RFC 7525 REQUIRES it, and the RESTCONF standard, RFC 8040, says RFC 7525 is a SHOULD.
AES-GCM in particular has problems with side-channel attacks on pure software implementations. ChaCha20, which nicely avoids these issues when in software, isn’t an option. This is because: a) it’s not RFC-compliant, and b) there are currently no acceleration offloads for it, and the situation is that there could be thousands, or tens of thousands of pfSense instances hitting a single (clustered) instance of our cloud management platform.
So the choice is either to design, engineer and release a less-than-strong product, or require AES-NI or other offloads.
The entire PHP layer is being eliminated in the “3.0” effort, and we’re simply too small to continue to maintain both the current, organically-grown PHP layer (100K lines of PHP in 200 files) and the new, pure JS GUI (client) architected as a single page web application.
So there is an excellent chance that pfSense 2.5 will use the new webGUI, talking to our RESTCONF back-end.
As should be obvious by now, this isn’t about VPN.
If you’ve been testing 2.4 snapshots and updates, you’ve already seen a lot of new features. You have probably also seen a new pop-up in the webGUI.
Trademark Policy pop-up
While the pop-up is new, the message isn’t. On January 27, 2017 we posted a blog Announcing a new trademark policy for pfSense. This pop-up is a simple reminder that ensures everyone sees and acknowledges the trademark policy.
For our end users and customers, nothing has changed. pfSense Community Edition (CE) remains a free and open product available for your personal or business use. This is true if you buy hardware from us or not. This notice addresses those who take pfSense CE and sell it, infringing our policy while not giving back to the project and directly competing with Netgate.
At Netgate, we engineer, build, test, and give pfSense software to the community for free. Accepting the pop-up affirms your agreement and right to use, but not sell, pfSense software.
After reading these articles and looking at my old faithful Alix. It is time to look for alternatives. One possibility is OPNsense
These two articles condense a long story, hope you find them informative:
I’ll share just a small quotes from them.
OPNSense is a fork of PFSense, and PFSense is itself a fork of m0n0wall.
The story gets even more interesting:
Building a BSD home router (pt. 6): pfSense vs. OPNsens
Once upon a time… in 2003 there was a new firewall OS called m0n0wall. Manuel Kasper had built it on a stripped down version of FreeBSD. There had been small firewalls before, but Kasper’s innovation was to put a Web GUI on top of it so that the firewall’s settings could be controlled from the browser! It did not take long and m0n0wall took the world by storm. However Kasper’s project focused on embedded hardware. So only a while later a fork was created which geared towards more powerful hardware. The fork’s name? You’ve guessed it: pfSense. In 2015 Manuel Kasper officially ended the m0n0wall project (because recent versions of FreeBSD had been grown too big to be easily usable for what he did with it in the past). And guess what he did: He gave his official blessing and recommends to migrate to and support OPNsense!
So if I want to go with pfSense I need to get a box with CPU supporting these AES-NI instructions. For this either get a branded box or build one on my own. Naturally I’ve chosen the latter.
In selecting the box I have to thank to the great members of the community forum of pfSense.
Alternative to Qotom Q190G4 with AES-NI?
My choice of box is this quiet beast:
Product properties: i5-5250U, 8G RAM, 128G SSD + Q355G4 WIFI $ 350.42
The fan less design combined with the SSD makes the operation completely silent. It keeps a steady 50 C temperature, with average CPU usage of 1-4 % and consumes only 7 – 10 % of the memory. My hopes are that this will serve me for at least the next 10 years. As it is x86 architecture my choice of OS dramatically widens leaving the door open to experiments with whatever comes to my mind.