Horizon HTML Landing Page - All White

[epa80]

We recently upgraded to Horizon 7.8 and are trying to implement HTML access for the first time. We're an F5 shop for load balancing, and seem to be running into a problem when going through the load balanced address. In a nutshell:

We have two 3.6 UAGs in our DMZ. They are under a load balancer. The UAGs are each pointed at a secure network load ba;ancer address that has our connection servers behind it. In terms of brokering with the Horizon client, we have no issues. Works fine. However, when we point our browsers (tried Chrome and Firefox) at the UAG load balancer, we get to this page fine:

However, as soon as we click "VMware Horizon HTML Access", we progress to a page that is all white. That's it. No error, nothing, just a blank white web page. If I point my browser directly at each UAG, I get the same behavior. If I bypass the UAG, point directly at the brokers, I get expected behavior: I can login and get a VM.

The UAG radio button for allowing HTML access is indeed set. We also modified the Locked.Properties file a bunch of different ways using these 2 KBs, but, without luck. We're a bit stuck for now. Hoping someone has seen something similar.

Allow HTML Access Through a Load Balancer

Allow HTML Access Through a Gateway

[Shreyskar]

Hi g0dMAn

Please create locked.properties file on all connection servers as per VMware Knowledge Base  and restart CS services once. Test now if HTML connections through UAG works or not.

[g0dMAn]

Shreyskar​, see my previous post... I already indicated that locked.properties doesn't help.  The setup right now is just one CS and one UAG.

[Shreyskar]

Hi g0dMAn

I read in above posts if you bypass UAG and directly hit CS, HTML loads fine.

If checkorigin file has already been tried, the only other thing I suspect could be causing this issue is incorrect blast external URL setting on UAG. If the issue happens only when you connect through UAG, make sure blast tunnel is enabled on UAG only and is disabled on CS (View config > CS > Edit > Do not use Blast tunnel).

[g0dMAn]

Shreyskar​

Trust me, I've tried all of the common items. I have no idea why it doesn't work.

Here is my original thread:

Unified Access Gateway HTML - Browser is blank

Here is what I've done...

"domain" is the actual domain name we are using. We have root CA certs across the board.

locked.properties:

checkOriginal=false

portalHost=vdi.domain.com

^I originally only had the first line, tried only the second line, then left both in there.  I did a CS restart each time (originally did service restart, but then went as far as rebooting the entire CS).

Connection Servers Settings:

HTTPS Secure Tunnel disabled

PCoIP Secure Gateway unchecked

Blast Secure Gateway - Do not use Blast secure gateway

UAG Settings:

PCoIP External URL: external-ip-address:4172

Blaster External URL: https://vdi.domain.com

Tunnel External URL: https://vdi.domain.com

^I even tried https://vdi.domain.com:8443 for Blaster external (even though that's the default port).

Here are the ports available through firewall:

tcp 80

tcp 443

tcp/udp 8443

tcp udp 4172

All protocols work via Horizon client: rdp, pcoip and blast

UAG has two interfaces, external for DMZ, and internal/mgmt.  Gateway lives on external interface.

UAG internal is on the same subnet/vlan as the connection server and the VMs, so no additional routing is necessary.

So the only thing that does not work is connecting to https://vdi.domain.com via a browser.  The entire website shows up white/blank... absolutely no messages at all.  If I go to https://vdi.domain.com:8443 it gives this message: "missing route token in request" -- I assume this is normal.

I hope this is all the info needed.  I'm at a loss.

[Aaron11211]

I suggest opening UDP port 443, and checking your locked.properties file.

[g0dMAn]

UDP 443 doesn't help... didn't think it would, but I tried it.

I totally think it's related to locked.properties, but it doesn't seem to change anything.

C:\Program Files\VMware\VMware View\Server\sslgateway\conf\locked.properties

checkOrigin=false

portalHost=vdi.domain.com

This is how it's currently set up.  I've also tried each of the two lines above separately, with conn server restarts each time I make a change.  I don't assume I need to reboot the UAG when I make these changes (would rather not if not needed).

