Ah, that explains a lot! Thanks for the information. Yes, what Otto had 
mentioned was indeed confusing me :-)

Especially when I look at the following statement from the faq:
http://www.openbsd.org/faq/pf/filter.html#state

" When a rule creates state, the first packet matching the rule creates 
a "state" between the sender and receiver. Now, not only do packets 
going from the sender to receiver match the state entry and bypass 
ruleset evaluation, but so do the reply packets from receiver to sender."

Plus, in the pf.conf(5)  stated that floating was the default behaviour, 
which I now notice is what Otto pointed out, but that meant me think 
even more that the pass out would not have been needed, since the state 
was created with the pass in.

I've added a "pass out from ! self" rule that should take care of 
everything that I've allowed to come in. It also explains why the state 
table will grow so much, if there's a state entry for each direction. 
I'll look more into the tag part which should be even better as well as 
that link on optimization.

Is the state direction tracking something that changed at one point of 
the PF development or has it always been like that?

Thanks again to all for the responses and references,
Steve

Stuart Henderson wrote:
quoted text
> On 2008-05-08, Otto Moerbeek <otto@drijf.net> wrote:
>   
>> On Thu, May 08, 2008 at 07:23:41AM -0400, Steve Johnson wrote:
>>
>>     
>>> Thanks for the information. This is the first time that I've used PF as a 
>>> router based firewall and not with NAT. I didn't know that the state was on 
>>> a per interface basis, and not global to the system. So this means that 
>>> unless I want to allow all outbound traffic from my firewall, I need to 
>>> have a matching pass out rule for all the pass in rules for which I want to 
>>> restrict the inbound interface (ie for which I don't want to put just pass 
>>> for)?
>>>       
>> No, states are by default global and not tied to an interface. See man
>> pf.conf. 
>>     
>
> But they are sensitive to direction; if you keep state for a new incoming
> session on an interface, you:
>
> 1. *do* pass _return_ traffic associated with that connection,
> 2. *do not* pass the incoming traffic that created the state (or any
> following incoming traffic from the same connection) out of another
> interface to send to another machine
>
> For 2. you can either pass the outbound traffic separately, or you
> can tag the inbound traffic and pass outbound traffic that has been
> tagged.
>
> ...
>   
>>> The reason I need quick, especially on a few of these rules, is that the
>>> firewall will be establishing 3 to 6 thousand new sessions per second
>>>       
>
> You should read this set of articles:
> http://undeadly.org/cgi?action=article&sid=20060927091645