The dramas [0] between PFSense, OPNsense, and IPFire [1] always seems to come up.
I ended up going with PFSense and it works fine. It's open enough that you can always dive in to figure out what's going on. Perhaps philosophically suboptimal, but for all practical purposes it's worked great for my home!
It’s a fairly recent turn of events. First it was difficult to compile on 2.4 because three left out closed source dependencies that their build scripts relied on.
With 2.6 they are basically diverging entirely. Albeit they are still trying to argue they are foss.
The issue I have is if I’m going with an edge security appliance that has code that can’t be easily audited by security pros better than me, I’ll go with Pali Alto or Cisco who has entire branches and teams dedicated to security like Talos/snort. They are less succeptible to security errors and have a customer base that straight affects national security. So even Alphabet agencies will report exploits and 0days to them.
With their wire guard shenanigans it’s clear they are a small team and closing off the code base means I’m now relying on people that act this way to criticisms for security. I don’t really care about internet drama and it’s a reason I’ve stayed with pfsense to now. But pragmatically their choices mean I have to change. Which is okay too.
The shade I occasionally see thrown toward pfSense is curious to me. This isn't push-back at the parent comment but me expressing a bit of confusion.
I've used pfSense since 2009 or so. I was skeptical when Netgate entered the picture but since I've had no reason to complain. It's been a continuous and usually smooth timeline of serving me well.
A relevant sidebar is that I've been part of different, stellar volunteer efforts - started by a core team that was trying to improve or fix something worthwhile. It is inevitable that core teams members will eventually run low on time/energy and changes must follow. Those changes can be anything and usually are.
> The shade I occasionally see thrown toward pfSense is curious to me.
Every last bit of it is deserved. They made a promise to keep pfSense open source and they broke it as soon as they could. I see them hiding behind it's the newly announced pfSense Plus that is closed source, not pfSense CE and it's pure weaseling.
I still use pfSense but I feel bad for ever being excited about it and contributing to their popularity.
I'm not sure that over 10 years later is "as soon as they could". NetGate has made a huge number of open source releases, and while they have not held exactly to the platonic ideal of open source (literally every bit on the disc comes from an open repo) I think we can all agree that the vast majority of the existing CE code remains open. I also think that they get a lot of shade because some of their developers have been some of the loudest jerks in open source.
In my opinion, at the moment we have Schrodinger's open source: in the box there's a future pfSense CE which is well-maintained but differentiated from their commercial offering of pfSense Plus, and there's a pfSense CE which languishes from a lack of new features and slowly accrues an ever-larger trail of closed-won't-fix bugs.
At this time, which future will develop is anyone's guess; I suspect even NetGate don't really know. Even if they're planning on effectively abandoning CE in place, a backlash in the community could cause that to reverse.
> At this time, which future will develop is anyone's guess; I suspect even NetGate don't really know. Even if they're planning on effectively abandoning CE in place, a backlash in the community could cause that to reverse.
It seems like a certainty that users will shift over to the free version of pfSense Plus for the eventual performance advantages, if not for the REST API alone, and then pfSense CE will slowly wither. We'll see, but I really think you're being overly optimistic entertaining an alternative scenario :)
> However, you are directing your disdain (about pfSense) toward us.
I don't think I am; who's us in that sentence?
> To what end? What is it you want to achieve?
I'm scratching an itch. If Netgate can screw the community that helped pfSense gain popularity then surely it is perfectly acceptable for a member of that community to express a little disdain.
> it is perfectly acceptable for a member of that community to express a little disdain.
Okay. I never inferred otherwise. If venting is the total of your goal here are you okay we blow that off or is there something else you're hoping for?
To be clear, I've no animosity toward your posts. My 'hidden' agenda is this: Because hostility takes a toll on the recipients (us), I'm curious if what you're getting in return is worth it.
> “Because hostility takes a toll on the recipients (us), I'm curious if what you're getting in return is worth it.”
We aren’t the recipients of the hostility; Netgate is. I feel no hostility directed towards me when reading anfogoat’s post. In fact, I thank them for openly expressing their disdain towards Netgate here, as it gives others like me more information to look into and come to our own conclusions on.
> To be clear, I've no animosity toward your posts.
No worries, no animosity assumed.
> If venting is the total of your goal here are you okay we blow that off or is there something else you're hoping for?
I don't like venting. I said I was scratching an itch but venting makes it sound like it had no substance at all and suggests what Netgate did was alright. To be clear, I think the more Netgate gets criticized and called out the better. But I had no hopes beyond that.
> My 'hidden' agenda is this: Because hostility takes a toll on the recipients (us) ...
Putting aside that I'm not completely on board with the hostility characterization either, you're recipients of it only in the sense that you happened to read it. I disagree with you about the degree to which Netgate deserves the criticism of course, but none of the "hostility" was addressed to you or anyone else in this thread.
It shouldn't be taxing. It's pick-me-up to anyone who's read one too many overly positive comments about the pfSense Plus shenanigans.
Like you, i have used pfSense since the 1.2.3 days...which is about 2008-2009 or so. I even bought the book to support the devs at the time (which to my knowledge have left for greener pastures). In some sites I even replaced failing hardware with a legit appliance. And even with COVID, pfsenese allowed me to quickly spin up OpenVPN appliances as standalone boxes (something i tried on OPNsense but couldnt get stable, largely due to the interface changes and my lack of familiarity with them). All of that is to say that I have been a big supporter of theirs, having submitted small bug fixes pre-netgate days and even buying/financially some of their later endeavors.
But the issues are as much
1. Starting with the 2.4 train, you can no longer really compile from source. Their build.sh relies on some closed source components not in their git repo. Specifically a small program called gnid that creates a unique ID and AT LEAST calls home to netgate to report that. They have been very cagey about what all occurs but it does happen outside of the firewalls application itself (ie: you cant block it with a state rule). Bringing this up in forums brings in ad-hoc attacks and open hostility. Gonzo is on-record saying if you cant compile its because you dont know what you are doing or something of the sort.
2. They are openly hostile to FreeBSD, forks like OPNsense (which at one point they squatted a similar domain and even tried to spread amlicious misinformation). https://opnsense.org/opnsense-com/. Theres more...entire threads of nonsense and reading. its out there if you want...But all that is to say...everyone has mud of their face when its slung around like it has been.
You may say this is childish and so comically so theres no way its true. But if you see how they conduct themselves on reddit and listservs its actually somewhat inline.
3. Finally, when gonzo or whatever his name is started back into the project and spawned netgate that was mainly to sell certified appliances as a means to support development. Initially he attacked storefronts on sites like amazon that would pre-package the Community edition onto supermicro boxes etc. And that seemed reasonable (at least to me), even though it was kosher within the terms of the Apache license.. But then with 2.5 they initially announced it would require AES-NI, which a lot of these low power boxes dont support. They backed off of that and eventually said it wouldnt be a requirement.
Ive been on 2.3 for a while now because with 2.4 they dropped x86 and went x64 only. Ive avoided opnsense because im used tot he pfsense interface and some of its more advanced tweaks. And moving to x64 is an in place rebuild and re-import. But I held largely to see how further development shakes out and frankly I'm now spending the time migrating my config over to the primary fork.
2.6 (well their move to year.month releases) will diverge from their "Open Source" code with no promises for them to stay near track. Basically its going closed source. And while they claim its up to community for further support, they also hold the keys to the PR and commits/merges....so they have the ability (and given their history) to deny commits for features/bugs that would conflict with their closed source aspirations.
From the announcment below
>In general, features that are part of FreeBSD or the other open source components that comprise pfSense will be upstreamed to those projects and made available to pfSense CE. This includes features mentioned above, like improved packet filter performance. Some features that we add to Plus will contain code that is part of these open source projects and also GUI or middleware modules that are part of pfSense Plus. In those cases, the open source code will still be contributed back and made available to CE, but work will need to happen in CE community to enable it.
Community Edition will diverge from Pfsense+ with the 2.6 release. They have also made no commitments there will be any releases after that - "it's up to the community".
They will, however, gatekeep what features the community is allowed to add. Community Edition is more or less a dead man walking at this point, they just refuse to come right out and say that.
Someone asked if they'd allow one of the REST API projects to be put into upstream and they gave some ridiculous answer about how they'd review any commit but alluded to the fact they won't actually accept it. Because what would they do if the maintainer left? Their suggestion was to fork it. Which, ironically, is exactly what OPNsense did and then Jim Thompson acted like a misbehaving 6 year old and created a website trying to bash them and didn't even have the spine to own up to it until there was a court order.
I'm not sure why ANYONE would waste any effort on adding anything to pfsense at this point when they won't actually commit to accepting features upstream that competes with PFsense+.
In my case, I don't readily find hostility toward a group that has busted tail to provide me tremendous value while I have contributed very little in return. My interactions over the years have been - perhaps not exclusively positive but overwhelmingly so.
History says one day pfSense will no longer fill my needs. Okay. I'll raise an imaginary glass move on with gratitude.
Well instead of pfSense no longer fulfilling your needs than maybe its time to beam up to the mothership. FreeBSD can do everything pfSense does without a web interface.
pfSense provided a real easy of use, at least back in the day. Given that the whole config synced over to a backup/HA failover system and updates to one could easily be confirmed synced to the other, there was a real ease of use in using pfSense (at least I thought so about a decade ago when I was using it). Spend enough time configuring HA firewalls and you start wishing you had something to take care of alerting about config differences and syncing changes automatically, and that's one of the things pfSense offered that was good.
This wasn't a case of us not knowing how to configure stuff in the OS, we moved from configuring OpenBSD firewalls with pf+pfsync, ipsec+sasync and carp to pfSense because it just made it easier to deploy and configure, given we had about ten or more of these we maintained for customers.
Even recently at a new job we were talking about upgrading or replacing some HA FreeBSD firewall pairs, and I was suggesting pfSense because it's simple to use, and just BSD underneath. Given what I've learned in this thread about the state of the project and company behind them now, I don't think I would recommend it anymore, but I still think a similar project with similar features has something to offer over vanilla BSD.
I moved over to opnsense yesterday. Just built my config in a vm. Exported. Installed the firewall and imported and setup the interfaces.
It should do all of that and seems to have a few nice features to boot. As well as a much steadier release cycle. And a security audit feature built in to tell you if the updates available will patch vulns. Which I found neat
Nice, and thanks for the heads up on your experience. I was actually just looking into comparisons of them today, because I wanted to know what the major differences were, if any. I came across this[1], which while not extremely recent, it within the last year.
Everything looks pretty good for opnsense IMO based on that. The only thing that gave me pause was the note about (unsubstantiated) reports of VLAN problems in opnsense that have supposedly been broken for a while. We make heavy use of VLANs, so that would be problematic, but it could be fixed by now or never have been the longstanding problem reported for all I know, I haven't gotten to that point because I'm not planning on anything in the immediate term that requires it.
I haven’t had any problems so far with them. (I run about 5 vlans at home).
Keep in mind I’m using intel nics (igb driver), promiscuous mode on. They seem the same as others.
The major things I’ve had to muck with.
1) NUT seems bugged. I can’t get it talking via usb as a stand-alone at all. Though I can see the APC UPS via usbconfig. Even when I just pointed it at my nut server I’m seem TTY broadcasts on the ssh session that its dropping snd reconnecting.
2) vpn configs carried over but assumptions made in PFsense had to be input in opnsense. Such as outbound nat on my full tunnel (I run manual nat). And firewall rules have to be put in, generally with the vpn cidr scope at the source address.
3) suricata is definately less....chatty than my snort config on pfsense. Again assumptions in pfsense have to be put in manually (such as specifying your external IP to $HOME in advanced). Also the new policies filters/rules doesn’t seem well documented though it’s brand new as of 21. I’m thinking et pro has less false positives than my old snort options. I’m also still in IDS mode, haven’t started dropping. Their appid implementation seems broken though.
4) php73 seems to freak out here and there. Webui can be crashy, especially big operations like hitting download for suricata rule sets.
5) traffic shaper is definately a little different. Though for me less complex and better. But I haven’t really dug in. I have seem to drops on a specific rtsp stream cross vlan. Hoping sharing rules can fix it.
Overall I like it. It’s a nice improvement despite the bugs.
Except it's not. The source that is provided doesn't actually build pfSense as shipped. Plus there are binaries that no source is provided for that "you don't need to worry about"
pfSense is closed-source [1]. It was discussed last month here on HN [2]. OPNsense is the equivalent FOSS alternative [3].
[1] https://github.com/rapi3/pfsense-is-closed-source
[2] https://news.ycombinator.com/item?id=25894420
[3] https://en.wikipedia.org/wiki/OPNsense