Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I seems both the telecom operator as well as the Palo Alto administrator are right, the problem does not lie in those domains. The problem is on the ThinClient. Before the RST is sent by the Citrix Server, it tries to retransmit lost data to the ThinClient. The segment with seq=3873396656 is sent, but as soon as the client receives that segment, it ack=3873396656, which means it wants to receive from sequence number 3873396656 onwards (but it just did receive that segment). This repeats itself until the Citrix server has to give up with a RST.

The underlying situation is that the receive buffer of the client is fully filled, but there are gaps (that's why you see sack blocks being sent back to the server). Maybe this situation is a trigger for this issue. Do these ThinClients run the lastest firmware? If not, an upgrade might be a good try to solve this issue. Otherwise, a support case with the vendor would be the next step.

Also strange is the fact that segments of 536 bytes are sent instead of the advertised MSS of 1460 (both ways). This might indicate a caching of an earlier issue between these hosts with segments of size 1460. Is there a VPN involved?