Hacker News new | past | comments | ask | show | jobs | submit login

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.

https://opnsense.org/opnsense-com/

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+.




I've been on the wrong end of the Netgate brigade/shills/apologists before due to a few blog entries, and it's not fun.

I'm just glad others are seeing the darker side of them.


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

Example, the version i built is on 21.1: https://imgur.com/a/2X2UBJQ


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.

1: https://teklager.se/en/pfsense-vs-opnsense/


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: