Date: Tue, 14 Dec 2004 19:00:32 +0300 From: Vladimir Grebenschikov <vova@fbsd.ru> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters Message-ID: <1103040032.1060.72.camel@localhost> In-Reply-To: <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> <41BEE281.607DD0A8@freebsd.org> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=D0=92 =D0=B2=D1=82, 14/12/2004 =D0=B2 16:02 +0100, Andre Oppermann =D0=BF= =D0=B8=D1=88=D0=B5=D1=82: > Vladimir Grebenschikov wrote: > >=20 > > =C3=B7 =C3=97=C3=94, 14/12/2004 =C3=97 13:54 +0100, Andre Oppermann =C3= =90=C3=89=C3=9B=C3=85=C3=94: > > > 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. > >=20 > > 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. >=20 > It breaks the PFIL_HOOKS API. If I not mistaken Gleb claims that do not break: G> please don't take this hard. I'm not going to change pfil(4) API, G> since it has everything required. > > Let's imagine our firewall framework as general firewall, able to be > > plugged on different layers, after that you can get following: > >=20 > > 1. Plug firewall (dedicated chain) between netgraph nodes >=20 > [Doesn't work before and after PFIL_HOOKS API breakage. You'd need a > ipfw netgraph node for that anyway.] Yes, but is about "how netgraph interfere with ipfw" sometimes, netgraph filtering has nothing common with host filtering. > > 2. Plug firewall on any specific interface > > 3. Plug firewall on any network packet processing input/output (current= ) > > 4. Plug it into bridging code >=20 > How do you represent this complexity in syntax and semantics? First what jump into my mind: flows management: ipfw flow add $customer1 iface fxp0 ipfw flow del $customer2 iface fxp0 ipfw flow set $customer1 iface fxp1 ipfw flow default $extrenal ipfw flow list changes rules for flow ipfw flow use $customer1 add ip from any to any ... or as variant ipfw -F $customer1 add ip from any to any ... I think there can be better interface if think a bit about it. > 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. Again, Gleb do not going to change API or ABI. > So give me syntax and semantics examples how you want to operate this > functionality? =20 see above=20 > We do not dispute the need for per-interface rules. =20 Ok, so we agree that it is good idea ?=20 > The question is *how* to represent it. =20 > In fact that is the only question because the functionality is already th= ere,=20 > only hard to use. I haven't yet seen how you make it easier to use other= =20 > than saying "ipfw per-interface". But that doesn't answer my question. So what=20 > > In this list interface looks very reasonable as place to plug, for me i= t > > 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) >=20 > With cloned devices you have a problem anyway. Who puts the correct > ipfw chain head pointer into struct ifnet in your example? devd perhaps? mpd while start pptp session, or like > Please enlighten me. --=20 Vladimir B. Grebenchikov vova@fbsd.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1103040032.1060.72.camel>