On Fri, Dec 06, 2002 at 12:37:32PM -0800, Stephen Gutknecht (OBSD-PF) wrote:
> *** We did notice a few problems where pf rules we wrote using the > firewall's "keep state" option would incorrectly block packets returned as a > result of an incoming connection *** > > That is a pretty good description of what I thought we observed that > prompted me to start this thread. In our case, we suspected the problem > seemed to favor some users over others. So I had assumed it was the browser > / TCPIP stack thee web browser was using? To investigate this kind of problem, I'll need more specific data. A tcpdump of a blocked packet (tcpdump -nvvvepi pflog0) and the state entry (pfctl -vss) you expect the packet to match. Also, enable debug logging (pfctl -x m) and watch for 'bad state' messages in /var/log/messages. I pass several thousand http connections statefully each day, and I get a couple of blocked packets daily. In every case, either the state has timed out already or the peer was re-using a port with a new initial sequence number before the old state has timed out. You can compensate both by adjusting the tcp state timeout values. A certain percentage of real traffic will always be dropped, there's just too many weird stacks or browsers out there that don't honor 2MSL. If you can reliably reproduce connection drops or stalls, the tcpdump and state information will help explain what is going on. Daniel