[sjesse]

Whats vdi.domain.com. is that the uag address or the loadbalancer address? If its the loadbalancer address it should be under balancedHost  portalhost should be the uag name.

[g0dMAn]

It's to resolve external IP to the UAG, so yes it's the UAG name.  We don't have a load balancer.

UAG is sitting in the DMZ without NAT.  UAG external interface has external IP address, but behind a Sonicwall firewall and has access rules for the ports mentioned in the previous post.

I really don't think I missed anything, but hoping I did!! This is why it's been driving me nuts.  Every suggestion I've had, I've already tried... thus far.

[Shreyskar]

Hi g0dMAn

Can you generate HTML logging and share?

Below steps can be follow to change and generate the HTML Access logs.

HTML Access log-level is not the same as Broker log-level.

• HTML Access log-level config file is in the Broker
• HTML Access log should be collected by browser console at client Machine.
• normally used log-level for SR
• debug log-level can help to find cause of issues most of time.
• trace log-level contains most of information, and is most helpful for SR.

1. 1. Change Log level for HTML Access

The default log-level is LEVEL_INFO for GA builds, and logs in debug level will be helpful for debugging issues.

Steps to change HTML Access log level

• Change  config file by editing log-level number in the config file:
  Path on broker: vmware\vmware view\server\broker\webapps\portal\WEB-INF\classes\protal-version.properties
  LEVEL_TRACE: 0,
  LEVEL_DEBUG: 1,
  LEVEL_INFO: 2,
  LEVEL_WARNING: 3,
  LEVEL_ERROR: 4,
• Reboot VM or restart web service.

1. 2. How to collect
   • open console for the testing browser
     https://www.google.com/search?q=how+do+i+open+the+browser+console&oq=how+do+i+open+the+browser+conso...
   • copy text into a text editor and save logs into a file.
1. 3. Confirm log level has been changed
   • we can check if there is any keyword "[debug]" in the console log, if there is any, the log level is trace or debug, otherwise, it should be info.
   • if the console log level is not changed after Step 1), please close and re-open browser.

1. 4. Collect Log before and after page reloading
   • For Chrome, select "preserve log" checkbox in the browser console panel, and reproduce the bug.

[g0dMAn]

I changed the log level, and opened up the browser console via Firefox, but can't tell on how to use the browser console.

I did restart the service called "VMware Horizon View Web Component"

[Rolleps]

Hey,

we have exactly the same problem in our installation.

What we were able to see is that the request for downloading content is taking very long. After 6 mins it finishes and is doing the next requests. After about 24 mins of content download requests the side is loading successful.

Our setup is a UAG cluster in the DMZ -> haproxy cluster with keepalived -> connections servers.

Any update on this case?

[anthonyu]

we had the same issue and resolved it, what i found if the Load balancing is doing ssl decrypt re-encrypt for the connection servers was the issue.

we first test by connecting the UAGs directly to a single connection server and everything worked as expected. we then decided to create a new VIP that is passthrough and the existing VIP with the public IP will be used to present the certificate to internal users and then the UAG connects and trusts the certificates on all of the connection servers, by either sharing the certificate across all the connection servers or adding each thumprint in the horizon config for the UAG

[ENCOMPASS]

Question Did your use the IPAM Template when you setup the Unified Access Gateway?

Also you mention that you are using 2 Interface. I see alot to folks say lock.properties.

For Giggles have you just tried 1 NIC Interface and see if that work first. 

Let getting one Interface going first.

If you still want the second interface working for the Management add the second Interface for Management from there is going to be a bit tricky

use wireshark and trace out where the packet is dropping.

So if the single interface is working use the wireshark and capture all the routes and traffic.

then when you add the 2nd Interface use the WireShark to capture all the traffic from there you should be able to add the route or it will tell you with Interface port that it is using with the MAC Address if it points back to the F5 make sure that the F5 Interface is set to allow traffic. I hope this helps

Also Make Sure that the TCP/UDP is Bidirectional Traffic not just 1 way only that will be on your Firewall.