From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:42:29 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 EA28616A4CE; Tue, 14 Dec 2004 14:42:28 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3654A43D46; Tue, 14 Dec 2004 14:42:28 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CeDsf-000Cca-M8; Tue, 14 Dec 2004 17:42:25 +0300 From: Vladimir Grebenschikov To: Andre Oppermann In-Reply-To: <41BEE281.607DD0A8@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Tue, 14 Dec 2004 17:42:25 +0300 Message-Id: <1103035345.1060.55.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov 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 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 14:42:29 -0000 =F7 =D7=D4, 14/12/2004 =D7 13:54 +0100, Andre Oppermann =D0=C9=DB=C5=D4: > Vladimir Grebenschikov wrote: > =20 > > > I know this. We have a well commented firewall scripts, we store them= at RCS, > > > we do many things to make our life easier. But my practice (and my co= llegues) > > > shows that per interface filters are easier to understand and maintai= n when > > > number of interfaces grows up to 20 and more, and they all are logica= lly > > > different - clients, servers, DMZs, hardware, nated networks, etc. > > > > > > Again, this feature is not for all. This is for people who build comp= licated > > > routers on FreeBSD. It is not going to hurt standard host setups. > >=20 > > Frankly speaking, I think ppl who runs real-life router with firewall o= n > > fbsd will vote for this feature by both hands. > >=20 > > I sometime, some years ago I had freebsd router with near to 100 > > interfaces (mostly VLANs and FrameRelay customers connections, and > > about 10 physical media interfaces). This router transfers some > > thousands packets per second. It was real trouble to rearrange ipfw > > table with large (very large) number of jumps (especially in case when > > some number range was exceeded and renumbering required). Also most of > > router interrupt time was spent in going through client multiplexer par= t > > of ipfw ruleset. > >=20 > > Gleb, please do the feature. > >=20 > > Why we do not avoid bottlenecks where they can be avoided ? > > With that feature we can select right rules for specific interface > > without do linear search by ruleset. >=20 > It's about HOW to implement it. I think the ways proposed so far are > hackish, too complex and outside of our framework which was very well > designed and allows this kind of feature without any of the hacks and > extentions discussed here. >=20 > We have to properly DESIGN these feature instead of just hacking them > in. Well, I agree, that it is about how to design it. But I do not think that proposed solution is hackish, and I not alone with it. 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 2. Plug firewall on any specific interface=20 3. Plug firewall on any network packet processing input/output (current) 4. Plug it into bridging code In this list interface looks very reasonable as place to plug, for me it looks even more reasonable then our usual input/output, because packet on ether output gives you no idea where it come from - local or remote, especially in complex setups, with often changing interface names and indexes (pptp server for example). It is not clear how to write rules that affects only local traffic and transit traffic (I do not mean loop- back when talk about local traffic) > > Do we what FreeBSD be used on large scale of setups or we have think > > targeting ? >=20 > As long as there is a sufficient large base we are not opposed to it. > What we are opposed at is tradeoffs which favor one particular minority > special interest over the general average interest set. >=20 > > -- off-topic -- > > Days ago FreeBSD was only OS flexible and stable enough to be use in > > complex, customized network environments, but now-days it is not so :(, > > and you know why. > > -- off-topic -- (not for flame or advocacy, just emotion) >=20 > No, I don't know why and this isn't helping any. >=20 --=20 Vladimir B. Grebenchikov vova@fbsd.ru