fortigate ip connection

edit

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.

yeah it seems like packet 29 is rst-flag from sever due to client not responding from its side with fin-ack.. in that case i would see server-rst on FW but i dont..

That would be the case if the server sends a RST without first sending the FIN, but since it sends a FIN first, (that is not answered by a FIN from the client) it could possibly log this differently. An "IP connection error" might be the way it is reporting FINs that do not get a FIN back. You would have to check with Fortinet Support.

In any case, for an HTTPS connection, it is really weird for a client to keep the connection open after the server has sent a FIN (indicating it will not send any more data after that point). Do you know what kind of client is doing this? It seems the client waits 120 seconds to send the FIN after receiving the FIN (it is not a response to the servers RST, as that would mean you would have seen ~165 ms delay between the two packets), that is also weird behavior. So I would mark this as a problem on the client side (or in any infrastructure between the client and the capture point).|

The weird ACKs seem cosmetic to me, somehow the ACK of the packet resulting in the RST is kept, but since the ACK flag is not set, it should not treated as "insignificant". Some security products might trip on this as it is not common, but AFAIK the RFCs don't explicitly say the ack field should be zero when the ACK flag is not set.