Drop pfSense for OPNsense

This is an argument I keep having with one person on Mastodon about the future of pfSense. As of this blog post, it’s been almost 1 year and 4 months since the last release of pfSense CE. Do you know what has happened in that time?

• Elon Musk bought Twitter
• Mastodon became big
• PHP 7.4 went end of life

Did you see that last one? PHP 7.4 went end of life. That means exactly what it means: IT. IS. DEAD. Guess what pfSense 2.6.0 runs?

PHP 7.4.26 (cli) (built: Jan 12 2022 15:25:10) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.26, Copyright (c), by Zend Technologies

It doesn’t take a genius to understand that running end of life software on a security appliance is a very bad idea. If you can VLAN hop, then a firewall can easily be exploited. After all, PHP, like every other programming language, is very secure (that’s sarcasm). At this point, any vendor shipping PHP 7.4 on a security appliance is negligent and doesn’t care for their customer base.

Open Code != Open Source

There is also this huge misconception that pfSense is open source. I mean, after all, they claim it themselves:

But here’s the thing… it’s not. Besides the EULA, you cannot actually build pfSense from source. The Netgate build process actually relies on a lot of internal tools and proprietary dependencies. Well, I take that back. It can be done. But it’s difficult. And the build process is so complicated, it had to be reverse engineered.

Further, just because the code is open, doesn’t mean that it’s open source by definition. What’s the definition?

Modify and enhance is the key part. While you can modify and enhance pfSense, good luck building it.

A Secure Open Source Alternative

It’s OPNsense. Period.

Unlike Netgate, OPNsense releases multiple times per year. When they saw PHP 7.4 EOL coming, they quickly pushed out a release to switch to PHP 8. Something Netgate hasn’t thought of doing.