Why I use OPNsense over pfSense, and why I don't trust Netgate at all

5 days ago 1

pfSense and OPNsense are open-source firewall and router operating systems that share a common lineage but have diverged in philosophy and development over the years. pfSense originated as a fork of the m0n0wall project in 2004 (first release in 2006), and gained popularity as a powerful FreeBSD-based firewall platform with a web interface that allowed anyone to essentially build their own router with an advanced firewall if they wanted. OPNsense, on the other hand, was created as a fork of pfSense in January 2015 by Dutch company Deciso, and this fork coincided with the end-of-life of m0n0wall, whose creator, Manuel Kasper, actually recommended users migrate to OPNsense rather than pfSense. Both projects provide similar core features, yet their communities and trajectories have diverged to become significantly more distinct over the years.

Personally, I use OPNsense, and to be quite honest, there have been a number of controversies over the years surrounding pfSense that pushed me to OPNsense. I had initially opted to use pfSense, but there was enough that I was uncomfortable with surrounding it, and Netgate left me uneasy with the idea of building on that ecosystem. From domain disputes, licensing changes, security issues, and more, there's a lot that simply doesn't sit right with me. That's not to say that OPNsense is perfect, but the company's negatively perceived actions have not been anywhere near as controversial.

8 things I always do after installing OPNsense

Here's a checklist of things to do with your fresh OPNsense firewall.

Why did OPNsense fork from pfSense?

Licensing, primarily

Before getting into the issues I have with pfSense, the OPNsense team has documented several key reasons that motivated their fork away from pfSense in the first place. The first was in code quality and openness: the founders of OPNsense felt that pfSense's codebases had become monolithic and difficult to maintain, with ad-hoc development practices. The aim was to refactor toward a more structured framework with improved code quality over time. This included separating the web UI logic from root privileges for better security, though a decade later, OPNsense's UI still runs as root, even if the plans to eventually separate that logic still haven't changed.

Another was the openness of the build process, which at the time had been in flux. Back in 2014, Electric Sheep Fencing (ESF), the trademark owner of pfSense, no longer made the tools needed to build pfSense from source publicly accessible. You needed to apply to ESF to get a copy of the build tools, and there were cases of developers applying and never receiving access. This meant the community could not easily reproduce the official builds or modify the build process, and was seen as undermining the open-source spirit of the project. OPNsense developers viewed this as a form of control by Netgate. In response, they wrote a new build system from scratch for OPNsense and made it fully open.

On top of that, OPNsense wanted a more predictable and frequent release cadence to deliver updates and security patches regularly. pfSense historically did infrequent releases ("when they are ready"), aiming for three releases a year. Now, pfSense Plus has a schedule, but pfSense CE sticks to the same "when ready" approach. Meanwhile, OPNsense instead adopted a schedule of two major releases per year (20.1, 20.7, 21.1, etc), with minor updates every few weeks. This means OPNsense often provides cutting-edge features and quick fixes, at the cost of more rapid change. In contrast, pfSense's slower cycle can mean more stability, but also longer waits for fixes or features.

However, the biggest philosophical divide concerns open-source licensing and community transparency. OPNsense uses a simple 2-clause BSD license (also known as the FreeBSD license) for its code, which is very permissive. pfSense has changed its license multiple times and at one point used a custom ESF license with strong trademark restrictions. This was partly to protect the trademark, but it led to a lot of concern raised by the community. By 2016, pfSense transitioned to the Apache 2.0 license, which it still uses for the open-source pfSense CE today. Apache 2.0 is a bona fide open-source license, but Netgate's strict enforcement of the "pfSense" trademark and even adding a UI popup in 2017-2018, reminding users that "No Commercial Distribution Is Allowed" without permission, struck many as being against the open-source spirit. Plus, it seemed to outlaw contractors from deploying pfSense for clients, and while official communication from Netgate communicated that was not the case, the details felt unclear, with users directing many questions to Netgate about what exactly was and was not allowed. For what it's worth, these licenses did not seem particularly out of the ordinary, but the wording of the license and the nature of the pop-up are what concerned users.

