Hi Liudvikas,
First let me preface this by asking if there are any problems, or just
concern over log messages. The following information should resolve any
problems, or help explain log messages. If there are no functional issues,
it may not be necessary to implement the command.
The following command should help:
sysopt connection timewait
This will force each TCP connection to linger in a shortened TIME_WAIT
state of at least 15 seconds after the final normal TCP close-down sequence.
From the documentation:
The connection timewait option is necessary for end host applications whose
default TCP terminating sequence is simultaneous close instead of the
normal shutdown sequence (see RFC 793). In simultaneous close, four TCP
segments are exchanges in the shutdown instead of the normal three.
The default behavior of the PIX Firewall is to track the normal three
shutdown sequence and release the connection after the third segment. This
quick release heuristic enables the PIX Firewall to sustain a high
connection rate.
However with simultaneous close, the quick release will force one side of
the connection to linger in the CLOSING state (see RFC 793). Many sockets
in the CLOSING state can degrade the performance of an end host. For
instance, some WinSock mainframe
clients are known to exhibit this behavior and degrade the performance of
the mainframe server. Old versions of HP/UX are also susceptible to this
behavior. Enabling the connection timewait option enables a "quiet time"
window for the abnormal close down
sequence to complete.
I hope that helps,
Lisa Napier
Product Security Incident Response Team
Cisco Systems
At 10:49 AM 02/23/2000 -0500, [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?
>
>Liudvikas Bukys
>[EMAIL PROTECTED]
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
Lisa Napier
Product Security Incident Response Team
Cisco Systems
http://www.cisco.com/warp/public/707/sec_incident_response.shtml
PGP: A671 782D 2926 B489 F81A 3D5E B72F E407 B72C AF1F
ID: 0xB72CAF1F, DH/DSS 2048/1024
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
