knitti wrote:
* 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
