From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 18:47:03 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 D92E516A4CE; Mon, 13 Dec 2004 18:47:03 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2723E43D2D; Mon, 13 Dec 2004 18:47:03 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id iBDIl1Fl050819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Dec 2004 21:47:02 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBDIl162037166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2004 21:47:01 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBDIl09O037165; Mon, 13 Dec 2004 21:47:00 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 13 Dec 2004 21:47:00 +0300 From: Gleb Smirnoff To: Andre Oppermann , mlaier@freebsd.org Message-ID: <20041213184700.GA37107@cell.sick.ru> References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41BDABFB.E64C0A31@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: 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: Mon, 13 Dec 2004 18:47:04 -0000 Andre, Max, please don't take this hard. I'm not going to change pfil(4) API, since it has everything required. Max, you showed me that pf has some optimizations. ipfw has only skipto rule, it helps to reduce CPU consumption, but makes 'ipfw show' more complicated. On Mon, Dec 13, 2004 at 03:49:31PM +0100, Andre Oppermann wrote: A> > When managing a complex router with many interfaces the output A> > of `ipfw show` (or ipf/pf analog) is getting long and difficult to A> > understand. It is also important that many packets are checked A> > against the rules that can never be applied to them, wasting CPU A> > cycles. A> > A> > A simple example can be local network router with many inner interfaces A> > and with one interface to internet. Actually filtering is desired A> > only in external interface, and there is no need for local traffic A> > to enter packet fitlering routines, e.g. ipfw_chk(). A> A> Then you argument about long ipfw show doesn't hold... ;) I mean that this feature can be useful on a complicated setups because of maintainability, and even on simple ones, because of speed. A> > I'd like to implement per-interface pfil hooks, like in Cisco A> > world. Each interface may have 'in' list of rules, 'out' list A> > of rules. Current global ip_{input,output}, filters may coexist A> > with per-interface ones, but can be turned off. A> A> Different worlds. I wonder why everything has to "like Cisco". It's A> not always the most clever way they solve a given problem. Andre, I know your dislikes about Cisco, and I share it too. Idea of maintaining separate filter lists for each interface is handy, no matter that it is like in Cisco. Before writing this mail I have a lot of practice with complicated firewall setups, and I have asked several network administrators, who run FreeBSD routers, for their opinion. A> > Our PFIL interface is quite ready for this, and this is very nice. A> A> I don't see any changes to pfil for this. Pfil already passes the A> interface in the argument call. This is something for the packet A> filters (ipfw/pf/ipf) than the pfil API? (Now I speak only about ipfw. But other filters can be used in same manner with a very small changes.) We have list of rules defined in struct ip_fw_chain. At this moment we have only one instance of it - a global variable layer3_chain. What I'm going to do: 1) adding possibility to add new chains and editing them. 2) adding possibility to run ipfw_chk() against a chain other than layer3_chain. 3) Edit ip_fw_check_{in,out}, so that it can call ipfw_chk() on different chains. Supply chain identifier in void arg. Edit ipfw_hook() so that it can register ipfw as a pfil, but with chain different to layer3_chain. 4) add possibility to register a pfil_head for an interface. Once the pfil_head is registered, administrator can call ipfw_hook() on it, and hook ipfw chain to this pfil_head, either in or out. 5) In ip_input()/ip_output() check if interface has pfil_head associated with it. If it does pfil_run_hooks on it. Important points: 1. No API breakage in PFIL, at least I don't see any problems now. 2. No conflicts with current filtering. Interface filters can happily coexist with global ones. 3. Overhead of comparing one pointer. A> > I'll start with creating/editing alternative chains in ipfw. Then A> > we will need to add possibility to register per-interface hooks A> > in pfil, and add possibility to pass one more optional argument A> > from pfil to the filter itself. A> A> Can you provide example how you think the syntax should be? A> A> > I'm glad to see any constructive comments on plan. A> A> You have to be careful not to collide with the "in|out|via" inside A> the rules. It is not going to collide. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE