Date: Wed, 18 Apr 2007 19:51:19 -0300 From: AT Matik <asstec@matik.com.br> To: freebsd-ipfw@freebsd.org Cc: ipfw@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: ipfw changes being contemplated.. Message-ID: <200704181951.20174.asstec@matik.com.br> In-Reply-To: <462688B5.9080305@elischer.org> References: <46268689.1080301@elischer.org> <462688B5.9080305@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704181951.20174.asstec>