From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 08:46:00 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 5553B16A41F for ; Tue, 3 Jan 2006 08:46:00 +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 137BE43D60 for ; Tue, 3 Jan 2006 08:45:57 +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 k038jrAZ015434 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 09:45:54 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k038jqZB028105; Tue, 3 Jan 2006 09:45:53 +0100 (MET) Date: Tue, 3 Jan 2006 09:45:51 +0100 From: Daniel Hartmeier To: Attila Nagy Message-ID: <20060103084551.GF17829@insomnia.benzedrine.cx> References: <43B96824.20608@fsn.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43B96824.20608@fsn.hu> 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 08:46:00 -0000 On Mon, Jan 02, 2006 at 06:51:32PM +0100, Attila Nagy wrote: > Any ideas? RFC1323 support includes TCP window scaling (wscale), which affects pf stateful filtering. There have been bugs with that in the past, but the code in 6.x should contain all fixes for them. Maybe you found a new one. When you say "a simple pass only ruleset", do you mean a ruleset consisting of a single "pass all" rule (i.e. not creating state), or one that includes "pass keep state" (and possibly "scrub") rules? If the latter, there's one possible user mistake that could result in the effects you're seeing. If you filter statefully, but create state not on the initial SYN packet of each TCP connection, but a subsequent one, pf doesn't note the relevant wscale factors (seen only during the first two packets of the handshake), which can have precisely this effect, stalling connections after a while (when one peer starts to actually use large windows, making use of its negotiated wscale factor). It's also possible that this would occur more often with specific OS peers, as the OS (and TCP settings, like receive buffer size) influence the wscale factors being used. 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. If that's not it, can you enable pf debug logging (pfctl -xm), note pfctl -si output, then reproduce a failing connection, then run pfctl -si again, compare the output (looking for any counters increasing the obvious ones), and checking /var/log/messages for any lines from pf? Daniel