On 7/11/06, Bill Marquette <[EMAIL PROTECTED]> wrote:
Try setting tcp.closed lower for the rule in question. It's default is 90 seconds, which in some cases appears to be a little high (although I believe there is a good reason for it, I just can't find it).
I'm wondering if this is the same problem discussed here: http://www.benzedrine.cx/pf/msg07510.html Daniel Hartmeier wrote:
Check pfctl -si output before and after reproducing the problem, and note which counters are increasing. That shows if and why pf is blocking packets when the ruleset shouldn't.
In my case (with http_load), "state-mismatch" increments each time I get a "No route to host" error. One factor which I forgot in that 'pf' thread is that TIME_WAIT state is only on the host initiating the close. If the remote host asked for the socket to be closed, the local TCP stack releases the socket immediately for reuse. And then when OpenBSD immediately reuses the same socket (RLSP), and happens to make a connection to the same remote server and service as the old socket (thus matching the existing 'closing' state table entry), pf sees the existing state and blocks the new SYN packet. This is easiest to trigger with something like 'http_load' where the client makes many thousands of connections to a single remote server/port. Kevin
