Unable to connect to the server (Socket Error 10051)
The problem
I have set up a Windows Server 2022 with Citrix VDA 2206. Everything is pretty normal, I checked the registration status in Citrix Studio.
Seems good. Now a quick connection test.
After a few seconds I get this:
After close this dialog error box, I get the next error message:
Client error 0
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.
Socket Error 10051
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.
The network trace - VDA
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:
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
:
That looks also good.
The network trace - Client
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.
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.
Citrix Workspace App Logfile
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.
No evidence
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.
Finally a hint
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:
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.
The home straight
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:
After rebooting the VDA, the AD attribute dNSHostName
correct itself and the connection finally works.
Final words
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.