We are standing up a new Horizon 7.1 environment and have some questions on the traffic flow when load balancing a pair of UAG.
For external access we have a dedicated pair of connection servers. These are front-ended by a VIP on our F5 using the iApp. We do not have any tunneling configured on the F5 or the Connection Servers. We then have a pair of UAG that are front-ended by a VIP on our F5 again using the iApp. We have a public IP that is NAT to a private IP on the F5 for the VIP. We then have two connection servers with private IP. We will be doing SSL passthrough to minimize the CPU load on the F5. If I understand correctly the display protocol traffic will still have to flow persistently through the F5 and UAG to the Horizon Agent.
If the traffic does need to flow persistently through the F5 could we instead configure a VIP on our F5 that redirects to the UAG at a public IP? (e.g. vdi.mycorp.com on the F5 which load balances UAG1.mycorp.com and UAG2.mycorp.com). That way all of our client would connect to a single URL that would then redirect them to the UAG which are also publicly accessible but the user would not hit them directly. Kind of like what is described in this discussion?Resolving the balancer DNS name on Access point if it is the same for internal and external connecti...
Hi BenFB
Yes, you have it about right. The flow for the secondary protocols such as the display protocols must go through UAG in order to get the right protection to ensure that these protocols only get to the data center resources (virtual desktops and RDSH servers) when they are confirmed as being on behalf of an authenticated user. It is also important that they are routed to the same UAG appliance as was used for the user's authentication flow. Most people ensure this by configuring their load balancer for "source IP affinity". This way, the secondary protocols from a particular client device will be routed to the same UAG appliance each time.
The secondary protocols don't have to go through the LB but they do need to go via UAG. It is often easiest for everything to go through the LB as long as affinity is correctly set up.
This source IP affinity is method 1 of the 3 possible methods. Each affinity method is described in the UAG load balancing guide. It also has an explanation of the primary and secondary protocols used with Horizon - Load Balancing across VMware Unified Access Gateway Appliances (formerly known as Access Point)
Hi BenFB
Yes, you have it about right. The flow for the secondary protocols such as the display protocols must go through UAG in order to get the right protection to ensure that these protocols only get to the data center resources (virtual desktops and RDSH servers) when they are confirmed as being on behalf of an authenticated user. It is also important that they are routed to the same UAG appliance as was used for the user's authentication flow. Most people ensure this by configuring their load balancer for "source IP affinity". This way, the secondary protocols from a particular client device will be routed to the same UAG appliance each time.
The secondary protocols don't have to go through the LB but they do need to go via UAG. It is often easiest for everything to go through the LB as long as affinity is correctly set up.
This source IP affinity is method 1 of the 3 possible methods. Each affinity method is described in the UAG load balancing guide. It also has an explanation of the primary and secondary protocols used with Horizon - Load Balancing across VMware Unified Access Gateway Appliances (formerly known as Access Point)
Hi markbenson,
Thank you, it looks like method 3 will do what we want. I've spoken with our network and F5 teams and they are looking for clarification on the following.
As a side note, I noticed the document you mentioned might have a typo in the "UAG Configuration for External URLs" section of Method 3. The 5th line of the table has a value of "https://ap2.myco.com:4172/" and I believe it should be "https://ap2.myco.com:443/".
In answer to your questions:
1. With method 3, you can know which connections are the primary protocol because it comes in on a specific VIP. This is 192.168.0.100 in the method 3 example. None of the secondary protocols use that VIP.
2. No. UAG never initiates a connection to the client. It is always the other way round. For TCP connections they are always made from client to UAG. For UDP the datagrams are always initially sent from the client to UAG. Reply datagrams are sent in the opposite direction with source and destination ports reversed. This is very common with UDP and firewall rules generally allow this reply UDP data automatically.
3. The tables in the LB document detail the communication protocols used. It is only the primary protocols that actually "load balance" i.e. get routed by the LB according to availability and relative load. The secondary protocols must route to the same UAG appliance as was chosen by the LB for the primary protocol connection. Whether the route taken by the secondary protocols is via a LB or not is not important to UAG.
4. For questions about third party products, please direct them to the relevant vendor.
Thanks for pointing out the typo. You are correct. should have been 443 not 4172. It's fixed now. The rest of the details are correct.
We are still stumped on how the Horizon Client is redirected from the initial URL to the secondary URL. For example, if the Horizon Client is configured to talk to view.myco.com then what is responsible for redirecting it to talk to ap1.myco.com or ap2.myco.com? Is this a redirect on the F5? Are the tunnelExternalURL, blastExternalURL and pcoipExternalURL responsible for redirecting the client?
There is no redirect. The client simply connects to view.myco.com. That is the primary protocol and the LB will select one of the available UAG appliances.
The secondary protocols such as Tunnel, Blast and PCoIP are in addition and are made by the client using the configured tunnelExternalUrl, BlastExternalUrl and pcoipExternal Url values configured on UAG. The value of these settings is automatically passed to the client. It is these secondary protocol connections that are routed from client to the specific UAG appliance using any of the 3 affinity methods.
The table shows the correct value for the xxxExternalUrl settings for each secondary protocol.
Thank you! This is the once piece we were assuming was taking place but couldn't find clear documentation on how that works.
Would we need to have a single certificate with multiple SAN entries on the F5 and UAG or could they each have separate certificates? My concern based on your example is that the client will initially talk to view.myco.com which is on the F5 and has a certificate for view.myco.com. The UAG will then have their own certs for ap1.myco.com and ap2.myco.com. Will the Horizon Client be OK with the client eventually connecting to a different URL with a different certificate?
You can manage certificates in several ways. Wildcard certificates are supported. e.g. *.myco.com. Also SANs in certificates are supported; so view.myco.com plus SANs of ap1.myco.com, ap2.myco.com etc.
If you offload TLS to a LB. You should put that same cert on the LB and all UAG appliances. If you don't offload TLS, then there is no cert on the LB.
I realized the way I'm currently designing this the Horizon Client will point to view.myco.com but will end up communicating with a UAG that only has a cert for ap1.myco.com or ap2.myco.com. It sounds like I'll need one of the following.
Is there any scenario where I can have three certs and bypass the F5? One for view.myco.com that the Horizon Client points to, one on the first UAG for ap1.my.com and one on the second UAG for ap2.my.com. I do this today with our internal connection servers and it requires bridging SSL on the F5. I like this approach since it "masks" the names of the individual connection servers, allows me to dynamically add/remove connection servers and allows for certs to be replaced on a single device (As opposed to having to coordinate the replacement of the cert on the F5 and connection server simultaneously). I suspect we can't do this and I'll have to do option one above but I'm optimistic there is a way.
The 3rd option you mention is also possible.
With affinity methods 1 and 2, connections made by clients for primary and secondary protocols all use view.myco.com, so everything can be done with just one certificate for view.myco.com which you can put on both UAGs and your LB.
Affinity method 3 also uses uag1.myco.com and uag2.myco.com. This is for the secondary protocols for the tunnel and blast. If the route for these hostnames bypasses the LB so that TLS terminates on UAG, then you can use the 3 different certificates. view.myco.com on the LB, uag1.myco.com on UAG1 and uag2.myco.com on UAG2. Some customers don't really want to have to manage multiple certs though and simplify the setup by getting just one SSL cert with a name of view.myco.com and SAN entries for about 5 UAG appliances; uag1.myco.com ... > ... uag5.myco.com. Either that or a wilcard cert *.myco.com. That way if you need to add further UAG appliances in future, you can just use the same cert on the additional ones. Your choice really. It often comes down to ease of cert management.
The important thing for any TLS connection is that the certificate on the point of TLS termination matches the hostname used by the client. If the client is making a TLS connection for the tunnel or for Blast directly to uag2.myco.com, a certificate on the point of TLS termination (on UAG2) must have a name or SAN uag2.myco.com. The other important thing is that if the tunnel connection goes via an intermediate LB that is configured for TLS bridging, then the same cert must be used on the LB and UAG. If not, the client will detect that as a potential MITM attack.
If you are just using affinity methods 1 or 2, then every cert is view.myco.com.
markbenson
I'm not understanding how that would work and the client wouldn't see it as a MITM. We are using method 3 for session affinity and bypass the F5 for the secondary protocols.
We have a VIP on the F5 for view.myco.com. The only way for this to present a cert is to enable SSL bridging. The cert on the F5 has a common name of view.myco.com and a single SAN entry of view.myco.com. The VIP load balances the external NIC of the UAG. We've configured health monitoring and verified it's working.
We have two UAG, ap1.myco.com and ap2.myco.com
ap1 has a certificate with a subject CN of ap1.myco.com and a single SAN entry of ap1.myco.com
ap1 has the following external URL configured.
pcoipExternalUrl=10.20.30.41:4172
tunnelExternalUrl=https://ap1.myco.com:443
blastExternalUrl=https://ap1.myco.com:443
ap2 has a certificate with a subject CN of ap2.myco.com and a single SAN entry of ap2.myco.com
pcoipExternalUrl=10.20.30.42:4172
tunnelExternalUrl=https://ap2.myco.com:443
blastExternalUrl=https://ap2.myco.com:443
Pointing the Horizon Client to view.myco.com results in "Error: A network error occurred". Pointing the Horizon Client to ap1.myco.com or ap2.myco.com connects successfully.
Looks like it has been configured correctly. So the issue only occurs with view.myco.com via the LB. Connecting to UAG appliances is all working.
This doesn't look like a UAG issue.
I think you should investigate the setup of the LB and certificate. The client logs should help. Also do an SSL Test on your view.myco.com e.g. from SSL Server Test (Powered by Qualys SSL Labs)
Mark
Thanks markbenson. We can chalk this one up to user error. When I stood up the additional connection servers for external access I forgot to disable the secure tunnel and secure gateway.
The good news is that this is working exactly as you described.
BenFB - Great. Glad it's answered. Thanks for posting the details and circling back, I'm sure it'll help others too.
Great post indeed !
Quick question more related to networking/load balancing than UAG-> "The flow for the secondary protocols such as the display protocols must go through UAG"
How is that possible ? I mean, is this traffic passing trough the load balancer or the connection is direct from Horizon Client to external IP of UAG ?
In case of natting the public IP, the traffic ( pcoip/blast) flow from the external firewall to the UAG or to the load balancer ?
Thank you.
dmuligan You can do it either way.
The default and simplest configuration is to flow the BLAST/PCoIP traffic from the Horizon Client > Load balancer > UAG > virtual desktop. We use the load balancer for the primary protocol and for the secondary protocol (BLAST/PCoIP) the Horizon Client talks directly to the UAG. You configure the tunneled external URL on the UAG which tells the horizon client the URL to connect to which bypasses the load balancer and talks directly to the UAG. It requires additional public IP and potentially additional certificates but we prefer taking the load off of the load balancer.
