 | 1 | initial version |
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.
