Probably not enough information, but here is some general guidance:
If other remote clients are ok and do not experience the symptom, the problem probably is not with the server. It may be the connection for that client.
A retransmit typically means that a packet was not acknowledged, so there usually will not be actual
"errors" in a packet capture. It means that one end was sending the packets, and the other was not acknowledged. You may want to perform the capture from both ends, to determine if the retransmit is one-way only, or both ways.
If you ping your host from the client, what is the response time? If it is over 150 ms, you may have a suboptimal connection.
The server network adapter setting for Large Send Offload should be disabled. Windows should be smart enough to know it cannot send large packets to machines on different subnets, but sadly this is not always the case. If your server is a hyper-v guest, this is almost certainly the problem.
MTU. Generally speaking, accessing a server remotely when you are not on the same subnet, the MTU should always be whatever the smallest MTU is between the two endpoints. And that usually means the client. For remote clients that connect over VPN, it is not uncommon to have an MTU of 1400 or even lower. It can be beneficial to set the server MTU to match what the lowest MTU would be, to avoid issues where MTU cannot be discovered properly (sometimes referred to as black hole routers). To find the MTU for your connection you can enter the following command from your client:
ping -f -l xxxx <server ip>
Where xxxx is the MTU size. Start with 1400. If it works, increase it until it displays the message "Packet needs to be fragmented but DF set". If 1400 does not work, decrease it until it does. The highest number that works is your payload size. Add 28 to the payload size and that is your MTU.
You can set the server MTU at the following registry location:
HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{guid of the network adapter}
FYI - RDP packets are always sent with the "Do Not Fragment" bit set.
What I see here is that 192.168.0.10 is attempting to open HTTP connections to 139.179.55.181, and these connections are being refused.
The high port numbers that you're seeing originate as the source port numbers for the connections from 192.168.0.10. The RST segments are getting sent back to the exact same port numbers that the SYN segments came from. This is how TCP is supposed to work.
Best Answer
Just as a comment, sometimes what appear to be duplicate frames can be caused by network adapter drivers getting mixed up with capture drivers.
If you see a clear pattern of TCP retransmission backing off, that is, a retransmit at 1 second, then 2, then 5, it's likely an actual problem with retransmissions, rather than a capture artifact.
To troubleshoot retransmission problems for real, within a local subnet that you control and are sure isn't just saturated with traffic, replace or adjust:
If one of the boxes is more likely to be involved in a retransmission than the others, you can infer which link this might be from that.