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:
On 2008-05-08, Otto Moerbeek <[EMAIL PROTECTED]> 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
