From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 00:22:11 2007 Return-Path: X-Original-To: freebsd-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 59DDB16A400 for ; Thu, 19 Apr 2007 00:22:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 4541D13C465 for ; Thu, 19 Apr 2007 00:22:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 18 Apr 2007 16:50:23 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 1E653125AE2; Wed, 18 Apr 2007 17:22:10 -0700 (PDT) Message-ID: <4626B633.7070903@elischer.org> Date: Wed, 18 Apr 2007 17:22:11 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: AT Matik References: <46268689.1080301@elischer.org> <462688B5.9080305@elischer.org> <200704181951.20174.asstec@matik.com.br> In-Reply-To: <200704181951.20174.asstec@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, ipfw@freebsd.org 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:22:11 -0000 AT Matik wrote: > 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 > > 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 > 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. this comes from working within ipfw. there is a bit of "mess" added to make it (an IP layer firewall) know about and handle link level packets. It might be cleaner to have a separate link level firewall then to have the hacks in ipfw to make in know about L2 stuff. This is not something I'm working on, just something that occurs to me every time I have to look inside the firewall code. > > that is perfectly possible today as it is I KNOW it can do it.. but it is a mess as far as information scope is concerned. > >> 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 > circumstances, there is no need to reinvent the wheel you can write sh functions in ipfw? I don't get your point here. > > >> 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 > course could not be solved be actual ipfw functions or rc.firewall script > engineering I work on a product that monitors on a bridge and at the IP router level. We have some of our own changes to ipfw. the rules get to be fairly tricky when you have so many entry points coming into the same firewall. front, but if I use a "keep state" for a packet at one layer then I can not use "keep-state" in another situation for anything that may see the same packet as there is no way to keep separate states for different entry points. having separate firewalls for diffrent entry points allows me to have different state at different layers even for the same packet. > >> 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 usefull > example? Of course as well a case which could not be solved by ipfw as it is? the later (HTTPFW) is just a fanciful idea and in fact I already do that by 'fwd' rules to forward such packets to a proxy, however there might be more general solutions. > > > Joćo > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"