Date: Tue, 14 Dec 2004 19:42:38 +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: <1103042558.1060.82.camel@localhost> In-Reply-To: <41BF1112.77C18DC6@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> <1103040032.1060.72.camel@localhost> <41BF1112.77C18DC6@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=F7 =D7=D4, 14/12/2004 =D7 17:13 +0100, Andre Oppermann =D0=C9=DB=C5=D4: =20 > > Yes, but is about "how netgraph interfere with ipfw" sometimes, netgrap= h > > filtering has nothing common with host filtering. >=20 > Nontheless you need to call it from somewhere? Yes, If, for example, I do connection of two VPNs without accessiong them into host packet flow and want to firewall something inside. > > > > 2. Plug firewall on any specific interface > > > > 3. Plug firewall on any network packet processing input/output (cur= rent) > > > > 4. Plug it into bridging code > > > > > > How do you represent this complexity in syntax and semantics? > >=20 > > First what jump into my mind: > >=20 > > 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 > >=20 > > changes rules for flow > > ipfw flow use $customer1 add ip from any to any > > ... >=20 > Ok, this is a start. Now we are getting somewhere. >=20 > A "flow" would be what Gleb calls a "chain"? Yes, exactly, just read Gleb's message. > > or as variant > > ipfw -F $customer1 add ip from any to any > > ... > >=20 > > I think there can be better interface if think a bit about it. >=20 > Great. Please do so. Probably better way to do =20 ipfw flow set $custome1 add iface fxp0 del iface fxp1 ... etc for attaching multiple interfaces to single flow (or chain, does not matter) also=20 ipfw flow add $dummy - to add not connected flow and ipfw flow default $dummy to make this flow system-default (instead of old) > > > This is the tricky problem to be solved first. Then we can start arg= uing > > > about implementation issues, API's, ABI's and other related things. > >=20 > > Again, Gleb do not going to change API or ABI. >=20 > Again, he does. In a major way. Ok, I do not want to deep into details until I'll look code, but I guess it is possible to extend PFIL_HOOKS API without harming existing applications. > > > 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 > Yes. If it is smartly done it can help a lot. If not well done it > can wrek havrok. >=20 --=20 Vladimir B. Grebenchikov vova@fbsd.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1103042558.1060.82.camel>