Wolfgang Rupprecht <wolfgang@wsrcc.com> writes:

> Does anyone here use IPF with the TCP state option?  This set of rules
> works most of the time.  Every once in a while the state generated at
> "out @2" seems to fail.  I'm assuming its a timing issue is some sort.
> Anyone else seeing this?

> I'm seeing intermittent spurious blockings as follows:
> 
>     May 25 06:44:30 capsicum ipmon[118]: 06:44:30.141093 de0 @0:4 b
>     ftp.netbsd.org,supfilesrv -> c460058-a.frmt1.sfba.home.com,64808
>     PR tcp len 20 552 -A

What NetBSD version?

My largest problems with ipf:

	(1) socket state isn't really tracked, it is recreated.  It
	    would be much nicer to somehow attach the socket info to
	    the ipf line, and let the socket feed back into ipf what
	    the state is.  This would do several things.  for one, the
	    same thing (packet -> state) wouldn't have to be done
	    twice.

	(2) The state entries are not dynamic.  Once you hit 2048,
            you're out of state entries.  This is once again a problem
            with duplicating state.  If a UDP socket closes, for
            instance, I'd rather have the state vanish, not time out
            in 2 minutes.

	(3) There is no way to filter other than icmp, udp, and tcp.
            I'd like to be able to filter out all other "crap" like
            GRE tunnels from hosts I don't have a tunnel to, but the
            ipf doesn't do this.

--Michael