From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 5 01:04:23 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7078416A46D for ; Mon, 5 Nov 2007 01:04:23 +0000 (UTC) (envelope-from r.fulton@auckland.ac.nz) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF3413C4A6 for ; Mon, 5 Nov 2007 01:04:22 +0000 (UTC) (envelope-from r.fulton@auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2285618687; Mon, 5 Nov 2007 12:48:39 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXoO1ZlpkYH0; Mon, 5 Nov 2007 12:48:38 +1300 (NZDT) Received: from bluebottle2.insec.auckland.ac.nz (bluebottle2.insec.auckland.ac.nz [130.216.76.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DDB7118647; Mon, 5 Nov 2007 12:48:38 +1300 (NZDT) Message-ID: <472E5A58.5090707@auckland.ac.nz> Date: Mon, 05 Nov 2007 12:48:40 +1300 From: Russell Fulton User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: john.w.court@nokia.com References: <932971.53959.qm@web88014.mail.re2.yahoo.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, gbell72@rogers.com Subject: Re: IPFW Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 01:04:23 -0000 john.w.court@nokia.com wrote: > Hmm, I may well be missing something very obvious but rule 01000 seems > to be doing exactly what it says it will. Are you sure you meant "deny" > rather than "allow" on rule 01000 ? Note that it is immediately after the check state rule. What the Gardner intended was to drop established tcp traffic that was not part of a session for which there was already state. In fact this rule is redundant since (assuming I've read the rule set correctly) such traffic will get caught by the final deny rule. What is odd about this problem is that it appears to be a timeout problem and thus probably not related to the firewall at all. To me it seems that the initial SYN packet is getting lost and the retry gets through, hence the delay. I suggested to Gardner that he log all dropped packets so he can see if it really is the firewall which is causing the problem. Russell