per-interface packet filters, design approach
Josh Kayse
josh.kayse at gmail.com
Tue Dec 14 11:27:11 PST 2004
As someone who is quite new to all of this, take my thoughts with a
grain of salt. That being said, this is my view on the matter.
On Tue, 14 Dec 2004 15:03:27 +0100, Andre Oppermann <andre at freebsd.org> wrote:
> Let's take a high level view of the issue at hand and the consider
> some alternative approaches to the situation.
>
> Current situation:
<snip>
> 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.
I don't think so because as has been said, the PFIL_HOOKS API provides
all the needed information.
> 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.
>
> --
> Andre
> _______________________________________________
<snip>
I think so as it would be the best change, in my oblivious opinion. I
would see it as the firewall package receives the mbuf, checks the
interface, if it is processing rules on the interface, or if there is
a global set of rules, to then continue processing the packet. If it
isn't, it should just return/get out, whatever. I do believe this
would require a change in rule processing. The firewall package would
keep track of the different 'chains' for the rulesets.
As far as writing rules go, I think that it would be simple to make a
script that takes a set of firewall configuration rulesets and merges
them so that they do not collide. I think it take more work to get it
to make it pretty, but I don't see it being impossible.
I'm sure that I'm not understanding exactly what the problem is, so
please, let me know what I'm missing, thanks.
--
Joshua Kayse
Computer Engineering
More information about the freebsd-net
mailing list