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.
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.
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).
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.
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”
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.
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.
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.
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.
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.
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.
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.