To summarize, by 2015, OPNsense set out on a path that seemed to focus on openness, community involvement, and modern software practices, in contrast to what they perceived as pfSense and Netgate's increasing control and slower, closed development style. Netgate's leadership dismissed many of OPNsense’s critiques as unfounded, and Jim Thompson, co-owner of Netgate, accused Deciso in November 2015 of waging an "attack" on pfSense and, in another comment made in May 2015, of "attempting to use controversy to market their work." Franco Fichtner, who joined Deciso in a full-time role in 2020 and had been working on the project since its inception, referred to these incidents as "gaslighting" in a reply on GitHub.

Netgate repeatedly tried to tarnish the reputation of OPNsense

A purchased domain, a subreddit, and Wikipedia edits

While technical differences have certainly played a role in some users choosing OPNsense over pfSense, much of the motivation comes from trust and community aspects, and I fall into that latter category too. Over the years, Netgate has been involved in several controversies that have left a negative impression on the community at large, and some of them have been quite severe. The first and one of the most widely known controversies is the entire saga behind the "opnsense.com" domain.

After OPNsense launched, it was discovered that someone had bought the domain "opnsense.com" and was using it to host a smear site against the OPNsense project. For a time, opnsense.com showed a satirical video with an edited clip from the movie Downfall, depicting Hitler in his bunker. This video was edited to mock OPNsense developers, along with vulgar insults, and the website itself was filled with remarks aimed at damaging OPNsense's reputation. In September 2017, Deciso filed a complaint with the World Intellectual Property Organization (WIPO) to uncover the owner and stop the harassment. It turned out to be Jamie Thompson, the current president of Netgate, who had registered the domain. In November 2017, a WIPO arbitration panel ruled that Netgate had acted in bad faith by using the domain to tarnish a competitor and ordered that opnsense.com be transferred to Deciso. The "factual background" part of the panel decision is already a massive mark against Netgate.

According to the screenshots submitted by the parties, the disputed domain name was previously pointed to a website displaying images recalling Internet networks, the trademark OPNSENSE and comments about the Complainant’s OPNSENSE firewall, such as: “The possibilities are limitless. Just think of all the places you can go on vacation when your boss finds out you’ve installed OPNsense on his network”; “Look at this f[ ] keyboard. Pretty cool, right? If you had one, you could probably manage a firewall with it. Just not ours”; and “Ease to manage. When your users start complaining, it’s probably the firewall! Tell those whiny b[ ] to shut it. You’re leading technology!”. A video on the website also showed scenes taken from the film “Downfall”, the historical war drama film depicting the final ten days of Adolf Hitler's rule over Nazi Germany, along with a comment reading “From deep within the OPNsense development bunker”.

At the time, the OPNsense team said that such actions "undermine the very basic principles of open source" and that time and money spent fighting this could have been better spent improving the software. This domain hijacking was not the only attack on OPNsense either; Netgate-affiliated individuals also took control of the Reddit /r/OPNsense subreddit (the main community forum on Reddit for OPNsense) and refused to hand it over to the OPNsense project. Netgate was also accused of creating the /r/OPNScammed subreddit in another attempt to smear the name of OPNsense. Finally, Jim Thompson of Netgate made a conflict of interest disclosure on Wikipedia after being accused of a failure to declare a conflict of interest and for advertising and promotion, where he stated the following:

I'm Jim Thompson, I work at Netgate and am the only person here who can provide factual information about Netgate, ESF, pfSense or the OPNsense you seem to be very protective off. If you have any problem about my editing let me know.

Stating that he is the only person who can provide factual information about OPNsense, while not being involved in OPNsense at all, is a ridiculous claim to make. Given that he made that disclosure in July 2018, OPNsense had already progressed significantly since its original fork. The username also matches Jim Thompson's Reddit account.

For many who saw this entire saga play out, this behavior from a company ostensibly built on open-source ideals was yet another red flag and a reason to question Netgate's trustworthiness.

The dangerous WireGuard implementation that almost affected every FreeBSD user

Caught at the last moment

One of the most dramatic technical controversies for pfSense involved the WireGuard VPN. WireGuard is a modern VPN protocol that many users were eager to see on BSD-based firewalls. Netgate decided to fund the development of an in-kernel WireGuard implementation for FreeBSD (and by extension, pfSense) in 2019. This work, done by a contracted developer, was completed and merged into FreeBSD in late 2020, and Netgate proudly included experimental WireGuard support in pfSense CE 2.5.0, released February 17, 2021. However, shortly before FreeBSD 13.0 was to be released, numerous issues with WireGuard's kernel-level implementation came to light.

