Removing connections from stateful table

[reinke]

When does the pix remove a tcp connection from the stateful table (exact trigger)?

Background:

A valid tcp connection is terminated by the client:

1. TCP FIN from client to server

2. TCP FIN ACK from server to client

3. TCP FIN from server to client

4. TCP FIN ACK from client to server

The last packet (4.) is dropped by the pix: DENY TCP (no connection).

Looks like pix removing the connection entry as a result of packet no. 3.

Therefore, we can see such a syslog message everytime a connection is closed legally, which results in a lot of synthetic traffic.

Is this a bug? Short term solution is to disable those syslog messages?

Thanks in advance

Edgar

[yusuff]

The default behavior of the PIX Firewall is to track the shutdown sequence and release the connection after two FINs and the ACK (acknowledgment) of the last FIN segment. This quick release heuristic enables the PIX Firewall to sustain a high connection rate, based on the most common closing sequence, known as the normal close sequence. However, in a simultaneous close, both ends of the transaction initiate the closing sequence, as opposed to the normal close sequence where one end closes and the other end acknowledges prior to initiating its own closing sequence (see RFC 793). Thus, in a simultaneous close, the quick release forces one side of the connection to linger in the CLOSING state. Having 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. Using the sysopt connection timewait command creates a window for the simultaneous close down sequence to complete.

Use the 'sysopt connection timewait' command to enable the timewait option when you have an end host application whose default TCP terminating sequence is a simultaneous close.

Note The sysopt connection timewait command requires more system resources than default processing and, when in use, may impact PIX Firewall performance. Noticeable performance impact is most likely when there is limited memory available, and when there is highly dynamic traffic such as HTTP.

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/s.htm#1026942

[reinke]

Thanks ... an excellent answer!

Edgar