AES-NI Not Required The original plan was to include a RESTCONF API in pfSense 2.5.0, which for security reasons would have required hardware AES-NI or equivalent support. Plans have since changed, and pfSense 2.5.0 does not contain the planned RESTCONF API, thus pfSense 2.5.0 will not require AES-NI.
This will allow broader range of hardware to be able to run this new version.
There is a comprehensive list of new features and changes
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 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.
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.
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.
I’ve been running pfSense in Dual WAN mode for more than a decade. Unfortunately, some sites lately are quite sensitive per user session originating from multiple public IP addresses. The best description of the problem is from the official pfSense documentation:
Some websites store session information including the client IP address, and if a subsequent connection to that site is routed out a different WAN interface using a different public IP address, the website will not function properly. This is becoming more common with banks and other security-minded sites. The suggested means of working around this is to create a failover group and direct traffic destined to these sites to the failover group rather than a load balancing group. Alternately, perform failover for all HTTPS traffic.
The sticky connections feature of pf is intended to resolve this problem, but it has historically been problematic. It is safe to use, and should alleviate this, but there is also a downside to using the sticky option. When using sticky connections, an association is held between the client IP address and a given gateway, it is not based off of the destination. When the sticky connections option is enabled, any given client would not load balance its connections between multiple WANs, but it would be associated with whichever gateway it happened to use for its first connection. Once all of the client states have expired, the client may exit a different WAN for its next connection, resulting in a new gateway pairing.
After some testing and consideration let’s leave the sticky connections unchecked. As mentioned above they are problematic.
Other description of the problem here:
Some websites do not work properly if requests from the LAN are initiated from multiple public IP addresses. Hence load balancing is incompatible with these sites. Common examples are sites that maintain login sessions, most frequently online banking. This is most commonly observed with HTTPS sites so usually HTTPS should not be load balanced. Occasionally it is a problem with HTTP sites that maintain session, but this is rare.
For sites that do not function with load balancing, add firewall rules to not load balance traffic to these destinations or protocols.
To alleviate this issue, you can do the following:
Here are my two Gateways
Make two Gateway
Groups
One for Load Balancing
Set for both Gateways Tier 1
One for Failover
Set Tire1 for the one and Tier 2 for the second
Go to the LAN Rules
Set the default LAN
rule to use the Load Balancing Gateway Group.
Add new rule that will be valid only for HTTPS connection and set the Gateway to the Fail-over Gateway Group.
This way all HTTPS
connections will pass through the First WAN until it goes down and failover to the
Second.
The alternative is to make
separate rule for each and every HTTPS site with issues. The rule will be very
similar to the one for HTTPS. The difference will be that Destination address will
be single Public IP. Doing so will load balance all other HTTPS connection that
don’t have this problem.
Introduction Hello everyone. I’ve been running this blog for 9 years now. In 2010 there were very few options to host WordPress site. The blog was hosted in one local provider up until its acquisition by another company two years ago. This pushed me to move. At that time, I was experimenting with Azure and the natural choice of service was an Azure Web App with WordPress template.
The platform is packed with settings that you can tweak. Unfortunately, the prices are targeted at enterprise customers and were too steep for a small site like mine. Recently a friend of mine mentioned the Static Site Generators. I’ve investigated the topic and it appeared quite an interesting concept. For my purposes this solution fits well as most of my content is static. Thanks to GDPR I had to close all comments and feedback options, which made the site even more static. On the positive side not having to worry about PHP and MySQL out in the wild sounds very a pleasing.
Static Site Generators Research After reviewing a couple of solutions, the idea to use WordPress as a Static Site Generators begin to take shape. This could be achieved by employing Plugins. The ones that I’m currently experimenting with are: Simply Static WP2Static Each has some very strong features. But I still haven’t decided which one to keep. Simply Static has great Diagnostics that helped me troubleshoot some issues. Offering streamlined interface with essential options. While WP2Static gives more control over the crawling and processing with valuable options to clean up some garbage from the output pages. They both produced archives containing the static content, WP2Static can even be configured to push it directly to GitHub repository.
Web Hosting Either way I have a static version of my site now. The next hurdle is where to store the files? I don’t want to host it On-Premise as this will require a lot of additional time and effort. As the Cloud options are so many, let’s narrow it down to Static Websites on Azure Storage and GitHub for simplicity sake. Ever since I’ve read about the Static Websites in Azure, I really wanted to try it with something. Now having the content experiments can commence. My inspiration came from this article Static websites on Azure Storage now generally available Price for storing content and data transfers charges would be low in my case. SSL is requirement but it is not directly offered from Static Websites. I need Azure CDN in front to get the desired feature. This will incur additional cost and complexity for just one simple static site served over HTTPs. For Web Apps there is a Azure Let’s Encrypt Extension that is a pretty useful solution to automatically renew the SSL Certificate.
This tilted the table in favour of GitHub. There are no taxes for storing publicly accessible content and it automatically takes care of the SSL Certificate provisioning and renewal. For the moment GitHub wins.
WordPress Hosting Now that I have the generation and web hosting covered. The last obstacle is where to keep my Static Content Generating WordPress instance?
Cloud: WordPress.com – good starting point. But pretty much the same. You get a free WordPress instance somewhere out there. Not my ideal solution.
Azure Containers Instance – recently I have experiment with this service. It is perfectly suited to quickly get up and running a bunch of containers. Get the job done and destroy them. There is a ready-made template to build two containers solution for WordPress here: Create a WordPress site on a Container Instance My experience with the service is mostly positive. Bringing it up is easy. Getting data persistence requires modifying the template. The performance at the lowest tire was comparable to the once in Web App and insufficient from my perspective.
Local: VM with docker containers – My first choice. Spun up Ubuntu server, quickly and easily installed docker and docker compose. As I felt generous at the time the VM had 4 CPU cores and 4 GB or RAM. Even on mechanical HDD, performance was Fantastic! I never knew that WordPress could feel so snappy! The downside is that I will not keep the VM running all the time and must start and stop it every time that I want to do something.
To my unpleasant surprise there is NO official MySQL image for ARM, Really!? Check this article: Install mysql server-5.7 on ARMv8 architecture (raspberry pi 3 model B) But there is one for WordPress. I’ve tried building one on my own and hit a lot of problems! As a temporary solution for the moment I’m using this image hypriot/rpi-mysql. Works fine but holds MySQL 5.5 and my aim is 5.7. In near future I’ll look into it and if possible, build one image on my own. Had a few hiccups with the persistent storage of data for both WordPress and MySQL containers, but got it right at the end. Here is the content of my docker-compose file:
Again, the performance is even more surprisingly good compared the cloud scenarios. Considering that it is run off a mechanical hard drive on a very humble 1.2GHz Quad and only 1 GB of RAM.
Conclusion With this exercise I’ve managed to decrease the costs of hosting this blog to the bare minimum. Hosting costs are reduced to virtually free. The power costs for the Raspberry Pi are shared with other services and are negligible. Compared with Azure Web App and it’s 20 Euros per month it is a feat! My initial intention for this post was to be short and sweet, but it grew into something much larger. I was able to compress a few weeks of research and experiments into these few lines omitting a lot of problems crossed along the way. Hope you enjoy reading it.
