From owner-freebsd-ipfw@FreeBSD.ORG  Thu May 13 01:32:05 2004
Return-Path: <owner-freebsd-ipfw@FreeBSD.ORG>
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5BF9316A4CE; Thu, 13 May 2004 01:32:05 -0700 (PDT)
Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su
	[213.184.65.80])	by mx1.FreeBSD.org (Postfix) with ESMTP
	id D9E3443D45; Thu, 13 May 2004 01:32:03 -0700 (PDT)
	(envelope-from eugen@kuzbass.ru)
Received: from kuzbass.ru (kost [213.184.65.82])i4D8W1A9098468;
	Thu, 13 May 2004 16:32:01 +0800 (KRAST)
	(envelope-from eugen@kuzbass.ru)
Message-ID: <40A34082.F0182B31@kuzbass.ru>
Date: Thu, 13 May 2004 17:31:46 +0800
From: Eugene Grosbein <eugen@kuzbass.ru>
Organization: SVZServ
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: Luigi Rizzo <rizzo@icir.org>
References: <40A3393F.1391943E@kuzbass.ru>
	<20040513012344.A12373@xorpc.icir.org>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
cc: ipfw@freebsd.org
cc: net@freebsd.org
Subject: Re: ipfw: reset tcp
X-BeenThere: freebsd-ipfw@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: IPFW Technical Discussions <freebsd-ipfw.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>,
	<mailto:freebsd-ipfw-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ipfw>
List-Post: <mailto:freebsd-ipfw@freebsd.org>
List-Help: <mailto:freebsd-ipfw-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>,
	<mailto:freebsd-ipfw-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2004 08:32:05 -0000

Luigi Rizzo wrote:

> > When a rule 'reset tcp' matches, a kernel generates new TCP packet.
> > Will it have to go through ipfw list (from the beginning or not)?
> 
> ipfw2 uses an mbuf flag to bypass the firewall - I am not sure if i
> only used it for the keepalives or also for TCP reset packets

Please check. I suspect it does not enter ipfw itself,
it is not processed by my natd and bad things happen here.

Eugene