per-interface packet filters

[Vladimir Grebenschikov]

В вт, 14/12/2004 в 17:56 +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.

Yes, exactly what I mean, but whole ipfw subsystem should support
multiple chains or flows.

> > > > > > 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.

Term chain is not so bad, only objection - it has relation to Linux's
ipchains but has a little common with it.

> > 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.

Greate

-- 
Vladimir B. Grebenchikov
vova at fbsd.ru