Unable to connect to the server (Socket Error 10051)

I have set up a Windows Server 2022 with Citrix VDA 2206. Everything is pretty normal, I checked the registration status in Citrix Studio.

registration status

Seems good. Now a quick connection test.
After a few seconds I get this:

first error message

After close this dialog error box, I get the next error message:

second error message

All we have are two error message boxes, let’s check the second error message first. The error message is Unknown client error 0.. After we use google, we find CTX233143. The CTX article suggests to create inbound firewall rules. Of course, I did that, but a double check is never wrong. I checked it, but it was fine.

Maybe some issue with the firewall, even if I did the exceptions regarding the port 1494 and 2598 for the protocols TCP and UDP, something could have gone wrong. It’s a good idea to log the drop packets. I checked the log file %windir%\system32\logfiles\firewall\pfirewall.log but no indications of dropped packets.

There are other CTX articles as well regarding client error 0. To sum up what the error message indicates: “something went wrong.”. Usually, this error message doesn’t help us at all.

I googled the socket error message and found the CTX229748. The CTX article just describes that the Citrix Receiver improves the error message handling and also describes some socket errors. But the article doesn’t really bring us anywhere either.

Always a good idea is to check the event log. I checked the client event log and the VDA event log - no error messages.

We can be pretty sure, that it has something to do with the network.

Let’s just look directly into the network. We do a network trace on the client and VDA. Now, let’s check the VDA Wireshark trace:

VDA Wireshark trace

No display error. The network trace shows no activity. To be 100% sure, I also filter on the HDX Ports (1494, 2598) - no results. Then I thought, maybe that’s because the VDA doesn’t open the ports. So let’s check that.

We check that on the VDA with netstat -anb:

netstat -anb

That looks also good.

I was confused, but then there has to be something in the client network trace. I opened the client network trace with Wireshark and filtered it to the VDA IP.

Client Wireshark trace

What? Nothing? The network trace itself was fine, it contains several other packets. But nothing that was of interest to us.

In my mind, when the desktop viewer (“Citrix Workspace App Window”) opens and tries to connect I thought several things are for sure (internal connection):

  • The registration status in Citrix studio is fine.
  • The VDA is up and running and no network connectivity issues between VDA and Delivery Controller.
  • The client tries to connect to the VDA with the HDX protocol. No other ports or network connectivity is necessary.

I checked the Storefront and Delivery Controller event logs but everything was fine. I reinstalled the Workspace App on the client. Issue remains.
My next step was to enable the Citrix Workspace App Logging. CTX286820 explains how to enable the workspace app logging. Before version 2012, we have to enable the logging through the registry, as explained in CTX132883.

We start the logging via GUI and reproduce the issue (actually good news, that we can reproduce the issue - always easier to troubleshoot).

DiagnosticTool.log seems only contain generic information and nothing about the actual connection. We can open the Cdf/RcvrLogs.etl with CDFControl. We can read several messages, but most of them are just ScreenResize, GenericWorkQueue and some messages translates to ENCRYPTED. There are also some .etl files in the CTXReceiverLogs\2\ directory but to cut a long story short, no interesting information.

I was really a bit surprised and clueless at this point. Nothing has given me any clues as to why this connection is not working - everything looks fine. After googling around regarding the socket error 10051 I have found out that the socket error comes from the Windows Socket Error Codes. The error code 10051 means:

Network is unreachable.
A socket operation was attempted to an unreachable network. This usually means the local software knows no route to reach the remote host.

Wait for a second, now it makes sense that we don’t see anything in the network traces. When the client didn’t find a route to the VDA, we won’t see any HDX network traffic.

How does the client know which VDA to connect to? Right, via the .ica file. Here is a part of it:

[ApplicationServers]
Published Desktop $S1-2=

[Published Desktop $S1-2]
Address=ctxvda2.home.test:1494

The right value should be ctxvda2.abc.home.test and not ctxvda2.home.test. The DNS entry is correct. I remembered that when you create the AD account via PVS, the attribute dNSHostName is sometimes wrong. That can lead to odd behavior (actually not to this one, but anyway). I checked that:

dNSHostName attribute

Okay, let’s just change it in the GUI to the right value. Now reboot the VDA. Tried it again, same error message. I checked the dNSHostName again and it’s ctxvda2.home.test again.

For me, it was pretty clear that the VDA itself changes the attribute. But I’ve also been wrong more than once in the process of this adventure. I logged on to the VDA and checked the hostname.

I checked the local hostname via System Properties (sysdm.cpl) > Change > More and the value was set to home.test so I changed it to the correct value:

local host name setting

After rebooting the VDA, the AD attribute dNSHostName correct itself and the connection finally works.

Although the actual solution was very simple, the road to it was not easy. We can be very happy that Citrix provides the Windows Socket Errors, without that it would be even harder. In any case, I also take away that a look at the .ica file doesn’t hurt and can give good hints.

Happy troubleshooting.