From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 16:42:44 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 ACDC016A4CE; Mon, 13 Dec 2004 16:42:44 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0281143D6A; Mon, 13 Dec 2004 16:42:44 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CdtHX-00028S-00; Mon, 13 Dec 2004 17:42:43 +0100 Received: from [217.83.4.147] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CdtHW-0007HW-00; Mon, 13 Dec 2004 17:42:43 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 13 Dec 2004 17:43:26 +0100 User-Agent: KMail/1.7.1 References: <20041213124051.GB32719@cell.sick.ru> In-Reply-To: <20041213124051.GB32719@cell.sick.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1765365.jWeuOKUX53"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412131743.36722.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 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 16:42:44 -0000 --nextPart1765365.jWeuOKUX53 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 13 December 2004 13:40, Gleb Smirnoff wrote: > Dear networkers, > > I finally managed to pronounce my idea, although I'm afraid > of a bikeshed it is going to be burried under. > > When managing a complex router with many interfaces the output > of `ipfw show` (or ipf/pf analog) is getting long and difficult to > understand. It is also important that many packets are checked > against the rules that can never be applied to them, wasting CPU > cycles. That's an error in the ruleset evaluation code then. Pf automatically jumps= =20 over rules that cannot be matched after one failed. If you have a block of= =20 1000 rules "on xl0" and the first one does not match because of the interfa= ce=20 pf will continue checking with rule #1001. I am not sure if such shortcuts= =20 are possible for ipfw, but I suggest looking into that first. > A simple example can be local network router with many inner interfaces > and with one interface to internet. Actually filtering is desired > only in external interface, and there is no need for local traffic > to enter packet fitlering routines, e.g. ipfw_chk(). This is a very special case and you will only penalize the common case (i.e= =2E=20 looking for a per interface ruleset etc.) > I'd like to implement per-interface pfil hooks, like in Cisco > world. Each interface may have 'in' list of rules, 'out' list > of rules. Current global ip_{input,output}, filters may coexist > with per-interface ones, but can be turned off. If you want this behavior you can - for instance - use pf anchors. For=20 instance like this: anchor INTERN on xl0 anchor EXTERN on tun0 ... see the "ANCHORS AND NAMED RULESETS" section of pf.conf(5). You can even do= =20 things like: anchor SPAM on tun0 proto tcp from any to any port smtp You can then load rulesets into each anchor and pf steps into the ruleset o= nly=20 if the conditions are meat. Of course you can also look at the rules in a=20 given anchor, expand the complete ruleset and have "normal" rules in=20 conjunction with the anchors. That's the way to go - in my humble opinion. > Our PFIL interface is quite ready for this, and this is very nice. > I'll start with creating/editing alternative chains in ipfw. Then > we will need to add possibility to register per-interface hooks > in pfil, and add possibility to pass one more optional argument > from pfil to the filter itself. pfil already passes the interface. So if you really want to do this - I=20 personally don't think it is the right way to go - you can do it *inside* t= he=20 pfil hook without messing the API for everything else. I don't see what is= =20 missing in the current API that will stop you from doing so. > I'm glad to see any constructive comments on plan. Sorry, I don't see the point. If you are going to penalize the common case = for=20 this I will object. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1765365.jWeuOKUX53 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBvca4XyyEoT62BG0RAioFAJ927rx3XLNGCCk3A24VlYWO2FD5gQCcCDHF 2xJQEHZblyjIbKIY65fuFvQ= =KXPT -----END PGP SIGNATURE----- --nextPart1765365.jWeuOKUX53--