[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Public web server behind a PF bridge, crap clients

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
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.