OPNsense vs. pfSense article - any thoughts on that?

[kraileth]

Hi everyone,

Having followed pfSense on and off for years, I was a little biased towards it when the fork happened. I took a look at both operating systems, though, but soon stopped due to a lack of time. Now I've revisited this case and decided to write a little series about it (I may link the relevant parts in the howto section, too). I've come to really like OPNsense and will definitly write more about it to keep spreading the word and make it more popular.

However I'm a newcomer and I'm not sure that I got everything right (I end up recommending OPNsense over pfSense in the end so it cannot be that bad, eh? ). Still I would appreciate some feedback, taking my first steps in the community. If you're interested, please have a look here: pfSense vs. OPNsense.

So far I have had little luck on the forums with the few posts that I made. I have a FreeBSD background and like to tinker with things. And I like to become part of the community of a project that I use and thus would love to find my place with OPNsense, too. The next topics that I intend to write about are jail management and building additional packages on more powerful hardware.

[AdSchellevis]

Hi kraileth,

Nice article, thanks!
It's true that we don't like the webgui to run as root, but to be honest, it still requires quite some time to unravel all code behind it.
At the moment our system still requires the user interface to run as root, although we're aiming to fix that as soon as possible. We've cleaned-up a lot of code (we now share roughly 10% with pfSense), making it easier to read and we removed as much side affects as possible. Eventually we'll get there.
Plugins using our new architecture and guidelines are automatically compatible for a non root web gui.

Best regards,

Ad

[kraileth]

Hi Ad and thanks for clarifying the status of priv separation for the GUI! I've edited my post accordingly to mention that it's currently a work in progress.

[fabian]

Note that all new plugins (and some core components) are controllable by the API. So you can automate some tasks if you like.

[sthames42]

Hi kraileth,

I too have been a devoted user of pfSense. I've worked with router/firewall software for many years. Three years ago, tired of the terrible service from Watchguard, I went looking for an open-source router solution for my IT department. Found pfSense and been using it ever since.

However, over time, I have looked at the pfSense code and have found a lot of it to be stream of consciousness hacking and often wondered that it worked at all. Having a vast experience in software engineering, I have found it an axiom that good, clean coding results in a good, reliable product, and that the reverse is true, as well. That being said, pfSense has always worked well for me.

The latest version of pfSense did not port a package that I was using so I set out to do the port myself. It works well and I use it for my company routers. I put in a pull request to have the package included in the official source and got into an argument with one of the gatekeepers who appears to be a tyrant. Don't get me wrong, he had some points in his criticism, and I made several of the changes he requested. But we argued about one change, that I would have made, useless as it was, until he became insulting and hit me with a "do it my way or get out" attitude. They appear to not be interested in my contributions, now. It's just as well as I have no wish to improve their product, anymore.

I discovered OPNSense a couple of months ago, by accident, when I learned it's implementation of Suricata is superior. Didn't consider switching but I am considering it now.

I am an extremely good developer and love open source. But I have found that OS developers do not tend to take argument well. I love the debate of ideas and consider arguments over coding styles and approaches conducive to the very best results. But all parties must be willing to listen, consider, and above all, treat each other with civility and respect.

I have two questions or you, and anyone else reading this:

One, your article seems to describe both OPNSense and pfSense as good router software for a home router. Is it your contention that a different choice should be made for commercial use?

Two, I would very much like to contribute to a good OS product as highly useful as a UI router package like pf/OPNSense. Will I find the contributors here are just as inflexible and petulant as I have found with pfSense?

[fabian]

...But we argued about one change, that I would have made, useless as it was, until he became insulting and hit me with a "do it my way or get out" attitude. They appear to not be interested in my contributions, now. It's just as well as I have no wish to improve their product, anymore.

You can make a personal repository where your packages are hosted as a workaround. However I would also stop contributing.

