View Client SSL Initialisation Error

[Shez7]

We have a View 5.1 Environment that was built with 2 Security Servers (using DNS Round Robin for external access to cloud.abc.com); paired with 2 Internal Connection Broker Server and all originally deployed with self signed certs. We recently replaced the Security Server Certifictes (with a wildcard cert - *.abc.com) and completed all the required View Changes to deploy the Certs onto the Security Server and verified Cert working working using https://cloud.abc.com. View clients all working and SSl shown as green in View client when accessing (cloud.abc.com). We also replaced the Internal Connection Server Certificates (with a Cert "cloud.abc.pri" from our Internal CA and again made the View Changes to deploy the Certs onto the Conenction Broker Servers all working nicely.

Finally to resolve the View Admin Health Reports we changed the Security Server External URL (from the Public IP address to cloud.abc.com) and also changed the Connection Broker External URL (from the Private IP Address to cloud.abc.pri) and tested that external access was working.

Now the strange bit, 24 hrs later a few users reported they could connect to the View Server (and complete the intial 2F Authentication) but when prompted for the Network Login and password received an error SSL INITIALLSATION FAILED (or words to that effect), given the only changes made
from when everything was working was changin the External URL for the Security Servers from Public IP to FQDN this was changed back and everything started working.

Researching the issue on the communities lead me to the following post  - https://communities.vmware.com/message/1549700, which is over 4 yrs old. This related to the SSL Handshake being split into 2 TCP Segments and this causing the problem and a new View Client only requestable via VMWare Support was required to fix the issue. I wondered before I start making all the changes to the config and using Wireshark to verify if this is the problem we have it anyone could advise if they have a similar issue. Problem occurrs on View Client 2.3.0 and 2.3.3 (possibly other earlier clients but these are un-tested atm

Message was edited by: Brian Atkinson o remove the ALLCAPS from the subject line

[Shez7]

Reading the following Community Post - https://communities.vmware.com/message/2193011 highlighted virtually the exact same issue that we were experiencing. Below is the reply from MarkBenson (Vmware Team) that indiciates that the DNS Round Robin is sending requests to the alternate Security Server (not the one initially contacted) and that this is why the connection fails. In which case I would need to set the Security Servers "ss1.abc.com and ss2.abc.com" to have External DNS Entries and then define these FQDN's in the View Admin Console for the External URL on each security server.

It would be good if Mark (or anyone else ) could confirm my assumptions are correct. I had assumed that the DNS Round Robin would place a single cached entry into the Workstations DNS Cache but upon checking it puts both DNS Entries in the Local Cache and hence why I think the problem occur

Re: View 5.1 - View Connection Server Authentication failed

markbenson (727 posts since 10-Oct-2007) 05-Feb-2013 03:38 (in response to paiolfi) Currently Being Moderated

No. This is not correct based on your original configuration. When you saw the failure, your round robin DNS will have sent tunnel connections to a different Connection Server and will have failed. Setting the External URL to the specific Connection Server name (resolvable on the Internet) is correct for remote access situations.

If you set the External URL and PCoIP External URL to the specific external IP addresses of your Connection Server then it will route correctly. It is only the FQDN in the URL that the View Client uses that should be used for round robin DNS (not the External URLs).

If this is all internal, then you don't need to use the tunnel anyway so you can untick "Use Tunnel ..." in which case the External URL is not used.

Mark

[markbenson · Accepted solution]

The External URL setting on the Security Server is used by the client to make the SSL tunnel connection to the Security Server once authentication is complete. If your External URL value uses round-robin DNS then there is a risk that this SSL tunnel connection will be directed by DNS to the wrong Security Server. This will give you the errors you are seeing.

Each Security Server External URL value must ensure that the SSL tunnel connection from the client goes to that specific Security Server and no other.

Hope this helps.

Mark

[Shez7]

Thanks for confirming Mark, we switched back to the IP Address in the External URL on the Security Servers until we identified and confirmed the issue. We plan to implement a proper Load Balancer which will handle Stage 1 and 2 of the External View Connections using the FQDN of thLoad Balanced Address. We also saw the same issue on Stratodesk No Touch Clients on our internal Connection Servers.