Jason A. Donenfeld, who is the creator of WireGuard, reviewed the FreeBSD WireGuard code in early 2021 and was disturbed by its quality. In a public mailing list post sent in March 2021. The post starts off quite badly, but it gets worse. Here's how it starts:

Sometime ago, a popular firewall vendor tasked a developer with writing a WireGuard implementation for FreeBSD. They didn’t bother reaching out to the project. That’s okay, I figured, I’ll reach out and see if I can help and coordinate. What followed over the next year was a series of poor communications – messages unanswered, code reviews ignored, that kind of thing. Usually collaborations I’ve had with others have been full of excitement, but it just didn’t work out here. In the few discussions we were able to have, I did get across some key points, like, “you’ll save a bunch of time if you use the OpenBSD code as a starting point.” But mostly it seemed like a stop-and-go effort that the WireGuard project didn’t have much to do with. Then, at some point, whatever code laying around got merged into the FreeBSD tree and the developer tasked with writing it moved on.

He also said this later on in the post:

The first step was assessing the current state of the code the previous developer had dumped into the tree. It was not pretty. I imagined strange Internet voices jeering, “this is what gives C a bad name!” There were random sleeps added to "fix" race conditions, validation functions that just returned true, catastrophic cryptographic vulnerabilities, whole parts of the protocol unimplemented, kernel panics, security bypasses, overflows, random printf statements deep in crypto code, the most spectacular buffer overflows, and the whole litany of awful things that go wrong when people aren't careful when they write C. Or, more simply, it seems typical of what happens when code ships that wasn’t meant to. It was essentially an incomplete half-baked implementation – nothing close to something anybody would want on a production machine.

Donenfeld pulled no punches; this was bad, and it was only discovered a mere two weeks before release. More than 45,000 lines of flawed code had been added to FreeBSD's kernel, had almost been published as a part of FreeBSD 13.0, and Netgate had already rolled it out proudly to end-users as a part of pfSense CE 2.5.0. Understandably, users were pretty frustrated with Netgate, and the top comment on a thread in /r/pfSense, where Netgate "acknowledged" (more on that in a bit) the problems with the WireGuard implementation, shows the turning tides against the company over the past few years.

It makes me wonder if Netgate is ran by egomaniacs who can't take any constructive criticism (viewed by Netgate as a 'personal attack' of course) without shooting yourselves in the foot. Actually I dont wonder after this. Now, I definitely know that Netgate is too busy looking at one 'Im right' tree to not notice that the community forest (who probably works for places, like me, that buys your hardware) is burning.

Donenfeld, along with FreeBSD developers, scrambled to write a safer replacement implementation within a few days, ultimately resulting in WireGuard being pulled entirely from FreeBSD 13.0 and deferring its release to FreeBSD 13.1. It was a massively embarrassing situation for both FreeBSD and Netgate, which had sponsored the original code. A public dispute then followed between Netgate and the WireGuard team. Netgate's Director of Engineering, Scott Long, shared a defensive statement on the Netgate blog, where he said his team was "proud of the work, proud of the results" and claimed they had "not found any issues that would result in a remote or unprivileged vulnerability for pfSense users" running that WireGuard code.

This statement was at odds with both Donenfeld's assertions and, later, a detailed ArsTechnica report, which demonstrated some of the issues that were in the code and a buffer overflow exploit after speaking with the contractor who had written the code for Netgate. Netgate's statement was later altered to acknowledge the MTU vulnerability, but the rest of the statement was kept intact. This stance came across as downplaying the extensive issues Donenfeld identified. In a reply to Long prior to the statement's publication, Donenfeld stood by his critique but tried to de-escalate the situation, focusing on getting the fixes in place instead. Long claimed that Donenfeld "gave no details" or "time to mitigate, correct, and publish" the code. Long further attacked Donenfeld, claiming that he had publicly bashed the code for his own "self-gain." Donenfeld's response disputes these allegations and responds at length, including the inclusion of this line: "this isn't the first time you guys tried to intimidate an open source project."