I am an extremely good developer and love open source. But I have found that OS developers do not tend to take argument well. I love the debate of ideas and consider arguments over coding styles and approaches conducive to the very best results. But all parties must be willing to listen, consider, and above all, treat each other with civility and respect.

If your coding style is ok, you can contribute here. New code must be compliant to PEP8 (Python), PSR 2 (PHP) and consistent spacing in XML etc. The variable names should be useful. If the quality is good, your code is welcome here.

You can find a sample in the docs: https://docs.opnsense.org/development/examples/helloworld.html

If you want to add a plugin, you have to fork the opnsense/plugins repository, create a new branch and add your new feature. After creating a pull request you should get a code review and if all issues are fixed (if they have to be fixed), it will be merged.
Note that everything that happens as root must be run via configd.

[fabian]

Two, I would very much like to contribute to a good OS product as highly useful as a UI router package like pf/OPNSense. Will I find the contributors here are just as inflexible and petulant as I have found with pfSense?

It's probably a good idea to look at one of the pull requests here:
https://github.com/opnsense/plugins/pulls?utf8=%E2%9C%93&q=is%3Apr%20

[mimugmail]

Hi sthames42,

let me tell my story:

I was searching for a open source firewall with support for BGP and OSPF. I tried to find a solution using pfSense here: https://forum.pfsense.org/index.php?topic=126842.0

I stumbled upon OPNsense after and the solution to just use the package without GUI, so I looked at the project and there was fabianfrz just building a new version for a quagga plugin. Via Github I tried to contribute my ideas and knowledge of BGP and after some time also code, but I'm way no developer. Only some bash skills, nothing more.

After some time you'll see that the MVC code is always mostly the same, just like blocks you copy for your stuff and edit the model. When you're finished you create a template via jinja which is quite easy to read when you can do basic bash stuff.

And that's it, create a pull request and you get your source in. If you have a good idea the chance it get's in is really high, and the OPN guys are really fast

[franco]

In retrospect version 15.1 and 15.7 weren't very good by today's standards -- they were produced under a "restricted source" embargo which forced us to rewrite the build chain that wasn't freely available anymore 10 months before our first version came out. All we ever wanted was standard hands-off open source licensing, free access and a flexible platform to build upon. And we've achieved just that.

Since 16.1, either *sense is fine if it covers all your requirements. Choice is important and we have always said to use what works best for each and everyone in the particular setting.

We've also removed the package framework in the very beginning which always meant "OPNsense is ok, but pfSense has packages". It was a hard choice in favour of long-term sustainability, rewriting the necessary parts cleanly and with 20% the amount of code, reframing this as "plugins" to avoid FreeBSD "packages" confusion and going from there. 16.1 also started with the idea of plugins and since then numerous contributions have been made:

https://github.com/opnsense/plugins#about-the-opnsense-plugins

One should also note that through all the cleanups (which people at time took as an offence to stability which was a fair stance) OPNsense has become a platform toolkit that you can use to build a firewall, or just a specialised service-oriented platform with a GUI framework, build and sell a product or just have fun working with...

We try to help with code changes, ideas, support. We review pull requests, but like to get to a "shared interest" beyond the code itself, it makes it easier to find an elegant solution should the proposed one be not.

The only way to know is to experience this firsthand, people can say a lot of good things, but their actions are what matters.


Cheers,
Franco

[sthames42]

If your coding style is ok, you can contribute here. New code must be compliant to PEP8 (Python), PSR 2 (PHP) and consistent spacing in XML etc. The variable names should be useful. If the quality is good, your code is welcome here.

I have reviewed the coding standards on the website. I don't agree with all of them (I'm sure no one does) but I understand the need for standards. When I decided to submit a PR for my package, I carefully made all the changes necessary to comply with the pfSense Developer Style Guide. I very much appreciated the extensive documentation on the OPNSense site on both the required standards and the path to creating plugins.

Thank you all for your input. I look forward to contributing.

[franco]

Coding standards merely exist to shift focus from reading code to understanding it. It keeps the brain from jumping through hoops to get to the bottom of what somebody was / is trying to do. It helps to focus, even when in the process of writing.

