Although at first glance it looks like a MTU problem, it isn't. The "full" sized frames are indeed received at the client's end and one of these packets gets acknowledged, but the other ones did not.
First of all an analysis of the MSS being used by the server. The client advertised 1460, but the server used an MSS of 1352 for the data packets. I assume the MSS in the SYN packet was altered to 1352 on the way to the server. However, the MSS in the SYN/ACK is 1382, which suggests that the alteration of the MSS is different in both directions. This could be due to different configurations or that traffic might be routed asymmetrical. Interesting to investigate further, but not part of the problem I think.
The server sent 4 "full" segment and then stopped sending, this is in line with TCP slowstart, after receiving the ACK to the first segment, it sent only two more segments, which is also in line with TCP slowstart (where each acked segment increses the congestion window with 1 MSS). So the server behavior seems to be normal.
On the client however, I would have expected different behavior. Under normal circumstances, the client would send an ACK immediately after receiving 2 full segments. However, it takes ~40 ms to send an ACK and the ACK only acknowledges the first received segment and not the first 2 received segments. This looks like the TCP stack on the client did only receive 1 segment, waited for a second segment until the delayed ack timer timed out and so it sent an ACK for only the first segment. None the other segments are ACKed (which triggers the server to send retransmissions of the secend segment to finally give up when no ACKs are received for it).
It looks like, even though the segment are seen on the client at the capture point, they are not seen by the TCP stack. You said there is a VPN connection between the client and the server, is this VPN terminated on the win10 client doing the request, or is it a site-to-site VPN terminated outside the win10 client. In case of a VPN client on the win10 system, I suspect it is not functioning correctly. In case the VPN tunnel was already terminated before the traffic reached the client, there must be something else on the win10 client that is interfering. In either case, I'm sure the problem is somewhere inside the win10 client.
