Rule Separators

[chropnsense]

Working with +300 rules and +20 VLANs, separators (and able to fold them) is IMHO a must when looking for the right place to add rules. Usually network guys nowadays also work with tight schedules and multiple projects so to find the right place fast to add a rule is highly valuable, at least for me.

Not an OpnSense user (yet) but might consider coming onboard if we get this feature implemented. Since obviously 70e doesn't interest devs to create this UI feature; at what price would you mr. Developer implement this?

Thanks!

[mimugmail]

Which firewall vendor besides pfsense uses rule separators, just out of curiosity.

I dont know much of them, only Cisco ASA, Sophos UTM and Sophos XG where there are no separators.
I saw Juniper and Netscreen in the wild and didn't noticed them, if I'm right also Forti doesn't. IMHO Sonicwall also has very ugly displaying of rules.

[bimbar]

Sophos UTM has the groups with the background which does a good enough job of separating the rule groups.

The small dots in opnsense don't quite do it as well.

[Patrick M. Hausen]

Sidewinder, Forcepoint NGFW, ... look at my screenshot from Sidewinder for an example. Actually they allow hierarchical rule groups.

[chemlud]

Which firewall vendor besides pfsense uses rule separators, just out of curiosity.

I dont know much of them, only Cisco ASA, Sophos UTM and Sophos XG where there are no separators.
I saw Juniper and Netscreen in the wild and didn't noticed them, if I'm right also Forti doesn't. IMHO Sonicwall also has very ugly displaying of rules.

Sorry, but that's a non-argument. As nothing will change, we should stop here discussing. Some people will find the thread overthe years and get an answer (no) to the question, if there are separators in opnsense. End of story... ;-)

[chropnsense]

Which firewall vendor besides pfsense uses rule separators, just out of curiosity.

- Fortigate
- Forcepoint
- Checkpoint
- Cisco

to name a few.

Had a look at the source code of how pfSense does this and it was a bit more tricky than I initially thought (also not perhaps the best design..).

However, tell us a price mighty developers and let's see if we can cough up the dough for you!

Thanks!

[franco]

The problem is and always was that the rules pages are all static PHP pages and adding unnecessary complexity there will increase maintenance and lower the quality of an MVC migration which we also need for privilege separation to happen rather sooner than later (even if it takes years to get there). This is not limited to firewall_rules.php but also all the NAT and Normalization pages as well.

Other than that, within the last year when I got the chance to manage the business release cycle and I learned that open source community happens to ask for features that no business needs and/or considers paying for (and this includes the willingness to development sponsorship). This is true for things like custom configuration options and PPPoE support in FreeBSD amongst others. It could be true for rule separators as well.


Cheers,
Franco

[Patrick M. Hausen]

I would not ask for or endorse implementing some unclean hack to get separators. Maybe a real rule group hierarchy is something you could think about for the future. I have routinely operated enterprise installations with hundreds of rules that would be completely unmanageable without the hierarchical folder structure for rules ...

Just my 2 ct.

Patrick

[chropnsense]

I have routinely operated enterprise installations with hundreds of rules that would be completely unmanageable without the hierarchical folder structure for rules ...


Patrick

Yep - in the same boat here! And now especially when zero trust is no buzz word anymore but customers actually want and pay for to implement it, you quickly get loads of rules and VLANs. Having them all straight up and down on a single page with no grouping/hiding sections that not worked on, no fun and risk for errors gets high.

However, I completely understand the underlying issue here and when lookin into that pfSense "separator hack", I understand why nobody wants to touch this :-D

I have though learned, with enough cash on the table, someone is sooner or later eager to take on the most shitty task. That is - can we get a cost estimate of doing the change; what will it cost in man hours to make the needed changes on a rough estimate if we outsource this to a "outside dev" (put it as a one off project on Stackoverflow, LinkedIn or similar)?

The requirements should be quite straight forward but then if someone active on the project could give some technical design ideas/guidelines for the task, that would be great!

[chemlud]

DynDNS, PPPoE -> community problem, no money in it, no solution in sight. That was my impression for some years now. Thank's for confirming this. On the other hand: Community does the beta testing and some forum support (even for the "bussiness" edition, although that has changed somewhat in the past, my impression), so... life is give and take. ;-)

As "community" is not capable of coding (adequate quality , at least), there should be found a way to involve CE users more. There wishes and some money to make them come true. But I guess there is no way to make the community pay alone for new features (at commercial pricing). The same way imho the pfsense CE went the way down to "mostly unmaintained" status...

[chropnsense]

As "community" is not capable of coding (adequate quality , at least), there should be found a way to involve CE users more. There wishes and some money to make them come true. But I guess there is no way to make the community pay alone for new features (at commercial pricing). The same way imho the pfsense CE went the way down to "mostly unmaintained" status...

Actually - this is not a bad idea! Perhaps somekind of a feature wish list where you could "donate $$$" to the feature you want and then, bring on devs from also outside current devs when needed?

I'll talk to my boss and see if we can start offering OPNSense when edge firewalls are needed and then donate some $$$ for each sell for starters..

[mimugmail]

Fright should have the knowhow to do this, but I'd guess it will stay unofficial ;)

[marcquark]

Referring to what bimbar wrote, what do u guys think of this:

Instead of having the small dots, maybe the category colors could instead be used as background color shades in their respective rows? I haven't looked at any of the code yet, but i (perhaps naively) assume that's not a big change, with very little additional risk of maintenance required down the road.
This might already give a big boost to visibility, don't u think?

/e: rough idea just quickly F12ed together. Please ignore that i messed up source/destination settings in some my example rules :-D


/e: and here's the same with some readability improvements around the first icons just to demonstrate how this problem from the 1st screenshot could be circumvented:


If there's enough positive feedback, and perhaps a hint from the core team whether they would be willing to pull such a change in, i'll try to craft a PR :)

[chropnsense]

Referring to what bimbar wrote, what do u guys think of this:

This could work! And it also seems, that pfSense uses "an empty rule" to add the separators (then only hiding some of the rule elements if it uses certain tag). So yes, absolutely better than nothing!

[bimbar]

Referring to what bimbar wrote, what do u guys think of this:

Instead of having the small dots, maybe the category colors could instead be used as background color shades in their respective rows? I haven't looked at any of the code yet, but i (perhaps naively) assume that's not a big change, with very little additional risk of maintenance required down the road.
This might already give a big boost to visibility, don't u think?

/e: rough idea just quickly F12ed together. Please ignore that i messed up source/destination settings in some my example rules :-D


/e: and here's the same with some readability improvements around the first icons just to demonstrate how this problem from the 1st screenshot could be circumvented:


If there's enough positive feedback, and perhaps a hint from the core team whether they would be willing to pull such a change in, i'll try to craft a PR :)

The problem with this is that a rule can have multiple categories. Still, only being able to have one category would be a worthwhile tradeoff, I think.

I also like the idea with the hierarchical rule groups.