Horizon 7.1 and Access Gateway 2.9 - **almost** there but stuck

[sweater]

We currently have two Unified Access Gateway appliances set up in front of two 7.1 connection servers.

It's super simple:

External IP -> load balancer -> gateways -> internal load balancer -> connection servers

We can hit the external site with the Horizon client and prompted for credentials.

On entering credentials we get through to see desktops available to us.

On double-click of that desktop, there's a brief connection attempt and then it kicks you back to the client. No error, no "this desktop isn't available" or anything.

I have a feeling we're close but not sure where to start looking for what's failing. Anyone else seen this as well?

- mike

[VaseemMohammed]

I think that is because the load balancer is forwarding the traffic through other gateway than the one that was responsible to handle the authentication traffic.

These secondary Horizon protocols must be routed to the same Access Point appliance to which the primary Horizon protocol was routed. Unified Access Gateway can then authorize the secondary protocols based on the authenticated user session. An important security capability of Unified Access Gateway is that Unified Access Gateway only forwards traffic into the corporate data center if the traffic is on behalf of an authenticated user. If the secondary protocol is routed incorrectly to a different Unified Access Gateway appliance than the primary protocol appliance, users are not authorized and are dropped in the DMZ. The connection fails. Incorrectly routing the secondary protocols is a common problem, if the load balancer is not configured correctly.

Check the guide and see if you can find some info, I haven't completed it myself yet "Deploying and Configuring VMware Unified Access Gateway"

[markbenson]

sweater - It can be caused by a number of things. It sounds like the secondary protocol(s) are not configured correctly. When it fails, is this for Blast or PCoIP or both?

See if the results are different for each protocol (Blast vs PCoIP). If PCoIP works but Blast fails, check that Blast Secure Gateway is not enabled on Connection Server and check that our load balancer/firewall permits WebSockets on either 8443 or 443 (depending on your configuration).

Make sure the blastExternalUrl and pcoipExternalUrl settings are correct in UAG. Those settings are used by Horizon clients (on the Internet) to connect to the same UAG appliance. Hostnames/IP addresses in those URLs must be usable by the client. Check your firewall rules, turn one of the appliances off to eliminate potential affinity misconfiguration.

Most problems of this nature are not related to UAG but just a misconfiguration in the environment. If none of this solves it for you, provide more details about your configuration and we'll help to get this fixed.

[sweater]

Ha! The man himself shows up - I love getting info directly from the source.

