Internal Connection Server

[bjohn]

For Internal ONLY connection servers, do you need to have use secure tunnel connection to desktop or use PCoIP secure gateway options checked?

[mpryor]

No, it is not required. If these options are disabled client connections will be made directly to the desktop VMs, so make sure that it's directly routable and there are no firewalls blocking traffic between the subnets.

[bjohn]

Thank You

I have never been able to find good explanations on what both of these options do.

Do they just make the connections more secure?

We are using zero clients internally and a few Windows clients.

[mpryor]

Yes they're primarily for security (they will only let traffic through for authenticated users) and for cases where direct access is not possible, such as if the environment is firewalled off or behind a NAT. It's fairly common to only enable them for external access and leave disabled for internal clients.

[bjohn]

>> They will only let traffic through for authenticated users.

Could you please explain this sentence.

That said, what are the disadvantages of leaving these options enabled?

Thanks for your time.

[glennvelsol]

I would also like to know the advantages/disadvantages of leaving this checked or unchecked for internal usage.

[chriskoch99]

One disadvantage of unchecking the HTTP(S) Secure Tunnel option is that it also requires you to disable the Blast Secure Gateway option.  This means you can't use HTML5/BLAST connections at all.   So you have to choose... offer BLAST to those who don't have a working thick client, or subject your thick clients to unexpected disconnects every time you reboot a connection server for maintenance or patch.  I'd like to have the option to use BLAST and not secure tunnel with the thick clients.

[glennvelsol]

Yeah I noticed that BLAST gets unchecked as well and that is always a nice fall back to use so i'm leaving it on.

[erickbm]

I was able to use BLAST while unchecking the BLAST tunnel option. The issue we ran into was the certificate warning that would happen to all users when they tried BLAST through an internal connection server.

[bjohn]

Wish there was a document explaining the differences and which option to use in different scenarios.

[chriskoch99]

Yes, I was mistaken.  BLAST connections are possible when the HTTP(S) Secure Tunnel / Secure BLAST Gateway options are unchecked, however we too get a certificate warning that users must click through first.  This is because the browser URL becomes https://<IP address of the assigned VDI>/etc/etc rather than https://<FQDN of our View DNS name>/etc/etc.  Since the VDIs don't all have certs permitting SSL connections on the IP address, the browser presents a warning.

Frustrating stuff.  For the large enterprise, cert warnings result in too many helpdesk calls.  Could be eliminated by enabling Secure BLAST gateway, but in this case, huge swaths of users (View client AND BLAST users) get disconnected when connection servers are bounced on patch night.  Can't win either way if we want to use BLAST.

c'mon VMware -- let us enable Secure BLAST Gateway without requiring HTTP(S) Secure Tunnel!

I suppose we could set up dedicated BLAST connection servers, but now we're talking about three pairs of connection servers in the same Pod.  Seems goofy...

[markbenson]

You're quite right chriskoch99. You should, of course, be able to enable Blast Gateway without requiring the HTTPS secure tunnel. I remember there was a bug introduced for a while that wrongly linked these two checkboxes in Horizon (View) Administrator. I think it was fixed in 6.1.1 and newer.

What version are you running on your Connection Server?

There is a workaround by looking at the Connection Server settings in AD LDS (formerly ADAM) LDAP directory (for the Connection Server entry) and manually setting Blast and Tunnel Enabled settings (i.e. turn off tunnel). If you can, it is better to upgrade to 6.1.1 or newer.

Mark

[joshopper]

You can also install a wildcard cert on your desktops to avoid this if you prefer. You can see the resolution in KB2088354