Tcp – Why I see RST being dropped

The timestamps on your satellite pcap entries do imply tcp acknowledgement spoofing. Most devices that perform acknowledgement spoofing can be configured to bypass acceleration based on some combination of source/ destination IP address, source/ destination port; standard ACL concepts. This could be a feature that is configurable in the satellite modems (or nearby device) at your hub and spoke locaitons.

Wide area optimization or acceleration solutions are also common in such network architectures. Again, these solutions should provide a method to bypass your traffic that's having problems. Devices such as Riverbed Steelhead, Cisco WAAS, Bluecoat, and Citrix Cloudbridge/ Wanscaler are examples of technologies that might impact your application. A discussion with your provider (or network guy) should reveal if such technologies are in use on your network; if so, request bypassing your affected traffic in these devices to see if behavior changes. Best of luck.

A TCP connection is normally terminating using a special procedure where each side independently closes its end of the link. Connections are only a pair of two-way handshakes, not the normal 3-way handshake some people expect. Normal connection shutdown states are different at each end. It normally begins with one of the application processes signaling to its TCP layer that the session is no longer needed. That device sends a FIN message to tell the other device that it wants to end the connection, which is acknowledged. When the responding device is ready, it too sends a FIN that is acknowledged; after waiting a period of time for the ACK to be received, I believe its 4 mins, the session is closed.

The TCP protocol detects and responds to various problems that can occur during an established connection. One of the most common is the half-open connection. This occurs when one device closes the connection without the other one knowing about it, due to some problem with the connection, such as a bad network connection continuously flapping, which sounds like what you're experiencing. This means one device is in the ESTABLISHED state while the other may be in the CLOSED state, or some other transient state. This can cause states of the two devices to become unsynchronized.

TCP handles these half-open connections with the RST reset function, which is is generated whenever something happens that is “unexpected” by the TCP software.

Your client issued the RST, your http server ACK'd the RST, which should have closed the connection. However, because of the network flapping and the connection being half-open and unsynchronized, this caused some packet-loss or received out of order. This is why you also see the DUP ACK in your post.