From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 09:08:31 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D3EE16A41F for ; Tue, 3 Jan 2006 09:08:31 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63C0643D49 for ; Tue, 3 Jan 2006 09:08:30 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.12.11) with ESMTP id k0398S1P009411 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 10:08:29 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k0398SZX032616; Tue, 3 Jan 2006 10:08:28 +0100 (MET) Date: Tue, 3 Jan 2006 10:08:28 +0100 From: Daniel Hartmeier To: Attila Nagy Message-ID: <20060103090828.GG17829@insomnia.benzedrine.cx> References: <43B96824.20608@fsn.hu> <20060103084551.GF17829@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060103084551.GF17829@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.10i Cc: freebsd-net@freebsd.org Subject: Re: Is RFC1323 support flawed? (only with pf enabled) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 09:08:31 -0000 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