ipfw changes being contemplated..

[Julian Elischer]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"