Date: Wed, 8 Sep 2004 16:04:29 -0700 (PDT) From: George S <c0sine@yahoo.com> To: Ian FREISLICH <if@hetzner.co.za> Cc: freebsd-net@freebsd.org Subject: Re: ipfw dynamic tcp rule issue Message-ID: <20040908230429.35820.qmail@web40409.mail.yahoo.com> In-Reply-To: <E1C4hUx-0007tW-00@hetzner.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ian, --- Ian FREISLICH <if@hetzner.co.za> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040908230429.35820.qmail>