Re: per-interface packet filters

From: Andre Oppermann (andre_at_freebsd.org)
Date: 12/14/04

  • Next message: Vladimir Grebenschikov: "Re: per-interface packet filters" 
    Date: Tue, 14 Dec 2004 17:13:06 +0100
To: vova@fbsd.ru

    Vladimir Grebenschikov wrote:
    >
    > > 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.

    But this is not correct. He changes the way PFIL_HOOKS are called.

    > > > Let's imagine our firewall framework as general firewall, able to be
    > > > plugged on different layers, after that you can get following:
    > > >
    > > > 1. Plug firewall (dedicated chain) between netgraph nodes
    > >
    > > [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.

    Nontheless you need to call it from somewhere?

    > > > 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"?

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

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

    Again, he does. In a major way.

    > > So give me syntax and semantics examples how you want to operate this
    > > functionality?
    >
    > see above
    >
    > > We do not dispute the need for per-interface rules.
    >
    > Ok, so we agree that it is good idea ?

    Yes. If it is smartly done it can help a lot. If not well done it
    can wrek havrok. 

    -- 
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Vladimir Grebenschikov: "Re: per-interface packet filters"