VMware Horizon Community

VMWare Horizon Client - 2111 on MacOS 'Loading Desktop' Error


We've recently upgraded our MacOSX clients to Horizon Client 2111, however we can no longer launch RDS desktops when running OSX 12.1

Interestingly, downgrading to 2106.1 exhibits the same behaviour.

There is nothing on the server side logs that would indicate there is a problem and there is minimal informaiton in the client side logs on OSX, again nothing that would indicate a problem.

It's worth noting that no error occurs on the client, it successfully authenticates to the server, we select the RDS desktop, see a 'Loading Desktop' modal with a spinning wheel for a few seconds and then the client just returns back to the main screen to select a desktop.

Has anyone else had this problem as we're struggling to understand why this seems to be so broken?

Access via Windows and HTML5 is absolutely fine by the way.



0 Kudos
2 Replies

Can anyone shed light on the below from VMware-MKS logs?We have the same issue


2022-01-20T22:14:09.434Z In(05) main [BlastSocketClient] BlastSocketClientConnect: Connect using TCP Remote Port: 443
2022-01-20T22:14:09.434Z In(05) main SOCKET connect to wss://
2022-01-20T22:14:09.434Z In(05) main SOCKET creating new IPv4 socket, connecting to (
2022-01-20T22:14:09.434Z In(05) main [BlastSocketClient] BlastSocket_Connect: Connect issued for Primary, clientContext->primarySocket: 7F7D751073A0, error: 0.
2022-01-20T22:14:09.434Z In(05) main VIEWCLIENT: BlastSocket_Connect() done, vvcSessionId: -2.
2022-01-20T22:14:09.434Z In(05) main Begin gathering input Locale Identifiers for the user.
2022-01-20T22:14:09.444Z In(05) main TSF_GetKBDLayoutList: Get input source ID com.apple.keylayout.British
2022-01-20T22:14:09.444Z In(05)+ main .
2022-01-20T22:14:09.445Z In(05) main Number of installed Input Locale Identifiers for the user 1
2022-01-20T22:14:09.445Z In(05) main 1. Language 0x2809 Layout unique id 0x1
2022-01-20T22:14:09.445Z In(05) main Finished gathering input Locale Identifiers for the user.
2022-01-20T22:14:09.449Z In(05) main KHBKL: Unable to parse keystring at: ''
2022-01-20T22:14:09.449Z In(05) main KHBKL: Unable to parse keystring at: ''
2022-01-20T22:14:09.450Z Wa(03) main VDPMksVchan_GHIRequestReceived: unknown command name: ghi.dnd.shakehand.
2022-01-20T22:14:09.520Z In(05) blastSocket SSL: EOF in violation of protocol
2022-01-20T22:14:09.521Z Wa(03) blastSocket SOCKET 4 (27) Could not negotiate SSL
2022-01-20T22:14:09.521Z Wa(03)+ blastSocket
2022-01-20T22:14:09.521Z Wa(03) blastSocket SOCKET 4 (27) Cannot verify target host.
2022-01-20T22:14:09.521Z In(05) blastSocket [BlastSocketClient] BlastSocketClientHandleSocketError: ClientContext:7F7D75847200, vvcSessionId:-2: received socket error on asock: 7F7D751073A0, asockId: 4, error: 13
2022-01-20T22:14:09.521Z In(05) blastSocket [BlastSocketClient] BlastSocketClientIsPeerRejected: WebSocketError: 0, isPeerRejected: No
2022-01-20T22:14:09.521Z In(05) blastSocket [BlastSocketClient] BlastSocketClientHandleSocketError: Error before primarySocket connect, so closing BlastSocketClientContext: 7F7D75847200
2022-01-20T22:14:09.521Z In(05) blastSocket [BlastSocketClient] BlastSocketClientAsockClose: BlastSocketClientHandleSocketError: Closing primary socket: 7F7D751073A0 VVC owner: 0, BlastSocketClientContext: 7F7D75847200
2022-01-20T22:14:09.521Z In(05) blastSocket [BlastSocketClient] BlastSocketClientClose: Closing BlastSocketClientContext: 7F7D75847200, reason: 4
2022-01-20T22:14:09.521Z In(05) blastSocket [BlastSocketClient] BlastSocketClientClose: Closed BlastSocketClientContext: 7F7D75847200, reason: 4

0 Kudos

For anyone else experiencing this issue, the culprit is the VMware Horizon client on MacOS not using FQDNs when connecting to WSS sockets.

We use Load Balancers and Reverse Proxy Servers that are pre-routing based on the SNI for inbound SSL/TLS connections - e.g. vdi.corp.com. This work's absolutely fine to authenticate in the MacOS client to the Horizon Server but when you select a desktop to connect to, it would seem that the WSS connection that is initiated by the Horizon MacOS Client tries to connect via the IP Address that the FQDN resolves to. As such, the Load Balancers / Reverse Proxy Servers don't know what to do with the request and drop the traffic.

In order to work around this at the moment, we've had to stand up a separate UAG that listens on a dedicated external port (e.g. 8443), without going via any Load Balancers and Reverse Proxy Servers in order for the Horizon MacOS client to successfully connect when it tries to do main SOCKET connect to wss:// (see vmware-mks logs and the extract above).

This would seem to be a bug in the Horizon Client for MacOS only as the Windows Client seems to utilise the FQDN for WSS connections as they're are no issues with connectivity through Load Balancers or Reverse Proxies. 

Would someone from VMware's Horizon Client team be able to pick this up and log it as a bug to be fixed in the next client release? 


0 Kudos