VMware Horizon Community
epa80
Hot Shot
Hot Shot
Jump to solution

Rebooting UAGs

We have 2 UAGs in our DMZ, that are connected to 2 connection brokers via an F5 LTM. Our understanding was a benefit of the UAGs vs. security servers, was that if users are connected using UAG, they will not get kicked if we have to restart one of the UAGs. Essentially if the connection is brokered, the UAG is out of the mix. But that's not what we're seeing. When we reboot a UAG, the person gets bounced. Is our expectation of this behavior incorrect?

1 Solution

Accepted Solutions
jrodsguitar
Enthusiast
Enthusiast
Jump to solution

Right this is my biggest problem with the UAG's. You can't just reboot the UAG's and have them magically move the users that are connecting through them to other UAG's.

It's almost a poor man's solution (For a very expensive product) but you have to use Quiesce mode on the UAG (Or disable in the load balancer) to drain the UAG's. Then once all users are off the UAG you can reboot it. I suggested a solution that will auto move sessions to another UAG for a truly seamless experience while performing maintenance etc. Hopefully VMWare one day engineers such a solution.

Blog: https://powershell.house/

View solution in original post

22 Replies
jrodsguitar
Enthusiast
Enthusiast
Jump to solution

Right this is my biggest problem with the UAG's. You can't just reboot the UAG's and have them magically move the users that are connecting through them to other UAG's.

It's almost a poor man's solution (For a very expensive product) but you have to use Quiesce mode on the UAG (Or disable in the load balancer) to drain the UAG's. Then once all users are off the UAG you can reboot it. I suggested a solution that will auto move sessions to another UAG for a truly seamless experience while performing maintenance etc. Hopefully VMWare one day engineers such a solution.

Blog: https://powershell.house/
epa80
Hot Shot
Hot Shot
Jump to solution

Thanks. That settles that. Kind of a bummer, we were kind of sold on that being the case. I guess technically quiesce mode does it, but, it's not how we understood it.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

One annoyance as well. We are using CPA across 2 data centers. If I authenticate via the UAGs in DC1, but am given a VM from a pool in DC2, my session doesn't identify which UAG I used. Hence if I throw a UAG in quiesce mode, I technically won't know if everyone's off it, because they could be in the opposite DC. When I connect all within the same DC, I cans ee which UAG I am on in the Security Gateway tab in the session (Horizon 7.3.2).

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Separate question but kind of related.

We utilize F5 as our load balancer. Essentially all users, internally and externally, go to a GTM. We'll call it https://vdi.site.com. For this discussion, since it's UAG, we'll stick to external use case.

When they hit the GTM, there are 2 LTMs behind it:

DC1LTM = UAG 1, UAG 2

DC2LTM = UAG 1, UAG 2

The UAGs themselves are pointed at another LTM for connectivity to their Horizon brokers. My question is though, when I set say the DC1s UAGs into quiesce mode, how does the F5 know not to send traffic that way? Is there a health check that can be configured for the F5 to be aware of quiesce mode?

Probably a question for F5 I suppose, but, thought I'd try here.

Reply
0 Kudos
jrodsguitar
Enthusiast
Enthusiast
Jump to solution

Excellent question. I can't speak for F5 since we use Citrix Netsalers but yes as you said you must have a health check configured on the F5 that will know if the UAG is in quiesce mode. Again this is what works on Netscaler so it may be different On F5. This should return a 200 if successful and 503 if UAG is in quiesce mode.

o   Send String: “GET /favicon.ico HTTP/1.1\r\nHost: \r\nConnection: Close\r\n\r\n”

Blog: https://powershell.house/
a_p_
Leadership
Leadership
Jump to solution

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Off topic again, but, hoping someone can point me in the right direction yet again.

When coming in from the outside via the UAGs, our desktops are stating USB Redirection is Not Available. However, going to the UAGs from internal, it works. From our legacy security servers, we can access USB redirection internal or external. My network security team SWEARS the same firewall rules are in place for the UAGs, as was for the security servers, specifically port 32111. Is there a setting on the UAGs themselves I am missing?

I'm pretty much positive it's a firewall rule as, again, I come in from our secure network it works, outside network it breaks. Basically solidifying the idea the UAGs CAN do it, it's just about what road I'm taking in.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

And I think we already found it. On the connection brokers, "HTTP(S) Secure Tunnel" was unchecked. We tested this via the security servers, meaning when we unchecked it they broke in the same manner. Technically we're still seeing the issue even after checking them, but, I think now it has to do about what we're configuring on F5. There's a field asking what FQDN users will use to connect to the environment. We put in the LTM FQDN there (even though users technically go to a GTM, the GTM literally just hands them on to an LTM), but, starting to think that's a misconfig and we should just go GTM all the way.

Reply
0 Kudos
BenFB
Virtuoso
Virtuoso
Jump to solution

The only port we allow externally to our F5/UAG is TCP 443 and USB redirection is working for us. We have all three of the tunnels unchecked on our connection servers.

Edit: It turns out TCP 32111 was also being allowed and that's why USB redirection was working. We removed that and confirmed that USB redirection is no longer allowed externally for us.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

