From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 10:33:21 2004 Return-Path: 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 CF6DB16A4CE; Thu, 9 Sep 2004 10:33:21 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08F0F43D39; Thu, 9 Sep 2004 10:33:21 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1C5MEu-000Ga8-00; Thu, 09 Sep 2004 12:33:16 +0200 To: George S From: Ian FREISLICH In-Reply-To: Message from George S <20040908230429.35820.qmail@web40409.mail.yahoo.com> Date: Thu, 09 Sep 2004 12:33:16 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: ipfw dynamic tcp rule issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 10:33:22 -0000 George S wrote: > > I thought you had to explicitly state the check-state. Anyway, > > I've just noticed that your last rule is #65655 which is higher > > than the max for an unsigned short. Depending how this overflow > > is handled, you might get odd behaviour. This might just result > > in the packet being denied by the default deny rule on the way out > > of fxp0. Try adding a rule just before the default deny to log > > matches. It's almost always useful to do this anyway when playing > > with the ruleset until everything works. > > Sorry, that was a typo on my part... the the last rule should be #65534. In > any event, the packet rule counters are zero for this rule anyway. > > > I would have done the rules as follows: > > > > ipfw add 00010 fwd 10.0.0.1 tcp from 10.0.0.2 to any in via fxp0 > > ipfw add 00020 fwd 192.168.1.1 tcp from any to 10.0.0.2 in via fxp1 > > ipfw add 65534 allow ip from any to any > > > > Is there any particular reason for wanting a stateful firewall in > > this case? > > Yes, it is to differentiate between the following cases of returning SYN+ACK > packets received by fxp1: > > 1. A packet that is responding to the SYN packet originating from A (src ip > 10.0.0.2) > 2. A packet that is responding to a SYN packet originating from B (also with > src ip 10.0.0.2) > > Indeed this works, because if I send my test SYN packet from B (src ip > 10.0.0.2), the returning SYN+ACK triggers rule #9 (allow ip from any to any) > and the packet is not forwarded out the fxp0 interface. > > I am still at a loss as to why the packet counts get updated and yet the > packet itself is not written out on the wire. Any other suggestions? Did you try the logging deny rule? If you did, then I am out of ideas. Ian -- Ian Freislich