DanReynolds
Enthusiast
Enthusiast

Adding/Incorporating a UAG

Jump to solution

I'm still working through some upgrade issues. I need to get to Horizon 7.10.x (Windows 10 versions) and I need to get rid of some old, moldy Windows 2008 servers. Current environment is (2) connection servers - (1) is a new Windows 2019 server with the existing View version I'm running (7.5.1) and the old 2008R2 View connection server. [note: I got help with that part - message]

Now I'm attempting the next piece - I want to replace the existing View Security server with a UAG. I have it built and I've started setting it up. Oh first it's UAG euc-unified-access-gateway-3.10.0.0-16493322_OVF10. I 'assumed' the version that would work with 7.10.x would be this one. I have gotten into the actual setup (I'm using the Carl Stahlhood document). I've only gotten this far...

DanReynolds_0-1606999579822.png

I'm really stuck on this part. What I have been attempting to do was setup the UAG  and leave the existing security server going so I could test first before going live. It doesn't look like that is possible. Plus I have no real idea why the UAG can't connect to the Horizon Destination Server (connection server right?).

And someone give me some guidance? I only wanted to test ahead of time because this is a new arena for me. I have a small Horizon environment - 70 users, Full Win10 Clones. I have had it working very well for several years now. I'm a long time VMware user (2006?). And on top of that I'm a one man band. It's all me. If you can help me out a little I would sure appreciate it.

 

0 Kudos
1 Solution

Accepted Solutions
nburton935
Hot Shot
Hot Shot

Your UAG does not need those ports outbound to the internet (based on your notes), it needs them to the network(s) where the virtual desktops reside. Apologies when I sent UAG>Desktops, I meant virtual desktops. Not client machines.

Assuming your UAG resides in a DMZ where access is limited to the internal networks, you'll need to open those ports between UAG and the internal VDI network(s). 

The fact you could login and see your desktop pools means UAG > Connection Server communication is good. You just need to get the UAG > Virtual Desktop rules in place. Are you static NATing to the UAG on all ports from the internet? 

-Nick 

View solution in original post

0 Kudos
10 Replies
nburton935
Hot Shot
Hot Shot

Can you confirm your Security Server is only pointing to the old 2008 server and you’re not attempting to use this one for UAG? 

Ensure your Connection Server URL is resolvable and reachable over 443 from the UAG. Add a host entry if needed. Also ensure the certificate hash matches your CS cert. On the Connection Server UAG is pointed to, ensure all of your secure tunnel settings are disabled. These configs are not needed with UAG.

DanReynolds
Enthusiast
Enthusiast

OK, I'm going to sound like a real idiot here. My assumption is that when I added the 'new' connection server to my existing view environment that everything was "sort of" connected. So here are my questions:

  1. How do I confirm who is talking to who? In the "old" Flash admin console - in the dashboard - both connection servers are "visible" and the connection server is visible. The UAG is not showing up.
  2. I will verify that the connection server URL is resolvable.
  3. I know my certs are all screwed up. That's something I've never gotten a good hold on.
  4. If - I disable all the secure tunnel settings on the "new" connection server - won't it also disable them on the old connection server?

Thanks in advance. I can usually bulldoze my way to a solution but not so good this time.

0 Kudos
nburton935
Hot Shot
Hot Shot

1) The UAG is not like the security server (no 1-1, no IPSec tunnel, etc). - it does not show up in your console when integrated. You do have the ability to add it for monitoring purposes. That is a big advantage of the UAG - no more having to partition off Connection Servers just for external connections. You can use the same Connection Servers for both internal and external. 

4) No, each secure tunnel setting is specific to that Connection Server. Under Settings > Servers > Connection Servers, you will notice that each configuration is unique to that CS. The CS that the UAG is pointed to must have all of tunnel settings disabled to work correctly - ensure tunnel, PCoIP SG, and BSG are all disabled. The UAG handles these.

-Nick

DanReynolds
Enthusiast
Enthusiast

Took me awhile to get back to you. I had a multitude of issues. Some firewall, some me, some UAG...

I got the host file on both the connection server and the UAG - putting that host entry in on the UAG is pretty slick. I'm seeing all green lights now on the UAG. I also removed the secure tunnel settings on the "new" connection server.

I can login from a remote Horizon Client to the UAG - I get authenticated and I see the pools. When I try to connect I get a black screen and it disconnects. I think I know what this is. I'm pretty sure the correct firewall ports are open. Where I think my holdup is now is the version of my UAG vs. the connection server(s). I'm using UAG 3.10 which goes with Horizon version 7.10.3 - right this minute my Horizon is 7.5.1 something. I'm relatively certain they all need to be up to 7.10.3 - or at the very least my "new" connection server...

