On Mon, Apr 09, 2001 at 09:54:41PM -0700, Wolfgang Rupprecht wrote:
> Does "keep state" now work well enough to use?
> 
> I tried to have a block-all ruleset with holes punched for traffic
> that originated internally.  The outgoing packet would set the state
> and the incoming would be allowed back in via the saved state.  The
> problem was that ipf would fill up the log file with blocked warnings
> from places like "www.foo.com:80->myhost.com:65534".  Clearly the ipf
> state wasn't sticking around for the max-ttl of the packet and at
> tcp-connection close time the last few stragglers would get blocked
> and logged as security problems.  The result was that the logfile so
> littered with spurious messages that one couldn't find the intrusion
> attempts if one wanted.

I'm seeing the same thing.  According to the ipf-howto, it's a feature
(but I don't like it, for the same reason as you).  From the how-to
(http://www.obfuscation.org/ipf/ipf-howto.txt):

  Due to the often laggy nature of the Internet, some-
  times  packets  will  be regenerated.  Sometimes, you'll get
  two copies of the same packet, and  your  state  rule  which
  keeps  track of sequence numbers will have already seen this
  packet, so it will assume that the packet is part of a  dif-
  ferent  connection.   Eventually this packet will run into a
  real rule and have to be dealt with.   You'll often see  the
  last packet of a session being closed get logged because the
  keep state code has already torn down the connection  before
  the  last  packet  has had a chance to make it to your fire-
  wall.  This is normal, do not be alarmed.

  -jm