Before I saw this reply this morning I started messing with how the connection servers were set up. This is the part that got me on setup (from Carl Stalhood's writeup)

"In your Horizon Connection Servers, there is no need to enable any of the Gateways."

I guess I'm confused on that specific point - I got this working by clicking on things until they worked.

I'm like almost *almost* there now, still dealing with a RADIUS thing but this got me really far along in using these appliances instead of Windows-based security servers.

- mike

[markbenson]

What did you do to make it work? We want to help others!

Did you untick the Blast Gateway option on Connection Server?

What's the RADIUS thing? Tell us more and we can fix that too.

Mark

[sweater]

When I deployed these, I config'd them via the GUI - not the PS script.

We added these to a functional 7.1 environment that originally had Windows security servers.

On the servers that these appliances forward to, we still had "Use Secure Tunnel connection to machine" and "Use Blast Secure Gateway for Blast connections to this machine" still checked.

Once we deselected those, communication started working.

As for RADIUS, our ultimate goal is to have the UAG's handling RADIUS auth. When configuring these through the GUI, we've set up the RADIUS server info and the service goes green when enabled. Connecting to the external VIP (and hitting those UAG's) we do not get prompted for a 2fa token. But when we set RADIUS on the Windows connection servers we get prompted for a 2fa token. Basically, whether or not RADIUS is set up on the UAG's, only setting up RADIUS on the backend, internal servers will kick off a token challenge.

Right now I've destroyed the two GUI-deployed UAGs and am working through the 2.9 v3 PS script using the RADIUS template as a starting point. So far, when specifying the following in the file, I don't even see RADIUS as being set up once I can get to the GUI of the gateway. We have two RADIUS servers in different subnets for redundancy.

[Horizon]

<snip some stuff up here>

authMethods=radius-auth && sp-auth

matchWindowsUserName=true

[RADIUSAuth]

hostName=xx.xx.xx.46

authType=MSCHAPv2

authPort=1812

radiusDisplayHint=XXXpassword

hostName_2=xx.xx.xx.17
authPort_2=1812

Once I get into the GUI of the appliance, I don't see any of this info there.

[sweater]

More info after several hours of trying to get these two appliances deployed using PowerShell:

Even though I'm specifying "authMethods=radius-auth" RADIUS is not turned on when I check the appliance. This is concerning - it's like it's just skipping past that config that I'm specifying in the .ini file.

I originally deployed these using the OVF import GUI in vCenter and they worked for a bit until I tried troubleshooting the RADIUS stuff (that and I want to be able to deploy from script).

I'm mimicking pretty much everything that I'm doing in the OVF GUI - but I cannot now even get these appliances to pass traffic through to the connection servers. From our outside IP all I get is "Failed to contact connection server" in the HTML interface, just a timeout in the 4.4 client.

[markbenson · Accepted solution]

OK, so this is progressing. Yes, having "Use Blast Secure Gateway for Blast connections to this machine" ticked on Connection Server would certainly have been the cause of Blast connection failures. It must be unticked so that the Blast Secure Gateway (BSG) is used on UAG instead.

Before configuring RADIUS on UAG, make sure everything else is configured correctly first via PowerShell. Initially comment out the authMethods line so that it defaults to pass-through to Connection Server. Each time you change the .ini file, redeploy with apdeploy.ps1.

1. Test a native Horizon Client using PCoIP.

2. Test a native Horizon Client using Blast.

3. Test the HTML Access Client (which also uses Blast).

If any of these 3 tests fail, that will need to be fixed first.

Once the above 3 work, then move on to RADIUS configuration.

You can either have RADIUS configured on UAG or on Connection Server but not both. When it is configured on UAG it is important that any firewalls allow the UDP protol on port 1812 and replies so that this is not blocked. This is checked when the appliance is deployed and if this fails, RADIUS does not get set up.

It sounds like there may be another issue with this config as well.

If after you've worked through these things you are still stuck, you can  private message me and attach the logs .zip (which you can download from the admin GUI) and attach your .ini file and I should be able to determine what's wrong.

[sweater]

Yah, I have to get back to a very, very basic setup of the appliance - I was just fried yesterday for a variety of reasons not related to this issue. This has deepened my understanding of the architecture and I'm fully invested in getting this to work.

I really, really appreciate your help on this!

- mike

[druss10]

I'm going through the same process attempting to use the UAG appliances for RADIUS out to Safenet's RADIUS server in the cloud.   I was working with VMware support and experienced the same issue where the RADIUS config did not get imported into the Admin Console from the Powershell script/ini file.   I had to manually enter the RADIUS config info from the Admin Console.   Also, experienced the same issue where I was not getting the 2-Factor logon prompt.   This was occurring because I did not set the Auth Methods to radius-auth in the Horizon configuration section...not the RADIUS configuration as seen in the image.

I too am still trying to get RADIUS authentication to work, but I'm pretty sure it either firewall or F5 load-balancer related.

[sweater]

We, too, have been working with support on this - we got the UAG's deployed and working well for almost everything other than RADIUS.

No matter what we tried, we've settled back to enabling RADIUS on the underlying Windows servers instead. This pushes us back to roughly the same config that we've been running with 7.0.2 where we have separate VIPs for hitting the environment externally vs internally.

I mean it works, it's just double the amount of internal View servers needed (in our case, 4 Windows View servers instead of 2)

We plan on an upgrade to 7.1 ASAP as it's pretty cool and would probably push out the UAG's using RADIUS to a later version.

[markbenson]

As this thread is now answered, it would be better to start a new thread if you have UAG RADIUS config/setup problems. We'll then be able to sort out your specific issue.

Mark

[iforbes]

Hi Mark. My issue is similar. I have HTML, PCoIP, Blast Extreme all working fine within the LAN. I deployed UAG 3.1 (single appliance) to handle external connections. Here's the oddity. From everything I've read I'm supposed to uncheck all 3 settings (use secure tunnel https, use pcoip secure gateway..., use blast secure gateway...). Now, if they are unchecked I can authenticate with the View client, receive a list of entitled desktops, but when I click on one (any protocol) it will just stay on 'The connection server is preparing the desktop'. Nothing in View Admin illustrates that any desktops have been connected.

When I go back into the properties of the Connection server and check all 3 settings I can successfully login to the desktop via PCoIP ONLY (external connections). Blast or HTML do not work externally. I definitely have Blast enabled on the UAG and the Blast External URL points to the public resolvable name. When I choose Blast for the protocol within the View client and launch, I just get a black screen. HTML exteranlly will actually accept my authentication and show me a list of the entitled desktops. When I click one the url redirects to the Blast External URL but the webpage just spins like it's waiting for something.

So, hoping for an explanation of why I need to checkmark all 3 settings on the Connection server to even just have external PCoIP work, Second, why doesn't external Blast and HTML work?

Thanks