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>