Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Nov 2007 08:09:20 +0800
From:      <john.w.court@nokia.com>
To:        <r.fulton@auckland.ac.nz>
Cc:        freebsd-ipfw@freebsd.org, gbell72@rogers.com
Subject:   RE: IPFW Problem
Message-ID:  <DBA4167E9E1EB44D8476A6F928BE52452B53A4@siebe101.NOE.Nokia.com>
In-Reply-To: <472E5A58.5090707@auckland.ac.nz>
References:  <932971.53959.qm@web88014.mail.re2.yahoo.com> <DBA4167E9E1EB44D8476A6F928BE52452B5379@siebe101.NOE.Nokia.com> <472E5A58.5090707@auckland.ac.nz>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?DBA4167E9E1EB44D8476A6F928BE52452B53A4>