[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PF Filter rules & NAT
Henning Brauer wrote:
>> - Why do I need to put the second rule in place?
>> - What special/unique thing is PF doing that it can't track things
>> such that the first inbound rule will take care of the outbound rule from
>>the firewall appliance?
> it is not wanted. EITHER you filter on both interfaces. then you do not want
> to let a state from a foreign interface pass your filter on that interface.
> or you only filter on one interface. then you don't need anything on the
> second one.
> sounds like you want
> block in on dc0 all
> block out on dc0 all
> [your pass rules here]
> no filtering on dc1 at all.
Not filtering on any interface is a -very- bad idea. As if the scenario was that I had 3
interfaces, and I only filtered on the Internet interface, I now have no access control between the
2nd and 3rd interfaces.
When design decisions were being made, why was it decided not to replicate the way IPFilter does
this (i.e. 1 rule would imply the necessity for the other an this would be taken care of)?
Especially since the original target was to largely emulate/replace the IPFilter methodologies?
So far I am struggling to find a reason -not- to do it the IPFilter way, but am very quickly finding
why its a pain in the ass to do it the PF way. (By-and-by I don't intend to be overly critical, I
would just like to understand the design thoughts going in to this).
Some further background information as to why this is painful for me, is that I have been working on
a web driven interface for IPFilter for some 6 months now, and had it about 85% complete. I then
decided that I would rather port it to PF (as I am questioning the future of IPF). However the need
for duplicate rules is causing some consternation for building efficient code (I can make it work,
but its kinda kludgey at the moment). I do also intend to release the interface to the OpenSource
community as soon as I complete the conversion to my satisfaction.