RST packets sent by both client and server during file transfer

edit

What seems also odd to me is the fact that each RST packet can be seen on the receiving side but not on the sending side.

1. The RST packets claiming to be from the client and the RST packets claiming to be from the server start at approximately the same time.
2. The RST packets claiming to be from the client are seen only on the server, and the RST packets claiming to be from the server are seen only on the client.
3. There are the same number of RSTs in each direction.
4. With one exception, the IP TTLs on the RST packets are different from the IP TTLs on all the other packets. All the non-RST packets have a TTL of 64, except for packet 1 in the server trace, which has a TTL of 63. All the RST packets have a TTL of 250, except for packet 114 in the client trace and packet 107 in the server trace, which have a TTL of 64.

RST packets are not supposed to be responded to. If one system receives a RST, it should just silently tear down the TCP connection. It should not send any more packets to the other system.

I'd say that the client and the server are not sending RSTs to each other. Instead, some device in the middle is aborting the TCP session by sending RSTs in both directions. It's spoofing the server's address in RST packets going to the client, and it's spoofing the client's address in RST packets going to the server. It has to do that in order to get the client and server to accept and take action based on the RSTs. They will not tear down an established TCP connection is response to a RST packet from a third device that is not part of that connection, so the client has to believe that the RST is from the server and the server has to believe that the RST is from the client.

Look for some other device in between the client and the server, probably one whose operating system has a default TTL of 250. If there's really nothing between the client and the server except the Access Point and two switches, then it's one of those. Are you sure that there is nothing else between the client and server? Maybe some security device that is in transparent mode?

I stumbled on this old question because I was searching evidence that Meraki has a default TTL of 250. It seems to be the case...

Regarding your question:

As a follow-up question, is it normal that only the first packet has a TTL of 63 and all the others have a TTL of 64 if there is a router is the middle? I was expecting to see a TTL of 63 on all the packets.

Yes, normally you would indeed see all packets that are routed over one hop decrease the TTL, so in your packet captures, you would see a TTL of 63 for packets coming in from the other side of the Meraki router. But apparently, the Meraki works a bit differently, and it also does not seem to like the TCP seqments with sequence numbers starting with 48502, as these frames are forwarded to the server as a RST packet (look at the sequence numbers) while at the client these packets are answered with a RST.

The final RST is an actual RST of the client, after it received an ACK, after the connection was already reset.

Based on the timings in the pcap files, I assume the packet captures were made on the client (Mac) and the server (VMware VM)? And were you ever able to find the reason for why the Meraki router killed large file transfers?