parico
Contributor
Contributor

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://1.1.1.1:8443 (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? 

Thanks! 

Reply
0 Kudos