Date: Thu, 19 Apr 2007 06:31:13 -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: <200704190631.14634.asstec@matik.com.br> In-Reply-To: <4626B633.7070903@elischer.org> References: <46268689.1080301@elischer.org> <200704181951.20174.asstec@matik.com.br> <4626B633.7070903@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 18 April 2007 21:22, Julian Elischer wrote: > 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. > I think it is better for me to understand and wait for what you wrote in=20 another mail:=20 > "I think I'll firm up my proposal a bit before trying to explain too much= =20 more" > > 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. > you mean logging? good there are some missing points today but adding bette= r=20 log sensus does not need a general ipfw change right? > >> 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. ah you know what I mean, not in ipfw but in the ipfw script you can use any= sh=20 programming you want and use it=20 > > >> IPFW could be called from the IP layer, or from the FW of a lower laye= r. > >> 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 don't know if skipping ip packages to one point and layer2 packages to=20 another is not exactly what this is about, I also do not know how you can=20 achieve statefull firewall on layer2 packages, sounds kind of nasty to me look, anyway this seems to become then a product hard to understand for mos= t=20 users I really like to repeat that ipfw is one of the best application we have=20 because of it's straight forward logic, easy to understand by anybody ( sin= ce=20 the beginning). And overall it is working. Nothing is perfect but changing = it=20 would be a wrong decision. Changing how it works will bring lots of problem= s=20 and obviously bugs and bugs and bugs. Imagin how many people want to hang y= ou=20 if their production servers do not firewall anymore. I only remember a smal= l=20 thing like the proto ip versus proto ipv4 thing which was not well announce= d.=20 Anyway, enhancements (if really) can be interesting but only so long as the= y=20 do not touch any of the actual functionality and logic. Otherwise you bette= r=20 write a ipfw_nested fork to do what you pretend to do and then it is up to= =20 the people use it or stay with what they are used to. 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?200704190631.14634.asstec>