Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 09 Sep 2004 12:33:16 +0200
From:      Ian FREISLICH <if@hetzner.co.za>
To:        George S <c0sine@yahoo.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: ipfw dynamic tcp rule issue 
Message-ID:  <E1C5MEu-000Ga8-00@hetzner.co.za>
In-Reply-To: Message from George S <c0sine@yahoo.com>  <20040908230429.35820.qmail@web40409.mail.yahoo.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1C5MEu-000Ga8-00>