 | 1 | initial version |
Setting the TCP FIN flag just means you are done sending data. That is usually done in a separate packet with no data, but it is also allowed to set the FIN flag on the last segment of data that is being sent. After the FIN from side A, side B is still allowed to send data until it sends a FIN itself.
So nothing out of the ordinary in your packet flow. The only thing I can imagine is that there is a session based device between the client and the server. Think of firewalls, load-balancers (Application delivery controllers), etc. Usually these devices will have a long timeout for an established session and will have a short timeout after one of the sides has sent a FIN. So in your case, how much time is there between the packets? Also please check the IP TTL of the RST and compare it to the other packets coming from the server. If they differ, that could be an indication that an intermediate device was responsible for the RST and not the server itself.
If these tips don't help, please provide the pcap files if possible (use Tracewrangler to remove sensitive information and translate IP addresses if there is sensitive data in the pcap files). You can use any public file sharing service (like One Drive, Dropbox, Google Drive, etc)
