Hi,
Could we also add ability to keep state between reseting of the rules?
For, example, if I use keepstates, after flushing and setting new rules that could be different by two lines from an old one I kick my self from that server with out any serious reason, I didn't change anything for ssh.
IMHO this could be done by keepstate for a while after flushing, but I didn't
ever look inside this code.
rik
Andre Oppermann wrote:
Let's take a high level view of the issue at hand and the consider some alternative approaches to the situation.
Current situation:
a1. There is a need to have per-interface specific firewall rules. a2. We have multiple firewall packages which have multiple way to specify interface specific rules. a3. With large numbers of interface specific rules the rulesets get complex and hard to manage. a4. This seems to be mainly a problem with ipfw and it's skipto actions.
Request:
b1. Users request a less complicated way of doing interface specific firewall rules.
Analysis:
c1. This is primarily a USER interface/syntax/semantics issue. c2. The different user interface approaches of the different firewall packages we have require different changes to their USER interfaces to make it easier for per-interface rule sets. c3. The firewall packages we have can only deal with one global rule set per protocol family and direction currently. They can't be loaded multiple times and can't have multiple rule set heads (only one entry point).
Implementation approaches:
d1. The PFIL_HOOKS API has one hook per direction per protocol and passes the interface information to the firewall package. d2. Should the PFIL_HOOKS API be changed and be per interface instead of per protocol? All firewall packages need to be modified and we are no longer compatible with the PFIL_HOOKS API. d3. Should the interface specific rules sets be per firewall package in the way that best suits the package? No kernel API is changed. d4. What is the user interface syntax and semantics for each firewall package that someone wants to be modified? Provide examples for those you are interested in. d5. Should it be a replica of Cisco|Juniper approaches or can we do better in syntax or semantics? Think outside of the box.
Lets continue the discussion from here.
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
