OPNsense Forum
Archive => 17.1 Legacy Series => Topic started by: kraileth on July 17, 2017, 06:58:24 am
-
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 (https://eerielinux.wordpress.com/2017/06/25/building-a-bsd-home-router-pt-6-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.
-
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
-
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.
-
Note that all new plugins (and some core components) are controllable by the API. So you can automate some tasks if you like.
-
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?
-
...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.
-
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
-
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 :)
-
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
-
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 (https://github.com/softlife/FreeBSD-ports/tree/vhosts-package/www/pfSense-pkg-vHosts), I carefully made all the changes necessary to comply with the pfSense Developer Style Guide (https://doc.pfsense.org/index.php/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.
-
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. :)
-
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.
-
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
-
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
-
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
-
Franco, Thought you might get a chuckle about this, I have just been banned on the PFsense forum. Probably for things I have said in this forum because I just visited that forum, by mistake, for the first time in weeks and I was banned. You really hit a nerve with the PFsense people. Shows they are threatened by such a great product. But really they loose because I have dozens of PFsense installations I service and was ready to start contract talks with Netgate. This last nail in the coffin for them will see me move all my accounts to OPNsense over the next year.
Beside I have other login accounts at PFsense that still work, so they didn't accomplish anything. Just shows what I have been dealing with over there and why I was looking for an alternative, and I am glad I did.
Keep up the good work.
-
I just deleted my pfsense forum account. Didn't contribute much, way less then here, but i browsed it a lot. When 18.1 will be out, i'll migrate all my clients to OPNsense. Lots of work, but it's worth it. Don't want to throw mud and blood so my reasons are irrelevant at this point, pfsense has been a good companion over the years, so all I can and will say is that i feel that they forgot about their roots. And i hate this.
Franco is one of those people who care, as limited his time may be. OPNsense feels like a fresh breath and things are going in the right direction, at least for my tastes.
Keep up the awesome work!
-
If it's indeed like you say, it's pretty sad. I hate when companies forget their roots and change for the worse like that too. Users leaving can sometimes straighten them up again though, so good luck to them.
-
Once they go fully commercial, they won't go back. When that happens, watch for a flood of new OPNsense users. Besides IPS doesn't work well on their system. And as far as I am concerned, you don't have a true firewall without IPS. IMO
-
Agreed. And that's good for OPNsense. They have signed with qnap in the last past days. Although the idea seems, at first, nice, i would not trust my network's security to a vm inside a NAS (if i remember correctly, it will run inside a vm). Not to mention performance. Imagine the bottlenecks in a busy network. But... it might work for small businesses. Anyway, too many failing points with this design. The proper way to do it will always be 2 dedicated physical machines with high availability enabled.
-
QNAP broadens the reach of an otherwise capped growth potential. That's nice to see for them.
We have our own interesting announcement to share on top of the 18.1 release next week. It's mainly a twist to what is already possible, but it may have major implications for making a favourable decision towards OPNsense in the future. ;)
Cheers,
Franco
-
We have our own interesting announcement to share on top of the 18.1 release next week. It's mainly a twist to what is already possible, but it may have major implications for making a favourable decision towards OPNsense in the future. ;)
Cheers,
Franco
Is it 29th of January yet?!?! :D
I can barely wait, would you please spoil something, better now then latter? :)
-
Yes, from their POV, it's completely true. Obviously, i would also expect other major moves in the future, it's a business after all. They have to at least try. For OPNsense as well, that's a business too.
But i'm a lot more interested in OPNsense, so looking forward for the announcement :-)
-
Is it 29th of January yet?!?! :D
I can barely wait, would you please spoil something, better now then latter? :)
Lol 😂 Agreed! Come on Franco, just a little something :-))
-
Nope. :)
-
Oh, Franco, you're so mean!... :D
-
We'll call him "Franco De Mean" from now on, to throw in a little French nobleman-ish ambience:-D (joking of course)
-
I hopes it's zfs
-
Why do you want ZFS so badly? :)
I remember you asked for it in the past (or maybe I'm wrong, and wasn't you?), and I answered that ZFS has particular HW requirements without which it wouldn't bring any significant advantages over other file systems. Quite contrary, without those HW reqs ZFS has the potential to do more harm than good.
But maybe I miss some info, and your arguments would be really welcome.
-
ZFS provides redundancy if setup as a mirror. A nice feature when some firewalls are very remote. If a disk goes down the firewall keeps running until you have a chance to replace it.
-
I was 99,9% sure you are thinking about the redundancy offered by ZFS as the main reason to be used in OPNSense. ;)
Completely agree that ZFS provides redundancy, completely agree that ZFS is a very robust and resilient FS, but it is designed to make the data checks (immediately after the read of that data, on-the-fly check-ups) and periodic scrubs on storage considering that data and/ or hashes in RAM are the correct one. So, it implies that RAM memory should be ECC RAM, so that no RAM memory errors would get pushed to storage as "correct", overwriting the really correct, but mistakenly considered as corrupted, data on storage.
If ZFS, and if production, you wouldn't risk a RAM failure being considered as a storage failure - multiple points of failure. Also, I guess many user wouldn't like to be "forced" to use ECC RAM in their HW setups - look at pfSense and the storm they provoked getting more and more pushy, hammering the "my way or the highway" approach on users.
I'm sure there are alternative ways to get redundancy on your OPNsense setup, and ZFS could be, IMHO, at most an option, not the only option.
-
ZFS is gaining priority as we have cleared a lot of other things that were more pressing, but that's not what the announcement is about. For me, the roadmap in 2018 has remote syslog improvements via Syslog-NG, the migration of the Monit plugin to core and introducing ZFS into the installer (amd64 only like UEFI/GPT).
Cheers,
Franco
-
Looking forward to ZFS. most of my firewall installations are remotely maintained.
The packaged version of Monit will also help with remote maintenance.
Keep up the great work.