Date: Tue, 14 Dec 2004 17:49:11 +0300 From: Roman Kurakin <rik@cronyx.ru> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach Message-ID: <41BEFD67.2060501@cronyx.ru> In-Reply-To: <41BEF2AF.470F9079@freebsd.org> References: <41BEF2AF.470F9079@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41BEFD67.2060501>