per-interface packet filters

[Andre Oppermann]

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