From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 16:13:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15A0416A4CE for ; Tue, 14 Dec 2004 16:13:08 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C9B343D49 for ; Tue, 14 Dec 2004 16:13:07 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 28161 invoked from network); 14 Dec 2004 16:01:58 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 16:01:58 -0000 Message-ID: <41BF1112.77C18DC6@freebsd.org> Date: Tue, 14 Dec 2004 17:13:06 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vova@fbsd.ru 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 16:13:08 -0000 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