On 23 Feb 00, at 10:49, [EMAIL PROTECTED] wrote:
> We have a PIX (4.4) on which we see frequent "denied" TCP packets with
> the same source/destination as a recently-torn-down legitimate
> connection. First thought was that certain client machines had TCP
> stacks with quirks involving TCP shutdown retransmissions -- but we
> can't find a correlation between the logged denial and any particular
> type of client machine. We've tried adjusting a few parameters (xlate
> timeouts) on the PIX, to no avail. Any ideas?
>
Back in the good old days of browsers, around V2 they would open a
TCP connection, download all the files they needed and then do a proper
close of the TCP session by sending FIN�s and waiting for the ACK�s.
When V3 browsers came along some bright spark decided that it would
be quicker to open a TCP session, download one file and then close it.
By having multiple TCP sessions they could then have multiple
downloads going on at the same time. They also decided that it took to
long to close the TCP session properly by sending the FIN�s and waiting
for the ACK�s so they just sent a RESET and went away.
What is happening is that the PIX will see the RESET go to the web
server and close its connection. However this RESET gets lost on the
way to the server and as it has no ACK�s or retransmission the server
does not see the close. When the web server gets bored after its timeout,
usually one to two minutes it sends a RESET to close the connection.
When the PIX receives this RESET it has no record of this session and
logs it as denied packet.
So we have an Internet full of SYN�s and RESET�s as web browsers set-
up and tear down millions of connections. I can understand them
wanting multiple TCP sessions to improve performance, but why not
open the four TCP sessions and then queue requests on those same four
sessions. To hard to program the queuing that way I suppose.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