All coding standards suck in the sense that we have personal preferences, but in the end each step towards a standard is a good one, because very rarely we ask for compliance with coding standards in a PR as that is something that automatically happens when adding code to a file that looks a certain way... It's subtle, but it helps a lot.

[dcol]

Let me throw in my two cents about issues I have with PFsense, even though I do use it on some systems.
1. They seem to be moving away from the community edition. I suspect by version 3.0 you will need to buy it.
2. Forum support is not so good anymore. I get too many condescending replies. Few good posters anymore.
3. Suricata Inline in PFsense is very unstable and not usable. They keep blaming netmap. Works in OPNsense.
4. Cannot install PFsense using UEFI on many systems.
5. Notification system is useless and not customizable. No email alerts for hardware sensors.
6. Traffic Shaper and Suricata Inline. Forget it. Doesn't work.
7. No built in file manager. Only a file editor. Unless you learn Linux, you can't do much.
8. Cannot backup Suricata rules.
9. No migration ability for applying rules to another system with different settings. All Manual.
10. Rules management is not as straightforward as OPNsense using Suricata. PFsense uses too many resources trying to make Suricata backward compatible with Snort. OPNsense was built to only use Suricata which is far Superior to Snort in many ways. So in PFsense you have to keep track of which rules are enabled or dropped in two places. Way too cumbersome and hard to manage.

I am sure there's more items, these are just the ones that popped in my head while writing this post.

Now some of these features aren't in OPNsense either, but they haven't had 10+ years to do it either.

[franco]

For fairness, let me comment on a few of those things.

3. It can be edgy for us too. With the right hardware it works really well, but often users decline the possibility to change their workhorse because „free“. We ship what we have been given by upstream projects especially if users request and encourage it,, but there are no guarantees it works equally well on hardware, VM, other network tech, software, etc.

5. Same same. We are thinking of removing the last remnants and integrating the monit plugin by default and widening its scope.

7. We try to avoid this even more so for the sake of GUI-based security issues. The MVC code can be operated by non programmers to enhance the system from the shell or to write full plugins. With a bit of review on GitHub we guide and help shape plugin submissions. But that is no pitch for the problem. Clearly this is a downside because alterations cannot be made from the GUI. I just want to explain the reasons behind it.

8. Everything should back up as far as I know. We try to avoid caching all external files, so it’s not a complete backup, more a complete metadata backup. And the manual (not imported) suricata rules are not very elaborate yet.

9. Can you explain this in more detail?

10. The two reasons we went with suricata: netmap in-line mode is far superior to that table-based IP blocking; no base IDS integration meant starting from scratch with one single solution.


Cheers,
Franco

[dcol]

3. For known compatible NIC's pfsense inline is still unreliable and sees constant netmap bad packets. Don't see that issue with OPNsense.

5. the monit plugin would be great, it should also have email and Growl notification ability.

7. Not a big deal. WinSCP solves the problem for me. Came in handy when adding custom IDS rules.

8. I meant just the IDS rules. I would like to transfer those rules to another box with a different configuration.
Which is what I meant initem 9 as well.

10. The one IDS approach shows streamlining avoids complication. Also combining GeoIP with Suricata is far superior to pfblockerng because of inline.

Keep up the great work. As soon as I start implementing OPNsense next year into my client base, I will start sending some funds to help the project. Just need to iron out a few tech issues I have posted in other threads.

Thanks

[franco]

For 8, the export would be quite easy for all the rules files, but it’s hard to use as a drop in in another OPNsense box if that is what you meant. Ideally, the config.xml and a fetch + install rules should replicate all files? Otherwise unpacking the raw files the fetch + install would overwrite changes anyway defeating the purpose of a drop in.

Or do you use custom location xml files?

AFAIK, if you only import the IDS section from your original config.xml it should create a 1:1 copy.


Cheers,
Franco