Revision history [back]

One obvious problem in both traces is that your MTU size of 1500 bytes is not available across the whole path.

The good_client.pcapng filtered on 49169 shows PMTUD working from client towards the server and Cisco at 192.160.10.1 indicating the nex_hop MTU size is 1446 The server however does not set the DF bit in the IP header and therefore doesn't learn about the available MTU size and reverts to the default MTU size of 536 after several retransmissions 2.4 seconds into the session.
tcp.port==49169 && (icmp||tcp.len>=536||tcp.flags&7)

The server side shows that PMTUD is not working correctly, obviously because the router didn't send an ICMP message back. The MSS is changed to 536 bytes and the DF bot is turned on in a last effort to tge the data to the client. Note that this is the 'good' case

In the bad case the MSS is staying at 1460 bytes and the data never reaches the client resulting in the server resetting the connection with a tcp.seq sitting at the first segment tcp.seq<1462 and tcp.flags&4

So the problem is that the Cisco at the server side does not send ICMP messages when fragmentation is required. Ideally they should adjust the MSS when the SYN packets flow to avoid the need for the ICMP message in the first place.

Whether or not this solves all your problems I cannot tell but I would start here...

Regards Matthias