Ask Your Question

Citrix client disconnection from MPLS link, [TCP RST, ACK]

asked 2024-01-25 06:49:34 +0000

Jerome.launo gravatar image

Good morning,

We are experiencing disconnection problems with our thin clients randomly and only on certain external structures.

Of the 35 external structures connected to our central site (MPLS link), only 5 encountered Citrix disconnection problems on thin clients. This happens even when the 2MB link is not saturated.

Our telecom operator assures us that there are no problems with the MPLS links and our Palo Alto firewall manager assures us that the firewall is properly configured.

I'm desperate to find the source of this problem.

In the Archi.jpeg file you can see an extract of the architecture, I launched frame captures on each side of the MPLS link (CLIENT_anon & SRV_anon)

Architecture :

Client-side capture :

Server-side capture :

Thanks a lot for your help

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2024-01-25 22:22:46 +0000

SYN-bit gravatar image

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?

edit flag offensive delete link more


With VPN traffic MSS values are lowered in my experience. If a buffer is filled the window size should relect that. But it never drops very low which is ackward.

And as fas as small packets are concerned.. That's business as usual with Citrix. (Nasty little Trixies)

hugo.vanderkooij gravatar imagehugo.vanderkooij ( 2024-01-26 14:25:51 +0000 )edit

I forwarded the Wireshark traces to the thin client manufacturer ( I have also just replaced two thin clients with more efficient models, I am waiting for feedback from users. Thank you so much

Jerome.launo gravatar imageJerome.launo ( 2024-01-26 14:37:11 +0000 )edit

@hugo.vanderkooij Good to know about Citrix sending small segments, did not know that...

As for the window size not dropping, that's because there is a segment missing at the start of the buffer, so it needs to keep the window size high, even if the buffer is filled (except for a few gaps).

@Jerome.launo Great tht you created a case, let's see how they respond.

SYN-bit gravatar imageSYN-bit ( 2024-01-26 21:33:53 +0000 )edit

Hello, I just received feedback from the thin client manufacturer. He doesn't see a problem on his devices, but notices that the traffic captured is not synchronous. The server sends many packets in a row without receiving a response from the client (packet 2024 to 2113 in the server file) while the client sends many ACKs but are not immediately retransmitted to the server, as if MPLS routers store the data before sending it.

He advises me to open a ticket with my telecom operator so that I can send them the capture files so that they can analyze them as well.

Jerome.launo gravatar imageJerome.launo ( 2024-01-31 14:09:48 +0000 )edit

I'm sorry you got this feedback, as it is not a proper analysis and they are sending you in the wrong direction.

I'm not here to promote my business (analysing and solving issues like this, usually by convincing a vendor it IS their problem), but if you do need help in putting the problem where it belongs, you can of course contact me (email address is in my profile).

SYN-bit gravatar imageSYN-bit ( 2024-02-01 08:54:02 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2024-01-25 06:49:34 +0000

Seen: 277 times

Last updated: Jan 25