Greetings, My apologies to those who may have encountered this request on 'openbsd-misc'.
Our obsd border router has worked for years with our PF ruleset, but sometime in the middle of January, we discovered that our webpages were stalling when viewed 'externally' (from remote Internet clients) but not internally; the webserver is a box on the 10.0.0.0/24 internal LAN that is accessed externally through a 'pf' rdr rule. Stalls only happen if our 'redirected' webserver is a Solaris 2.6 box (using either of two different httpds), but if we redirect http traffic to an SVR4 box, there is no problem. Capturing traffic on the internal LAN and on the 'external' interface of the obsd border router shows 'pf' dropping outgoing traffic from the webserver after a few data blocks have been sent. The webserver continues to send data while awaiting acks that it never gets, and completes the GET request (so it records a '200' in its logs). Note that the obsd router has three ethernet interfaces; one serves the main internal lan, another serves a restricted wireless lan, and the third connects to a Speedstream 5861 ADSL router to the 'Net. Workstations on the wireless segment do not experience stalls on http connections (the 'pf' rules for this segment are more restrictive). Only remote connections from the Internet get http stalls. Timeouts are on the order of 24 hours, so essentially they are permanent. I have tried all of the suggestions from archived mailing list posts without success, including proper 'keep state' and 'flags S/SA' filter rules, adjusting MTUs and MSSs (one poster reported that his combination of obsd and Speedstream 5861 ADSL router required certain max-mss adjustments -- could have applied to us), and scrub rule changes didn't help. FWIW, we had _no_ keep state rules for years when everything worked, but of course state is implicit on NAT rules. From a remote Internet host, a 'telnet 80' session to our webserver and GET of an 8500 byte html page produced the 'tcpdump' captures (one on the internal interface, one on the external interface) and 'pf' debug logs which can be downloaded here: ftp://ftp.cybertheque.org/pub/pf-debug/ I would really appreciate some assistance in doing the arithmetic to analyze the state errors and also some insight and suggestions for remedies. Needless to say my version of obsd is not recent, and I don't currently have the option to update it due to the mix of custom code and hardware in use (a major project for later). However, I have been successful backporting features and fixes into this kernel for quite awhile. A recent poster on 'openbsd-misc' reported some PF/NAT issues and later said essentially 'never mind -- hardware issue'; I have no evidence of NIC or CPU issues but wonder if this recent dramatic change in behavior could be hardware related. Much thanks for any help, Michael
