Re: pf NAT confusion

[Joel Schander <jschande@cuc.edu>]

On Thu, 4 Apr 2002, Ben Goren wrote:

> I think part of your confusion comes from the difference between
> state handling in pf and ipf. (At least, that was a big part of the
> confusion for me when I was trying to figure this out for the first
> time.) In ipf, the state table is consulted for all packets on all
> interfaces.  If you create state on an incoming packet on the
> internal interface, the state is remembered for the matching
> incoming packet on the Internet interface. By contrast, pf's state
> tables are interface specific.  Although state was created for the
> incoming packet on the internal interface, pf knows nothing of it
> when the matching packet arrives inbound on the Internet interface.
> It *does* recognize it when it's outbound on the internal interface.

That was the fount of my confusion.  Thanks for your help and
clarification.  Now that my understanding is set right: AARGH! -- this
means our rulesets on boxes we don't NAT on are going to get
complicated, for reasons akin to the example you gave. The great beauty
of IPF other than being stateful -- at least for someone who learned on
IP Chains -- was that I didn't have to write a rule for every interface
a packet traversed when using a default-deny policy...now we've got to
do that again to some extent.

I'm now baffled as to why the FAQ doesn't mention the state table
differences in the ``Differences between PF and IPF'' section, as seems
to make IPF => pf ruleset conversion less than trivial for most
default-deny rulesets.

curious: Was there a public discussion of why pf went with multiple
state tables vs one?  I'm curious to see what outweighed the ruleset
simplicity the single state table provided.

Joel