View HTML Blast, There is no available gateway for the display protocol

[Krede]

I'm playing around with the new HTML client for Horizon View - but when i connect externally (from Internet) i get this error when I click on my desktop:

Unable to connect to desktop: There is no available gateway for the display protocol. Try again, or contact your administrator if this problem persists.

From "inside" (through view connection server) it works fine - What could be wrong with my Security server (DMZ)?

I have opened port TCP 8443 to Security server (NAT from WAN) - and at this moment all traffic from Security server to connection server and desktops (LAN) is allowed.

[JustHall]

I'm still getting the same message for external HTML Access: "Unable to connect to desktop: There is no available gateway for the display protocol."

The 3rd-party firewall rules are in place per documentation from VMware, which also matches what people have mentioned on the forums (including iefke's Blast diagram). I have used a simple telnet test to confirm the following are all open and accepting connections:

1. TCP/8443 from external/WAN to the Security Servers

2. TCP/8443 from the Security Servers to their paired Connection Servers

3. TCP/22443 from the Security Servers to the virtual desktops

(For the record, the Windows firewall service is running but the profiles are set to Off. Based on nikonau's results, it sounds like this is acceptable.)

I can login to the web interface, but when I select the pool I get the error described above. Watching the network traffic (or lack thereof, actually), I don't see any attempted 8443 traffic coming out of the Security Server during this test. I would expect to see 8443 from the SS to the CS, and then 22443 from the SS to the desktops. The only thing I see is a short back-and-forth between the SS and the respective CS on port 8009.

Any ideas?

Thanks.

[jansson81]

Please try with the firewall ON. I think view security and connection server uses some ipsec functions in the firewall.

[JustHall]

jansson81,

I will try that, but I was under the impression that was only if you had "Enable IPSec for Security Server pairing" enabled in the Global Settings section of Horizon View Administrator. That setting is disabled in our environment. But I'll give it a go.

Thanks.

[JustHall]

I changed the firewall profile to On and made sure the rules were in place to allow the documented traffic. No change in behavior.

Any other ideas?

[jansson81]

Have you checked the view configuration for the security server? Blast Sercure Gateway should be your firewalls external (outside) IP or FQDN, not an internal adress. If you use FQDN, make sure your clients is able to resolve this adress.

[JustHall]

I checked, and the Blast Secure Gateway is configured to be the external IP of the Security Server. It's basically identical to the HTTP(S) Secure Tunnel option, except port 8443 instead of 443. It is IP, also (no FQDNs in the Security Server configuration window).

[jansson81]

Just to make sure, did you check the "Security Server configuration" and not the "Connection Server settings"? Can you please provide screenshots of your configuration? View Connection Server and Security Server config please.

[admin]

Hi JustHall,

You mentioned a 3rd-party firewall.  Does this firewall allow TCP traffic over the loopback interface on the Security Server?  In particular, access to TCP 127.0.0.1:8123 needs to be allowed on your security server.

There are other things to try as well, but I thought this would be a good first step, so please let me know if it helped or not.  Thanks!

- Chris

[JustHall]

jansson81,

Correct, I was looking at the Security Server configuration window. Here are some screenshots (apologies for the blurred out info, I am in a sensitive environment).

Chris,

Our 3rd-party firewall is hardware based and defines/regulates our DMZ. It handles incoming traffic from the Internet, as well as traffic from the DMZ to the internal network. Nothing in our configuration should restrict loopback traffic on a server. I had our firewall administrator verify this and watch the logs to make sure nothing was being blocked.

Thanks.

[JustHall]

Update [solved]:

It turns out our issue is the same as what Jo reported regarding RADIUS. Upon disabling "Use the same user name and password for RADIUS and Windows authentication" under Advanced Authentication for each external paired Connection Server, things began working as expected. Hopefully this may help someone else using two-factor authentication who gets caught in the same scenario where everything is configured correctly and still not working.

(For the record, VMware is aware of the issue and is going to get back to us on a resolution.)

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=205082...