Again, the whole idea was: two weeks until release! If I suggest the code is just disabled, people will be really upset, so instead we'll try to fix as much as fast as possible before the release. And actually, really focused sprints like that are fun and stimulating. We were all really enjoying writing code until the torrents of anger started coming from you about our efforts. (And I also learned that this isn't the first time you guys tried to intimidate an open source project -- see this summary of the opnSense defamatory website Netgate created -- https://opnsense.org/opnsense-com/ .)

And in the process, too, I've tried to be in contact with you and Jim and let you know what our intentions are and to diffuse tensions. I spent time on a video call trying to describe to you some of the security things we found, in case it wasn't possible for you to use the new code right away. I've also made it abundantly clear to you how much I want to work WITH Netgate. When that Reddit thread cropped up, I offered to you multiple times to send a message to it telling people that we've spoken and it looks like you have a good plan and every things going to be okay, but you didn't respond to my offer.

The rest of Donenfeld's response accuses Long of threatening "intense slander" and that he hopes things can "deescalate, and we can work together on this."

For pfSense users, the immediate impact was that Netgate swiftly removed WireGuard from pfSense CE and Plus in the next update (pfSense 2.5.1) "out of an abundance of caution." Netgate announced that they would revisit WireGuard integration once a stable implementation was accepted into FreeBSD, which was the right move, but one that only came after public criticism. The fiasco damaged pfSense's technical credibility for some, reinforcing a narrative that OPNsense's more open development (and willingness to wait for well-vetted features or use community plugins) might be safer. Notably, OPNsense did not rush kernel WireGuard integration. It offered WireGuard through a plugin package and later adopted the properly vetted implementation once it was ready.

Shifting to closed-source

Another major development was Netgate's introduction of pfSense Plus in 2021. Historically, there was only one pfSense distribution (free and open source, usable on any hardware). Netgate sold official appliances, but they ran essentially the same pfSense software. In February 2021, alongside pfSense CE 2.5.0 (the same ill-fated version that had introduced WireGuard support), Netgate announced pfSense Plus 21.02, a renamed and improved version of what used to be the appliance-only edition. pfSense Plus is basically a separate product branch with additional features and optimizations for Netgate customers. The crucial difference is that pfSense Plus is not open-source. It's a closed-source, commercially licensed software that's free for Netgate hardware owners, but not freely redistributable.

The original open-source project was also renamed to "pfSense Community Edition (CE)" and has continued under the Apache 2.0 license on GitHub.

As Netgate itself states, "pfSense Plus software is a Netgate product - branched from pfSense project - and it is closed source." This marked a significant shift in strategy. Netgate argued that maintaining a wholly open project while trying to rapidly develop new features had become difficult, and that they needed the freedom to diverge the commercial product to meet customer demands. They also cited the need to overhaul large parts of pfSense (dating back to 2004) without disrupting existing open-source users, implying that pfSense Plus would evolve faster and the open CE would lag behind. In practice, since 2021, pfSense CE releases have been infrequent (for example, CE 2.6.0 came in 2022, and 2.7.0 in mid-2023), while pfSense Plus receives more regular updates and new features first. Some features may never make it into CE if they are tied to Netgate's product offerings.

Understandably, this bifurcation caused concern and confusion in the community. Netgate insists they are not abandoning the open-source pfSense. They continue to release and maintain CE, and they contribute code (especially security fixes and FreeBSD updates) to it. Netgate also says the following in its FAQ, under the heading titled "Does this mean Netgate is abandoning its open-source heritage?"

Absolutely not. Nothing has changed about our strong belief in, and commitment to, open source software.

Despite Netgate making its position clear on open-source, it's hard to say that the primary focus hasn't changed. It's now, clearly, on pfSense Plus, which is a closed-source product. To get pfSense Plus on non-Netgate hardware, you'd need to purchase a support subscription, such as Netgate TAC Lite, and use their installer. This is a very different model from the pfSense open-source project. For the purists, this was the straw that broke the camel's back. To them, Netgate's move was validation for those who had long suspected a long-term plan of Netgate to commercialize pfSense.

