From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 15:32:52 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 EFC6C16A4CE for ; Tue, 14 Dec 2004 15:32:52 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30E8043D3F for ; Tue, 14 Dec 2004 15:32:52 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 27652 invoked from network); 14 Dec 2004 15:21:43 -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 15:21:43 -0000 Message-ID: <41BF07A3.8F1F505E@freebsd.org> Date: Tue, 14 Dec 2004 16:32:51 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo References: <20041213124051.GB32719@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <20041214060341.A77720@xorpc.icir.org> <41BEF746.E8362858@freebsd.org> <20041214063118.B77933@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] 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 15:32:53 -0000 Luigi Rizzo wrote: > > On Tue, Dec 14, 2004 at 03:23:02PM +0100, Andre Oppermann wrote: > ... > > > the struct ifnet. All i meant to say is that we want a unique > > > key, possibly in a small namespace, to quickly locate the per-if > > > private firewall info. How the key is used is not a business of > > > the rest of the kernel. But of course if it is an index in a > > > smallish array (such as ifindex) the thing is fast and clean. > > > > Ok, I'm fine with *this* approach. > > > > This can be done and handled inside ipfw_check_in|out() based on the > > interface pointer information passed in from pfil_run_hooks(). > > > > Then inside IPFW it can be implemented with multiple rule chains > > although I'm not convinced this would be the smartest approach. > > alternatives ? See below. > > Wouldn't it be even better to have per-interface and global rules > > after each other? This way your problem with the general rule > > synching can be solved. > > this is what gleb suggested later today, but i don't think > this solves the problem because sometimes you want the common > processing to be at the beginning, sometimes at the end of the > chain... Plus there is the issue of namespace -- when you do > 'skipto 1000' is this a rule number in the global or the > private chain ? Having only *one* chain (either public or > private) solves the problem although at the price of some > extra copies of the firewall code. I've got something in mind marrying the global/interface approach based on my experience of managing large Cisco per-interface ACL's (which is a royal pain to get right). The big problem of the per- interface approach is the protection of the host itself (control plane in Cisco speak). They have fixed it in newest IOS with so called infrastructure ACL's but that is making life only a little better. Give a bit time to work out the idea some more. -- Andre