From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 5 00:11:35 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 2289F16A418 for ; Mon, 5 Nov 2007 00:11:35 +0000 (UTC) (envelope-from john.w.court@nokia.com) Received: from mgw-ext13.nokia.com (smtp.nokia.com [131.228.20.172]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB1713C4C4 for ; Mon, 5 Nov 2007 00:11:34 +0000 (UTC) (envelope-from john.w.court@nokia.com) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA509MPO015007; Mon, 5 Nov 2007 02:09:43 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 02:09:34 +0200 Received: from siebe101.NOE.Nokia.com ([172.30.195.47]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 02:09:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Nov 2007 08:09:20 +0800 Message-ID: In-Reply-To: <472E5A58.5090707@auckland.ac.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPFW Problem Thread-Index: AcgfPUCCrcGgK/c0TBqLPaR9G7/RdQAAj8Gw References: <932971.53959.qm@web88014.mail.re2.yahoo.com> <472E5A58.5090707@auckland.ac.nz> From: To: X-OriginalArrivalTime: 05 Nov 2007 00:09:23.0999 (UTC) FILETIME=[1F166AF0:01C81F40] X-Nokia-AV: Clean 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 00:11:35 -0000 Yep bad advice on my part, should have re-read the man page first. One thing that might also be useful however would be to use the "ipfw -e -d show" command when this occuring so that the expired and dynamic rule set is also displayed. I have logged bugs with IP6 keep-state in the past but not IP4 so this might not help but it can't hurt having more information :-) Cheers John=20 -----Original Message----- From: ext Russell Fulton [mailto:r.fulton@auckland.ac.nz]=20 Sent: Monday, November 05, 2007 9:49 AM To: Court John.W (Nokia-ES/Robina) Cc: gbell72@rogers.com; freebsd-ipfw@freebsd.org Subject: Re: IPFW Problem 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