TCP Retransmissions after [FIN, ACK] same tcp stream

edit

In frame 117548, the client responds to the RST in frame 117547. From the ACK (13685090) it can be deducted that the clients TCP stack never saw the FIN packets (with the phantom byte) and therefor the SEQ of the RST is out-of-window (it expects a SEQ of 13685090 instead of 13685091).

You said in a trace on the client the FIN packets are visible. Analysis of the SEQ/ACK numbers on the client side might give insight of what is happening. If the SEQ/ACK numbers are the same on the clientside, then something between the capture point on the client side and the TCP stack is causing the problem.

Are you able to share the client- and serverside packet captures on a public fileshare? If there is sensitive information in there, you can use TraceWrangler to anonimize the capture files.

It seems rather odd. As both system are in different subnets there is something connecting these two networks. This could be a statefull firewall doing things a bit odd. Or a router with ACL's that might be causing this.

Do you see the same issue if you are on a the same network as the webserver?

[FIN, ACK] sending without getting prior [FIN] from counter part

The server didn't receive an ACK to 96116. The retransmissions are requests to ACK the FIN/ACK.
Finally in 117547 the server resets the connection.

In this screenshot a bogus route was added to the server so packets could not get back to the client.
Capture is done on the server side.
After 5 seconds of inactivity (frames 40-41), the server tries to close connection.
The FIN/ACK never gets to client so there is no ACK back to server. Frames 42,43,44 are server asking again.