Network Security: Logical "NOT" Support for Packet Filter, DNAT, etc...
It would easily save a lot of work if we had the possibility to make a mass-rule with "NOT" operators, like accepting all traffic for all directions EXCEPT for some host or network etc..
Like ACCEPT ANY ANY !Host"A"
The ability to negate source, service and destination objects in the firewall and nat policy would be very helpfull.
I need to forward all services except smtp to a host. If i am able to negate, this is done by negating the smtp service object for this policy entry.
Be able to make rules like the iptables ! (exclamation mark), so allow all but ... One can work around that now, but it would be a lot easier if this would be possible.
Would also be great for QoS. Give garanteed bandwith to everything except...
Oliver, I totally agree with you, and there is already a request about this: http://feature.astaro.com/forums/17359-astaro-security-gateway-feature-requests/suggestions/182157-network-security-logical-not-support-for-packet
Oliver Hamel commented
If i am able to negate i can match every public IP by putting the 3 RFC 1918 networks in a group and negate this group in the accordant firewall policy line (!RFC1918).
And one more:
I want to match every network outside of my internal.
Just a negated group with my internal networks inside (!group_internal_networks).
Frank, I totally agree with you, and there is already a request about it: http://feature.astaro.com/forums/17359-astaro-gateway-feature-requests/suggestions/182157-packet-filter-rules-with-logical-not-entry
Oxiel Contreras commented
It will ease the configuration quite a lot, please implement it ....
Actually, not packet filter rules, but objects (definitions) with the possibility of negation. Also, groups containing negated objects. They would be extremely useful in NAT rules as well.
Tim Cronin commented
This would help clear up the packet filter list. As it is right now, you would need two packet filter rules to accomplish the role of this single rule.
Drawback: some end-users may find this confusing at first and it may cause inadvertent attack vectors (as with a lot of config).