> > How does pf handle state from an outgoing connection that is closing?
> > Under ipf the state for an outgoing TCP connection appeared to be
> > torn down as soon as the local side closed the connection.  [...]  If
> > pf handled that state better and kept the TCP-filter state around for
> > 2xMSL that would be a vast improvement.
> 
> But still not very good.  There is no reason why a TCP connection
> cannot be closed in one direction and still keep streaming data in the
> other more or less indefinitely.  If ipf - or any such firewalling
> package - tears down its state as soon as one direction closes, I would
> call that a priority-1 bug.

I never explicitly tested ipf with half-closed connections, but I did
observe lots of problems at closing time when both sides attempted to
do a 3-way close (fin / fin-ack / ack).  I'd often see extra acks or
tcp-rst's hitting the firewall instead of making it to the TCP stack
machinery.  Essentially a day of running all outgoing TCP connections
with a state-based filter filled up /var/log/messages with pages of
gripes.  Some of the remote systems were remarkably persistent in
trying to get their last few packets to me.

-wolfgang
-- 
The cpu is willing but the powersupply is weak.

spider food: http://www.wsrcc.com/baddream/usenet/
(NOTE: The email address above is valid.  Edit it at your own peril.)