Tunnel Connection Could Not Be Established

[epa80]

We have a Horizon 6.2 Environment behind F5 Load Balancing. We are also doing SSL offloading to the F5. Our setup:

• Global GTM connectvdi.site.com (all users go here, internal and external)
• Under the GTM, are 2 Internal LTMs, and 2 External LTMs, 1 pair at each of our Data Centers.

Internally we seem fine so I'll focus on our issue, which is primarily external.

When a user connects to the GTM, underneath him he reports to LTMs for external use: dc1-viewsecurity.com and dc2-viewsecurity.site.com. Under each of those, we have 2 security servers each. dc1-sec1.site.com, dc1-sec2.site.com, dc2-sec1.site.com, and dc2-sec2.site.com. All of these are in our DMZ. Each security server is paired with an external view broker that lives on our secure network. Round robin should equally distribute the load between the 2 LTMs.

As our population has started to utilize the outside access, we have seen a ton of reports of the error in the subject, tunnel connection could not be established. Initially we looked at F5, but now believe it is not the load balancer, since if I go directly to the security servers from outside, bypasing the GTM/LTM, I am seeing the issue. I believe the issue is some misconfiguration on our DC2 security server or external view brokers.

We had a similar issue on our internal brokers that was fixed by identifying 1 broker missing the locked.properties file (found in program Files\VMware\VMware View\Server\sslgateway\conf). Within the file was 1 line of text: "serverProtocol=http".

Could our problem externally be similar to the internal one that was fixed by placing the file? I can't seem to get a definite answer if the external brokers, and/or the security servers, need this same file or not. And if they do, should the text string within still be the same. This environment was setup by someone else, and oddly enough, of the 4 security servers, the file exists on 3 of the 4, but has no text in it at all. Paint me confused.

Thanks in advance.

[epa80]

According to a build document left by professional services, locked.proprties DOES need to exist even on the security servers. Within it is the single line "serverProtocol=http". Well, we did that, rebooted the sec servers, and still, we're having spotty connectivity.

Something is clearly misconfigured around our SSL offloading via the F5, going to a GTM, with 2 LTMs underneath it. Lot of moving parts and something somewhere is misconfigured. Wish we could nail down what.

[MikeTyler]

Did you get any further with this? We are seeing something similar to this in one of our PODs now. It started about the same time you posted. We are just now starting to investigate, will share what we find.

[epa80]

Once we made sure locked.properties was on all of our brokers, that resolved our issue. One broker was missing it and screwing up the entire pod.

[markbenson]

You should not have ServerProtocol=http in locked.properties. Connections to Security Server and Connection Server should be left as the default which is HTTPS on TCP port 443.

Even if your load balancer terminates SSL (TLS), it should re-encrypt traffic so that between the load balancer and the Horizon View Security servers it is HTTPS on port 443.

Also make sure that the externalURL settings you configure for each Security Server ensure that when used by the client, will get to the specific Security Server. If your load balancer misroutes the connection to a different Security Server you will get the tunnel error you describe.

Mark