Date: Tue, 14 Dec 2004 16:02:37 +0100 From: Andre Oppermann <andre@freebsd.org> To: vova@fbsd.ru Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters Message-ID: <41BF008D.AD79C9B@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <1103017203.1060.25.camel@localhost> <1103035345.1060.55.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Vladimir Grebenschikov wrote: > > В вт, 14/12/2004 в 13:54 +0100, Andre Oppermann пишет: > > It's about HOW to implement it. I think the ways proposed so far are > > hackish, too complex and outside of our framework which was very well > > designed and allows this kind of feature without any of the hacks and > > extentions discussed here. > > > > We have to properly DESIGN these feature instead of just hacking them > > in. > > Well, I agree, that it is about how to design it. > But I do not think that proposed solution is hackish, and I not alone > with it. It breaks the PFIL_HOOKS API. > Let's imagine our firewall framework as general firewall, able to be > plugged on different layers, after that you can get following: > > 1. Plug firewall (dedicated chain) between netgraph nodes [Doesn't work before and after PFIL_HOOKS API breakage. You'd need a ipfw netgraph node for that anyway.] > 2. Plug firewall on any specific interface > 3. Plug firewall on any network packet processing input/output (current) > 4. Plug it into bridging code How do you represent this complexity in syntax and semantics? This is the tricky problem to be solved first. Then we can start arguing about implementation issues, API's, ABI's and other related things. So give me syntax and semantics examples how you want to operate this functionality? We do not dispute the need for per-interface rules. The question is *how* to represent it. In fact that is the only question because the functionality is already there, only hard to use. I haven't yet seen how you make it easier to use other than saying "ipfw per-interface". But that doesn't answer my question. > In this list interface looks very reasonable as place to plug, for me it > looks even more reasonable then our usual input/output, because packet > on ether output gives you no idea where it come from - local or remote, > especially in complex setups, with often changing interface names and > indexes (pptp server for example). It is not clear how to write rules > that affects only local traffic and transit traffic (I do not mean loop- > back when talk about local traffic) With cloned devices you have a problem anyway. Who puts the correct ipfw chain head pointer into struct ifnet in your example? devd perhaps? Please enlighten me. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41BF008D.AD79C9B>