From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 17:25:39 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 EC80B16A4CE; Tue, 14 Dec 2004 17:25:38 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5459443D1F; Tue, 14 Dec 2004 17:25:38 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CeGQb-0006Aj-89; Tue, 14 Dec 2004 20:25:37 +0300 From: Vladimir Grebenschikov To: Andre Oppermann In-Reply-To: <41BF1B44.E3C1453E@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <1103017203.1060.25.camel@localhost> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <1103042558.1060.82.camel@localhost> <41BF1B44.E3C1453E@freebsd.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Tue, 14 Dec 2004 20:25:36 +0300 Message-Id: <1103045136.1060.93.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov 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 Reply-To: vova@fbsd.ru 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 17:25:39 -0000 =F7 =D7=D4, 14/12/2004 =D7 17:56 +0100, Andre Oppermann =D0=C9=DB=C5=D4: > > > > Yes, but is about "how netgraph interfere with ipfw" sometimes, net= graph > > > > filtering has nothing common with host filtering. > > > > > > Nontheless you need to call it from somewhere? > >=20 > > Yes, If, for example, I do connection of two VPNs without accessiong > > them into host packet flow and want to firewall something inside. >=20 > 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"? > >=20 > > Yes, exactly, just read Gleb's message. > >=20 > > > > 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. > >=20 > > Probably better way to do > >=20 > > ipfw flow set $custome1 add iface fxp0 del iface fxp1 ... etc > > for attaching multiple interfaces to single flow (or chain, does not > > matter) > >=20 > > also > >=20 > > ipfw flow add $dummy - to add not connected flow > > and > > ipfw flow default $dummy to make this flow system-default (instead of > > old) >=20 > Ok, I see. >=20 > 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 gues= s > > it is possible to extend PFIL_HOOKS API without harming existing > > applications. >=20 > It is not required to change PFIL_HOOKS in any way. Everything we need i= s > already in there. See Luigi's later emails as well. It just requires a > slightly different implementation approach. Greate --=20 Vladimir B. Grebenchikov vova@fbsd.ru