Date: Tue, 14 Dec 2004 17:56:36 +0100 From: Andre Oppermann <andre@freebsd.org> To: vova@fbsd.ru Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters Message-ID: <41BF1B44.E3C1453E@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> <41BF008D.AD79C9B@freebsd.org> <1103040032.1060.72.camel@localhost> <1103042558.1060.82.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Vladimir Grebenschikov wrote: > > В вт, 14/12/2004 в 17:13 +0100, Andre Oppermann пишет: > > > > Yes, but is about "how netgraph interfere with ipfw" sometimes, netgraph > > > filtering has nothing common with host filtering. > > > > 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. Hence you need a ng_ipfw node to plug in between. Should be easy for Gleb to write one. > > > > > 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? > > > > > > 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 > > > ... > > > > Ok, this is a start. Now we are getting somewhere. > > > > 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 > > > ... > > > > > > I think there can be better interface if think a bit about it. > > > > Great. Please do so. > > Probably better way to do > > ipfw flow set $custome1 add iface fxp0 del iface fxp1 ... etc > for attaching multiple interfaces to single flow (or chain, does not > matter) > > also > > ipfw flow add $dummy - to add not connected flow > and > ipfw flow default $dummy to make this flow system-default (instead of > old) Ok, I see. Do you mind changing the term "flow" to something else? Because by most accounts a flow is commonly a tcp session for example in Netflow accounting. It would be very confusing to use it here with a total different meaning. > 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. It is not required to change PFIL_HOOKS in any way. Everything we need is already in there. See Luigi's later emails as well. It just requires a slightly different implementation approach. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41BF1B44.E3C1453E>