My big question - do I have to upgrade both connection servers (remember one is 2008 - it's going away, and the new one is 2019 - the replacement). And if I do have to update both will that "work" on the old server? And on top of that do I have to update the existing security server (also 2008) till I move over permanent to the UAG... I have a lot of balls I'm trying to balance here. But by golly I think I'm getting closer. 

Let me know what you think Nick, if I'm not too confusing or too much trouble. THANKS!

0 Kudos
nburton935
Hot Shot
Hot Shot

Here’s the KB on upgrading a CS+Security Server. You should do this while upgrading your Connection Servers. I assume you don’t have redundant Security Servers, so you’ll need to plan for downtime for external users.

https://docs.vmware.com/en/VMware-Horizon-7/7.4/horizon-upgrades/GUID-A9455797-DB6C-46EC-A196-2A8AEF...

I would be pretty surprised if the UAG / Horizon mismatch is causing the issue you’re indicating, as it sounds firewall-related. Usually it will work even though it’s not technically supported. Can you confirm your firewall rules and UAG configs for Blast and PCoIP fields? Want to make sure all lines up there.

If using default configs/ports, its internet > UAG (443, 8443, 4172 tcp+udp) and UAG > desktops (22443, 4172 tcp+udp and 32111, 9427 tcp). Looks like you’ve got UAG>CS correct since you can login and it reports green.

0 Kudos
DanReynolds
Enthusiast
Enthusiast

Here's what it looks like in the new connection server, the 2nd one is the new one

DanReynolds_0-1607723088388.png

Here's the FW settings:
(ports are what you gave me last time...)

DanReynolds_1-1607723310188.png

I  made all these changes and I'm still getting the same thing. I have not updated the connection/security servers yet. Still getting a black screen on PCoIP and BLAST. I don't think the connection is ever really there. But like last time I can get logged in and see the pools.

DanReynolds_0-1607723637409.png

 

 

 

 

0 Kudos
nburton935
Hot Shot
Hot Shot

Your UAG does not need those ports outbound to the internet (based on your notes), it needs them to the network(s) where the virtual desktops reside. Apologies when I sent UAG>Desktops, I meant virtual desktops. Not client machines.

Assuming your UAG resides in a DMZ where access is limited to the internal networks, you'll need to open those ports between UAG and the internal VDI network(s). 

The fact you could login and see your desktop pools means UAG > Connection Server communication is good. You just need to get the UAG > Virtual Desktop rules in place. Are you static NATing to the UAG on all ports from the internet? 

-Nick 

View solution in original post

0 Kudos
DanReynolds
Enthusiast
Enthusiast

I corrected the outbound ports as you mentioned. 

Your comment that said "it needs them to the network(s) where the virtual desktops reside" rang a bell with me. A few years back I had a consultant help me VLAN my internal network into 3 segments - physical computers/devices; VM's (desktops), and servers (mostly). 

There was no path to that VLAN. The same consultant was the one setting up the firewall rules. It was taking too long for me to talk to you and then talk to them so I monkeyed around with the rules & 1:1 NAT till I figured out what works. 

I can log into a machine, I have the drive sharing thing turned on and that works. And I can tell it's going through the UAG, of course. 

Now I'm going to have the consultant go through the rules and take out all the extras. I really don't think a bunch of them that they put in are necessary at all. Networking is my weakest skill. But as long as you don't do something too stupid it's pretty easy to fix.

On my upgrade - on my new connection server, can't I just kick out the old connection server and security server, upgrade, swap my external DNS entry to the UAG and go? I know I have to adjust TTL so the users will see the "new" connection...

Nick I thank you a million times!

0 Kudos
nburton935
Hot Shot
Hot Shot

Best/easiest way to proceed:

1) Ensure your UAG certificate is good (matches your current external name, no client errors on connection, etc.) and do plenty of testing.

2) Flip the external DNS entry to point to the UAG. At this point, you could adjust the TTL to a lower value in case you had to back out the change; it would make the back out faster. 

3) You’ll see sessions in the admin console start marking their secure gateway as the UAG name. This means they’re flowing through the UAG versus Security Server.

4) Once all sessions are off the old SS, you can decom it and the 2008 CS. Here’s how you remove the old CS from the environment:

https://kb.vmware.com/s/article/1010153

5) Upgrade Horizon on new CS whenever you’re ready.

(Feel free to hit the kudos button on any post you found helpful and mark the best post as the answer!)

Glad you got it working!

-Nick

DanReynolds
Enthusiast
Enthusiast

Wow, that's about as clear as can be. 

Certificates have ALWAYS screwed me up. I'm going to work on it and get it fixed. 

Thanks again. Gave you kudos on one and then marked the other best answer and it wouldn't let me kudos any of the others. Sorry. 

0 Kudos