Of course, I'd never begrudge a company trying to make ends meet and survive as an open-source project. Development costs money, servers cost money, everything costs money. Yet, groups like the Open Home Foundation with Home Assistant and Deciso with OPNsense manage to make it work without harming the users of those projects. Was OPNsense perfect in its humble beginnings as a fork of pfSense? I don't think anyone would claim that. Nobody seems to deny the claims from Netgate that OPNsense responded rudely to offers of help from pfSense, yet at the same time, the actions that pfSense undertook were both significantly more damaging and alarming in both a company culture sense and a security sense. Plus, given Deciso hasn't ever commented publicly on the feud (aside from addressing the OPNsense.com situation), those claims from Netgate employees may leave out crucial context.

pfSense and OPNsense are both good platforms, but OPNsense does well by its community

There's still a place for pfSense, though

Despite the controversies, it's worth acknowledging that pfSense and OPNsense are both mature and capable platforms, each with some advantages. OPNsense gets a lot of praise for its UI, whereas pfSense clearly has superior documentation. With that said, there isn't a problem that hasn't been documented somewhere by someone that I've experienced on OPNsense, and oftentimes, the pfSense documentation is actually good enough to help when it comes to OPNsense issues. Both pfSense and OPNsense support add-on packages and plugins to extend functionality, like with intrusion detection systems, proxy servers, dynamic DNS, and more.

Even when it comes to plugins, historically, pfSense's package ecosystem was larger, including well-known packages like Snort (IDS/IPS), pfBlockerNG (for ad blocking and geo-blocking), and others. OPNsense initially had fewer plugins, but it has rapidly caught up by developing its own plugins and benefiting from community contributions. As an example, OPNsense had built-in WireGuard VPN support earlier via a plugin, whereas pfSense only officially added WireGuard in 2021, which turned out to be a security nightmare and later had to be pulled. pfSense also has Snort support, which OPNsense chose not to include, and instead relies on Suricata for IDS. These differences are relatively minor for most users, though they might be important to some.

There is, however, a perception that the more frequent update cycle of OPNsense leads to more issues, which is countered by pfSense's more conservative and slower update cadence. Both systems have their advantages, and neither is inherently better than the other. OPNsense can release more fixes quickly, but those fixes can come with regressions, whereas pfSense releases can be tested more before being rolled out. It doesn't really matter either way, and it's down to the user as to which system is better for their needs. Both can achieve largely the same networking tasks, but the experience of using and maintaining them can feel different. pfSense and OPNsense will likely remain the two leading open-source firewall platforms for the foreseeable future. Each has both loyal followers and clear strengths in different areas over the other. However, from the perspective of many technically inclined users who value open-source principles, OPNsense has become the preferred choice by many due to trust and transparency considerations. The history of pfSense under Netgate with license changes, antagonism toward OPNsense, and a shift to partially closed-source development raises questions about Netgate's motives and long-term plans for the "community" version of pfSense. OPNsense, backed by Deciso but developed in the open with the community, presents itself as a project that can't be yanked out of the community’s hands or turned proprietary on a whim. It technically could, but in its decade of operation, nothing has suggested that it will. It’s important to stress that pfSense is not a "bad" product at all. It remains extremely powerful and reliable, and Netgate serves many happy customers who still continue to use pfSense day in, day out. There are certain environments where one might still choose pfSense, especially those where the feature only exists in pfSense. But for those rolling their own solutions, OPNsense has become more and more appealing. There are more similarities than differences between the two, and as I've already mentioned, OPNsense hasn't been perfect in the past, either. If there's one benefit everyone got out of this, it's that the competition between pfSense and OPNsense has been healthy for users and pushed both platforms to improve. Even the introduction of pfSense Plus, in a roundabout way, proves it. It shows an attempt to innovate and improve faster, even if it's in a closed environment, and OPNsense has been steadily improving and introducing new features as well. Given how the ecosystem has developed over the last decade, it's unsurprising that OPNsense has exploded in popularity, and Netgate's own actions have likely been a major catalyst in OPNsense's growth in the first place, and it's not just one incident a decade ago that caused it. It's clear that OPNsense has won over those of us who prize openness, and it's exactly why I love it too. The history of pfSense has made me uncomfortable with the idea of using its software for my firewall and routing, and I know I'm not the only one.

small