Insert a title between rules to easily find an area to work on
-
Tabs wouldn't be good for that. I'm not sure we'd ever consider subdividing rules.
In general, if your ruleset is that complex, you've designed something wrong. Obviously there are many exceptions to that, but most things can be done elegantly in a screenful of rules or less using aliases.
If we did any kind of separation, it may be something more like subheadings:
- Title
+ Rule 1
+ Rule 2 - Title 2
+ Rule 3
+ Rule 4
Headings could be collapsed if need be, but would be expanded by default.
Could even use anchors and a drop-down at the top to jump to a specific header, but tabs would be too busy and would hurt more than they help.
- Title
-
Headings could be collapsed if need be, but would be expanded by default.
A Collapsible category header would work better than tabs ;)
A Search drop down field using the category's would also work well and may be easier to implement.
-
jimp, that is precisely what I was thinking. That would make rules management so much easier for really big sites that have large rule bases. Even with lower number of rules though which most sites can get by with being able to create subheadings would make management of the rule base easier to manage IMHO based on my experience with Checkpoint which does have a feature similar to that.
-
Only page found on web for development http://devwiki.pfsense.org/PfSenseDevHome :-[
Can anyone give me some Ideas of how Pfsense is storing input data?
-
This is just an idea but with the current version as it is cant you just have a disabled rule that doesnt really do anything. You could for instance block a private network that you dont use in your environment and then disable that rule. Then you set a description on that rule that explains what the next "group" of rules is doing. OFc there is some flaw like, uuh what if I realy want to disable a rule then I will mix all the disabled rules up and so on but hey, its just an idea :P
-
This is just an idea but with the current version as it is cant you just have a disabled rule that doesnt really do anything. You could for instance block a private network that you dont use in your environment and then disable that rule. Then you set a description on that rule that explains what the next "group" of rules is doing. OFc there is some flaw like, uuh what if I realy want to disable a rule then I will mix all the disabled rules up and so on but hey, its just an idea :P
I have actually done that in some spots to help identify sections. I setup a deny for 1.1.1.1 to 1.1.1.1 with a description and disable the rule to make it a gray color. It is still difficult to scan through the rules and find them though while still reading the description. I do have disabled rules in the rule bases for temporary rules that need to be enabled or disabled at times or if it is an experimental change.
Subheaders would of course be much easier to scroll through and find if they are created in such a way that they are easy to spot (assuming a different color or shade of gray and hopefully even smaller height if possible to make them really different and visible).
-
If this ever does get implemented for some big sites I might try to use the Floating tab for most rules (setting interface and direction when needed of course). I can then group all my VPN rules (incoming and outgoing) in one section (and easily find them in a long list) instead of split between a LAN for outgoing and IPSEC tab for incoming as it is now. Yes the list will be longer in the Floating tab but with subheaders overall i think it will be easier to work on with different VPN sites having their own VPN subheader sections on one tab.
-
This is just an idea but with the current version as it is cant you just have a disabled rule that doesnt really do anything. You could for instance block a private network that you dont use in your environment and then disable that rule. Then you set a description on that rule that explains what the next "group" of rules is doing. OFc there is some flaw like, uuh what if I realy want to disable a rule then I will mix all the disabled rules up and so on but hey, its just an idea :P
I have actually done that in some spots to help identify sections. I setup a deny for 1.1.1.1 to 1.1.1.1 with a description and disable the rule to make it a gray color. It is still difficult to scan through the rules and find them though while still reading the description. I do have disabled rules in the rule bases for temporary rules that need to be enabled or disabled at times or if it is an experimental change.
Subheaders would of course be much easier to scroll through and find if they are created in such a way that they are easy to spot (assuming a different color or shade of gray and hopefully even smaller height if possible to make them really different and visible).
For such a grouping feature I would also suggest the ability to collapse the entiregroup to make it invisible and only show the group header. Like a +/- you press to show/hide the group.
-
I sum to this pledge. Even with a low number of rules in the ruleset this will be of GREAT help.
The existance and use of Aliases do NOT avoid the need of rules grouping as it has been said.
Suppose that you have 10 openVPN servers. The need to have 10 servers is because you want to limit access to the internal resources based on which goup is connecting and you keep groups apart by giving them different subnets. May be there is another way to do this but, so far, I have not found it as the ip pool asignment is configured in the openvpn server not anywere else.
As you cannot create alias entries that have both an ip address (the server part) AND a given port (mainly because this is what a firewall rule is for) then your aliases cannot help in locking a given VPN group to a pool of internal resources (server:port pairs).
So I end up with 5 or more rules for each external vpn group that messes up the interface. It would be lot easier to manage if I could have a collapsible header for each of the blocks. Not that it cannot be done without this but a big improvement anywhere.
This could perhaps be done by adding a collapsableover the group of rules but as rules listing is actually built based on a draggable table, this table should have to be cut-off in portions (you cannot div a group of table rows in a single table) thus loosing the draggability (can you have inter-table draggable cells?). Besides the headers maintenance in the config.xml structure should be taken into account.
Anyway BIG thanks for a GREAT product to all those who have dedicated their time, effor and intelligence to making it possible.
-
Interesting idea for sure.
