From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 8 23:04:30 2004 Return-Path: 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 633AB16A4CF for ; Wed, 8 Sep 2004 23:04:30 +0000 (GMT) Received: from web40409.mail.yahoo.com (web40409.mail.yahoo.com [66.218.78.106]) by mx1.FreeBSD.org (Postfix) with SMTP id 5082643D2D for ; Wed, 8 Sep 2004 23:04:30 +0000 (GMT) (envelope-from c0sine@yahoo.com) Message-ID: <20040908230429.35820.qmail@web40409.mail.yahoo.com> Received: from [69.196.154.220] by web40409.mail.yahoo.com via HTTP; Wed, 08 Sep 2004 16:04:29 PDT Date: Wed, 8 Sep 2004 16:04:29 -0700 (PDT) From: George S To: Ian FREISLICH In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: ipfw dynamic tcp rule issue X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 23:04:30 -0000 Hi Ian, --- Ian FREISLICH wrote: > George S wrote: > > Hi Ian, > > > > Thanks for your response. > > > > Yes, the behaviour is exactly as I describe. What happens is that on its > way > > back, the SYN+ACK packet with DST IP/PORT 10.0.0.2 and SRC IP/PORT > > 69.196.154.5/80 hits rule #1 where there is a keep-state. This causes > ipfw > > to check all dynamic rules implicitly (as per the ipfw manpage). > > > > Since the SYN+ACK packet is part of a recently setup connection, there > is a > > skipto to rule #10. Rule #10 does not match because there SRC/DST are > not > > correct, so it then passes to rule #11, which does match (and its > counters > > are updated). > > > > The problem is that the packet never finds itself on the fxp0 wire. I > will > > give your check-state suggestion a try but I think the check-state is > > implicit within rule #1. > > http://www.geocities.com/c0sine/fbsdipfw.gif > > 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? Kindest regards, George S __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail