From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 00:06:24 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1E9B16A400 for ; Thu, 19 Apr 2007 00:06:24 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id C0CEC13C4C3 for ; Thu, 19 Apr 2007 00:06:23 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l3IN21E1064476; Wed, 18 Apr 2007 20:02:01 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Wed, 18 Apr 2007 19:51:19 -0300 User-Agent: KMail/1.9.5 References: <46268689.1080301@elischer.org> <462688B5.9080305@elischer.org> In-Reply-To: <462688B5.9080305@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704181951.20174.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: ipfw@freebsd.org, Julian Elischer Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 00:06:24 -0000 On Wednesday 18 April 2007 18:08, Julian Elischer wrote: > Also One possibility of 6 would be to make a family of > firewalls rather than one, that work together, > Hi=20 probably I do not understand what you are trying to achieve ... basicly I am missing a reason for this "making it complicated" the beauty of ipfw is it's easy use and easy to read, short, it is clear=20 so why do you want to complicate it? > e.g. L2FW (layer 2 firewall) that knows about MAC packets etc > but calls IPFW for ip packets should it want to do so. that is perfectly possible today as it is > IPFW in turn the ability to call TCPFW > for some sessions and TCPFW would know about > modules that in turn know about different > protocols. you can perfectly write sh functions which you call under certain=20 circumstances, there is no need to reinvent the wheel > IPFW could be called from the IP layer, or from the FW of a lower layer. > each layer would have the ability to do some inspection of the payload to > help decide which higher layer might be relevant. please give a real world reason and/or example for this need, which then of= =20 course could not be solved be actual ipfw functions or rc.firewall script=20 engeneering > > I can imagine an HTTPFW which does some small tests and if it needs to can > divert the session to a proxy. It would know some basic rules of HTTP. for > example. could you please let out your imagination and tell some practical and usefu= ll=20 example? Of course as well a case which could not be solved by ipfw as it i= s? Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br