Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Jan 2006 10:08:28 +0100
From:      Daniel Hartmeier <daniel@benzedrine.cx>
To:        Attila Nagy <bra@fsn.hu>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Is RFC1323 support flawed? (only with pf enabled)
Message-ID:  <20060103090828.GG17829@insomnia.benzedrine.cx>
In-Reply-To: <20060103084551.GF17829@insomnia.benzedrine.cx>
References:  <43B96824.20608@fsn.hu> <20060103084551.GF17829@insomnia.benzedrine.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 03, 2006 at 09:45:51AM +0100, Daniel Hartmeier wrote:

> To rule this out, make sure you either don't create state at all, or
> create state on the first SYN when you do (look for any "pass" rules
> which don't also include "keep state"). pfctl -vss prints the wscale
> factors being honoured by pf for each state.

Also note that there is an implicit (invisible) "pass" rule (without
"keep state") at the bottom of every ruleset, matching when no rule
matches at all.

For instance, the following ruleset would show the problem:

  pass in all keep state

Say, the machine has two interfaces and is IP forwarding a connection
going through both (incoming on one, outgoing through the other). pf
filters each packet on both interfaces (in on the first and out on the
second, in on the second and out on the first).

In this case, the initial SYN would come in on the first interface,
match your explicit rule, and create state on the first interface. This
state does NOT cover the packets flowing (in reverse direction) on the
other interface, pf evaluates the ruleset again when the initial SYN
leaves the second interface. Now the explicit rule does not match (the
direction is out, not in), but the packet passes due to the implicit
"pass" rule at the end (not creating state). Then the SYN+ACK comes
back in through the second interface, doesn't match a state, causes
ruleset evaluation, matches your explicit rule, and creates state. Now
this state is created based on the SYN+ACK, and hasn't seen the initial
SYN, hence pf doesn't properly track wscale factors in this state, and
will/might stall the connection eventually.

Make sure the implicit "pass" rule is never used, by adding an explicit
rule matching everything (the default policy, either blocking everything
or passing everything with "keep state") at the top of your ruleset.

Daniel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060103090828.GG17829>