While working at a Workspace ONE project we were implementing a Unified Access Gateways (UAG) for untrusted connections to reach the workspace. Untrusted connections could be Wifi or the big bad interweb. They have two routes, all users reaching the Workspace aka Identity Manager (vIDM Proxy and vIDM) for authentication and choosing the entitlements and the second route after selecting a desktop route and using a tunneled UAG to connect to the Horizon desktop resources. With the latter the user has the option to select the Horizon Client or the browser, both are allowed and should reach the desktop. Do we hear a should? Yes, should. The Horizon client is connecting to the desktop, so an okay here. When using the HTML Web client we were greeted with a 404 error. Hey, wait?!?

Next steps get out the violin and start investigating.

Sherlock investigate UAG

HTML 404

Where did that HTML error get from and what were we trying? A 404 error is a server-side error message. We are reaching a location in the chain and from there on there isn’t a way to get to the next thingie. Yes exactly, what is that next thingie. When we checked the page that was having the 404 we checked if the URL can be reached. If we just paste the URL in another tab we get another 404. When we checked the connection was okay from a trusted zone (or internal connection), the HTML Web desktop was shown.

Noticing a behavior

The difference here is internally you get the view-client URL from the vIDM portal and you are directed to the internal load balancers to the Horizon server, external clients will get the UAG load balancing pair in front (as the FQDN is DNS split internally to another address than the external split).

With posting the URL from an internal connection we noticed a behavior that the URL was ‘rewritten’. The first URL part after the FQDN, /view-client/1.0/ was rewritten to /portal/webclient/. And via the internal connection, this was done on one of the connection servers. The one you reached after the ESG load balancer decided on which you could use. Anyhow, this behavior is not witnessed while passing through the UAGs.

Steps

Could something be blocking the way to the next whiskey… ermm desktop?  When we manually replace the /view-client/1.0/ part with the /portal/webclient/ lo and behold the desktop is shown. It is not a blocker on the networking or Horizon or the desktop. Must be something on the UAG as the initial connection works, the user gets its entitlements, the desktop can be selected and can be connected with the Horizon Client (Blast extreme). This is a UAG setting, and specifically something to do with Horizon tunnel.

UAG Administration

And get access to the UAG, you can point your browser to https://uagfqdnorip:9443/admin/index.html, and log in as admin. Select Configure Manually.

In general settings, show the Edge Service settings and Choose the Horizon Settings (the wheel next to it) as there we need to go.

UAG Edge Services

Click on more. The URL is https://internallocation/view-client/ thus I’m looking at the proxy pattern. The proxy pattern is used for the HTML web client to the Horizon connection server, it is set to forward slash (/). According to the information, this should normally by a normal value. Well, it isn’t, at least not with the versions used here.

UAG Proxy Pattern

When we change the forward to include (with a or |) view-client now the connection works:

(/|/view-client(.*))

Versions witnessed

Witnessed on the following versions:
– UAG 3.0
– vIDM 2.9.2.0 (Build 6095217)
– Horizon 7.1

– Enjoy the HTML Web client and UAG

Share this: