Subject: Re: pf for NetBSD
To: None <email@example.com>
From: Wolfgang Rupprecht <wolfgang+gnus20021106T082313@wsrcc.com>
Date: 11/06/2002 08:32:08
> > 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.
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.)