Date: Tue, 14 Dec 2004 14:27:01 -0500 From: Josh Kayse <josh.kayse@gmail.com> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach Message-ID: <7c8f279204121411275ad919f9@mail.gmail.com> In-Reply-To: <41BEF2AF.470F9079@freebsd.org> References: <41BEF2AF.470F9079@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7c8f279204121411275ad919f9>