So Ben thanks for the reply. Let me go over our architecture a bit, see how maybe we're differentiating.

  • We have all users pointed to a GTM which is split DNS. Right now we're focused on externals, so, we'll stick to that. Externally when you hit the GTM, you are handed off to an LTM in either DC1 or DC2. Under each of those LTMs, are 2 UAG servers. So DC1UAG1/DC1UAG2, DC2UAG1/DC2UAG2.
  • The UAGs are each configured to point at an internal LTM for their Connection Server URL. Inside that LTM, we have 2 brokers designated for external access. This way we are not doing any 1 to 1 mapping. So the DC1 UAGs are pointed at DC1BrokerLTM, DC2 UAGs are pointed at DC2BrokerLTM. Again these LTMs are in front of 2 connection brokers isolated for external access.
  • For the PCOIP External URL field we're using the IP of the UAG LTM.
  • For Blast External URL we're using the UAG LTM FQDN:8443.
  • For Tunnel Eternal URL we're using the UAG LTM FQDN:8443.
  • We have all 3 boxes unchecked on the isolated connection brokers.

From the outside when I try to get in, I get that a tunnel connection could not be established and to try again. I'm testing by bypassing the GTM and going directly to the external LTM. If I check the box for tunnel connections on the brokers, I can get in, but, I won't be able to do USB pass through.

Hopefully this isn't too crazy to read through. Hopefully you can spot what we're missing.

To re-clarify, our security guys are saying the same firewall rules should be in place for the UAGs on the DMZ, as was the security servers. With the boxes checked and coming through the security servers, I can do USB.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Is this setting incorrect/moot for this topic? On the F5 for the LTM. I ask because again we're looking at using UAGs now:

pastedImage_0.png

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Little bit further. When we switch to using :443 instead of :8443 for the tunnel server, we get a cert error as seen below. It's odd because we're using SSL offloading at the F5, and a wildcard cert. If I don't do tunneling, just straight up PCoIP or BLAST, I can get in fine. Same cert would be in place, so, little thrown off there. Still working through it though. It's ironic because the UAGs are green all the way haha.

pastedImage_1.png

pastedImage_0.png

Reply
0 Kudos
BenFB
Virtuoso
Virtuoso
Jump to solution

We actually have a nearly identical deployment with a few exceptions.

  • We are a single datacenter at the moment with no GTM. Our internal teams are working on deploying GTM and then I will switch to that.
  • We use Blast Extreme instead of PCoIP
  • We do not tunnel our UAG through the F5. From Load Balancing across VMware Unified Access Gateway Appliances we are doing "Method 2 - Multiple Port Number Groups". You can see my discussion on that here Traffic flow when load balancing UAG. Essentially we have a VIP on LTM using the Horizon iApp that points to the two UAG. The Blast External URL on each UAG is the public address of the individual UAG instead of LTM.

I think you might need to allow TCP 32111 from the UAG to the Horizon Agent. See line 11.

View TCP and UDP Ports

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Thanks for the reply, Ben. I've been told by our network security guys that "all the UAGs have port 32111 to all the desktops IP pools has been confirmed to be open".

I still think we most likely have something misconfigured at the F5 level, but, my theory was weakened a bit today. When I tried going DIRECTLY to one of the UAGs via the Horizon client, and upon authenticating, I was met with "tunnel reconnection is not permitted". So even eliminating the F5, there's something still screwed up.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Would it matter if in the "TLS Server Certificate Settings" when I uploaded my cert, if I only did it for the Admin interface and not the Internet interface? I'm at a point now where authenticating either externally via the F5 LTM, or internally to 1 direct UAG without F5, gives me the same error about certificate mismatch:

pastedImage_0.png

But again, we're using a wildcard on the F5, that was also uploaded to the UAGs. But as I think back it was only with the admin interface box checked. Would it even matter?

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

I should clarify also:

With the "Tunnel External URL" being FQDN:443, I get the cert error. With it being FQDN:8443, I get the tunnel reconnection is not permitted error. For now I've been leaving it as :443.

Reply
0 Kudos
BenFB
Virtuoso
Virtuoso
Jump to solution

You need to apply a valid certificate that matches the FQDN that the users are connecting to. The management interface is ideal but not required (They only just added support for replacing the management certificate).

You might want to review the documentation on certificates. There are some gotchas with wildcard certs.

Selecting the Correct Certificate Type

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

The thing that has me scratching my head about certs though, in particular our wildcard cert, is if I disable tunneling via the UAG, I can get in via PCoIP/BLAST on them. Even externally through the F5s. The cert hasn't changed, it's still the same wildcard cert.

The wildcard cert I have on the UAGs is the same wildcard cert from the same CA as the one out on F5 for the LTMs, but, it does have a different expiration date. It expires later. Essentially they gave us a newer version of the wildcard. It's been in the back of my mind that perhaps that's a mismatch still,but, like I said no one complains at me about cert(s), UNTIL I enable the tunnel.

Just tested now to be certain. UAGs configured with only PCoIP/Blast enabled: get right in via the LTM from external. Enable tunnel on the UAGs, connect the same way: "Connection Server authentication failed. The tunnel server presented a certificate that didn't match the expected certificate.". This is still with the tunnel configured as my UAG LTM FQDN:443.

Have a ticket with support open, so, we'll see what they find. I'm pretty stumped by now.

Reply
0 Kudos