>This is excactly the reason, why I don't wanted to handle this in a
>Do so, provide us with the patch.
The more that I think about this, the more I think that the ruleset
should be pre-processed before it is applied. The system is meant to be
abstracted anyway, and there are few reasons that I can think of that
there should be a 1-to-1 mapping of GUI-configured rules to actually
applied rules, so long as they do as they're supposed to.
I can think of several other uses for a pre-processor. In particular,
I've been thinking about how to bind NAT rules to firewall rules. They
would be linked to eachother, and certain attributes would be
unchangeable in the firewall rule. It would also make it possible for a
user to check a box to add or remove the firewall rule mapping either
when adding or editing a rule. The lack of that ability can be irriting
when one forgets to check the 'Auto add' box. I also fear that some
users of the software, unfortunately, don't have the prowess to
indevidually maintain NAT and Firewall rules for the same thing. I just
need to figure out how to maintain the mapping between the two with the
least possible overhead.
Anyway, if the pre-processor would be desirable to anyone besides me,
I'll write it. I've got a few methods in mind, it's just a matter of
which would be the most efficient in PHP.
>I was also wondering, if it makes
>sense, to allow to select how to respond to a blocked packet
>(return-icmp-as-dest(port-unr) for example). I left that out because of
In my opinion, that option should be hidden and expanded with an
just hidden in config.xml. It would definately confuse most users. It
might be acceptable, though, if the responses were listed as simple terms.