 | 1 | initial version |
It appears that the server has an idle timeout of 8 seconds and closes the connection graciously by sending close-notify Alert and Fin packets. The client was probably using a browser and most, if not all, browsers maintain a pool of connections. This connection had been returned to the pool in which case there was no application thread to handle the half-closure and direct TCP to complete the closure. It further appears that the browser’s pool manager has an idle timeout of 120 seconds, and the server has a Fin-Wait timeout of 120 seconds which produces the coincidence of a Reset from the server and a Fin flag from the client.
It also appears that the Resets from the server have not been relayed to the client. The client repeats its Fin flags, seeking an ack, but the server always responds with a Reset which is not relayed to the client. The subsequent Resets are constructed with different sequence numbers because the server is now in a different state and their purpose is not to close the connection but to indicate that the connection no longer exists. It is strange that the firewall will relay client Fin packets but not server Reset packets.
Problems like this are very common yet often produce highly varied and bewildering results. The cardinal rule for connection pools is that they must have an idle timeout that is shorter than the timeouts of all the relevant servers. This ensures that connections are never left in a half-closed state. Weird problems arise when firewalls and other devices along the path have shorter timeouts and terminate half-closed connections in their different ways, usually without signalling the termination by sending a packet to either the client or the server.
One solution in this case is to increase the idle timeout of both the server and the firewall to more than 120 seconds. A better solution might be to reduce the browser’s idle timeout to less than 8 seconds, assuming that the firewall’s timeout is greater. It’s a salutary lesson for all network managers to ensure that the timeouts in all devices are set appropriately and not left with their default values.
