I'm running into a small issue with squid on OpenBSD 3.5 (I know...we're working on our 3.9 build right now) and I'm wondering if anyone has run into it, or has any suggestions (other than upgrade to 3.9 unless you know the fix is in there for sure).
We've been seeing 503 No route to host errors on https (only) calls through our squid proxies. After spending some time looking through pf debug logs, it's apparent that pf still has previous connections in FIN_WAIT_2 state (verified in code) in the state table on the machine (while the host itself no longer shows then in netstat). pf is then blocking the new outbound SYN as it's invalid to go from FIN_WAIT_2 to SYN_SENT state (duh). What's really wierd about this is that it is ONLY happening on the CONNECT method, GETs never seem to show this (which points to something I could possibly fix in squid). What I've tried to date to at least work around the issue is: Start squid with -r (-R? don't have it in front of me right now) to turn off SO_REUSEADDR - that unsurprisingly causes much larger issues Configure the port 443 pf rules to have a 10 second tcp.finwait time and set timeout interval to 1 second increase the net.inet.ip.port* range None of this has done much more than possibly reduce the number of 503's we see during the day. It appears that the source port is being used more frequently than pf is flushing the states. The connections are all going to the same destination host (for the most part) and are occuring at a rate of approx. 1/second. The rule that allows the outbound traffic looks like: pass out proto tcp from $extif to <remote_https_svrs> port 443 flags S/SA keep state ( no-sync ) it's since been changed to : pass out proto tcp from $extif to <remote_https_svrs> port 443 flags S/SA keep state ( tcp.finwait 10, tcp.closing 5, no-sync ) Any suggestions??? I'm guessing most people aren't seeing this as they are connecting to multiple hosts, not a select few at a "decent" connection rate. --Bill
