knitti wrote:
quoted text
>>> * pf "synproxy state" does not affect these CLOSE_WAIT sockets since
>>>   the SYN proxy is only active during connection establishement.
>>>   But it is a good to use anyway since it prevents IP spoofing.
>> Why not? Just test it out. What happen if you get a DDoS on your httpd
>> as an example, or try to connect to it. You send a packet to httpd, it
>> will create a socket to reply to your connection request and send the
>> source IP ACK and then wait for the reply ACK that will never come. So,
>> what does this do to your httpd then??? How many sockets will you have
>> pending responses here? You use one socket per user connection to your
>> httpd. You have 25 real users accessing your httpd and 1,000 fake users
>> without pf in the path. I will aksed you this simple question then.
> 
> don't confuse the CLOSE_WAIT with a SYN flood. if httpd doesn't close
> its socket, the proxy will neither. And even if it did, this doesn't
> close httpd's
> socket. I think I'm repeating myself, but the problem is *not* that httpd
> waits for any client data. I _has_ seen the clients FIN (or it wouldn't go into
> CLOSE_WAIT), but keeps its side open.

I am not. May look like that at first glance, but I am not. I am only 
saying that using PF in front of httpd will reduce the possible number 
of httpd close_wait you might see. By default httpd can only support up 
to 256 connections, unless you increase it and compile it again. PF do 
not have that limits and as such would help keeping your httpd going 
even if you have still a bunch of close_wait states.

As to if PF would close the httpd sockets, no it wouldn't. If I miss 
lead you in that path, then I am sorry. What will affect your close_wait 
time (when you reach that point) are the tcp stack value, witch I am 
reluctant to suggest to adjust as they sure can create way more harm 
then goods. But even then, there is limits to what can be done.

My point with PF here was that it would reduce the possible numbers of 
close_wait state you could possibly see in the first place, witch is one 
of the original goal of the question.

If you want to reduce the time it stay in that stage, then you need to 
adjust some of the tcp stack value, but it will also introduce other 
effects doing so, witch is impossible for me to say, or anyone else I 
think what's the optimum value for you in your specific setup. I 
wouldn't try to say I would know what's best for you in that case. I can't.

Hope this clear that part.

Best,

Daniel