per-interface packet filters, design approach
rik at cronyx.ru
Tue Dec 14 06:48:33 PST 2004
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
ever look inside this code.
Andre Oppermann wrote:
>Let's take a high level view of the issue at hand and the consider
>some alternative approaches to the 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
> b1. Users request a less complicated way of doing interface specific
> firewall rules.
> 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).
> 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.
More information about the freebsd-net