• Introduction
• Horizon Protocols
  • Primary Horizon Protocol
  • Secondary Horizon Protocols
• Session Affinity Options for Secondary Protocols
  • Method 1 - Source IP Affinity
  • Method 2 - Multiple Port Number Groups
  • Method 3 - Multiple VIPs
• Health Monitoring
• SSL Offloading or Bridging

Introduction

UAG is a VMware virtual appliance designed to protect desktop and application resources to allow remote access from the Internet. For an overview of UAG, refer to my earlier blog article. It is used with:

• VMware Horizon 7
• VMware Horizon 7 on VMware Cloud on AWS
• VMware Horizon Cloud (IBM Cloud and Microsoft Azure Cloud)
• VMware Workspace ONE Access (Identity Manager)
• VMware Workspace ONE UEM (AirWatch) Content Gateway
• VMware Workspace ONE UEM (AirWatch) per-App VPN Tunnel

This document focuses on the Horizon 7 use case for UAG with an external load balancer. With UAG 3.4, a new High Availability feature is also available. Refer to the UAG documentation for details of that feature.

UAG is typically deployed in a DMZ. For high availability and scalability requirements in a production deployment, several UAG appliances are usually setup behind a load balancer as shown in Figure 1.

Figure 1 - Multiple UAG appliances behind a load balancer.

This article focuses on the load load balancing requirements for the Horizon use cases. It discusses the distinction between the primary and secondary Horizon protocols and describes the three methods for guaranteeing session affinity. The three methods ensure that all protocol traffic from a Horizon client session goes to the same UAG appliance. This article also covers health monitoring and SSL offload/SSL bridging for load balancers.

Transport Layer Security (TLS) and the predecessor Secure Sockets Layer (SSL) are both referred to in this document as just SSL. By default, SSL is disabled on UAG and only TLS 1.1 and TLS 1.2 are enabled.

Horizon Protocols

When a Horizon Client user connects to a Horizon environment, several different protocols are used. The first connection is always the primary XML-API protocol over HTTPS. Following successful authentication, one or more secondary protocols are also made.

Primary Horizon Protocol

The user enters a hostname at the Horizon Client and this starts the primary Horizon protocol. This is a control protocol for authentication, authorization and session management. It uses XML structured messages over HTTPS (HTTP over SSL). This protocol is sometimes known as the Horizon XML-API control protocol. In a load balanced environment as shown above in figure 1, the load balancer will route this connection to one of the UAG appliances. The load balancer will usually select the appliance based first on availability, and then out of the available appliances will route traffic based on the least number of current sessions. This has the effect of evenly distributing the traffic from different clients across the available set of UAG appliances. The load balancer affinity timeout should be set to match the session timeout, which by default is 10 hours. This ensures that subsequent connections for XML-API during the whole session will be directed to the same UAG appliance. Affinity to an individual UAG appliance for the XML-API protocol can be ensured with source IP affinity as described below for method 1. For methods 2 and 3 where source IP affinity is not used, it is common to perform cookie based affinity by the load balancer. This is either done by tracking the UAG session cookie called "ACCESSPOINTSESSIONID" or can be done with a load balancer inserted cookie. In all cases, the XML-API protocol must have affinity with the initially selected UAG appliance for the entire session. Specific configuration details for cookie tracking or cookie insert for HTTPS should be obtained from your load balancer vendor.

Secondary Horizon Protocols

After the Horizon Client has established secure communication to one of the UAG appliances, the user authenticates. If this authentication attempt is successful, then one or more secondary connections are made from the Horizon client. These secondary connections can include:

• HTTPS Tunnel used for encapsulating TCP protocols such as RDP, MMR/CDR and the client framework channel. (TCP 443).
• Blast Extreme display protocol (TCP 443 and UDP 8443). Note that UDP is optional with Blast.
• PCoIP display protocol (TCP 4172 and UDP 4172).

These secondary Horizon protocols must be routed to the same UAG appliance to which the primary Horizon protocol was routed. The reason for this is so that UAG can authorize the secondary protocols based on the authenticated user session. An important security capability of UAG is that it will only forward traffic into the corporate datacenter if the traffic is on behalf of an authenticated user. If the secondary protocols were to be misrouted to a different UAG appliance to the primary protocol one, they would not be authorized and would therefore be dropped in the DMZ and the connection would fail. Misrouting the secondary protocols is a common problem if the Load Balancer is not configured correctly.

Session Affinity Options for Secondary Protocols

Method 1 - Source IP Affinity

This is the simplest configuration for a load balancer as it uses standard port numbers and a single load balanced VIP. It relies on the load balancer to route secondary protocols to the same UAG appliance as was selected for the primary Horizon protocol. It can do this on the basis of repeat connections coming from the same Horizon client IP address. Unfortunately, this method doesn't work in all situations. For example with certain Network Service Providers or NAT devices, the source IP address is not available for this affinity configuration. If source IP affinity can't be used in your environment, then one of the other two methods should be used as they don't rely on source IP affinity.

In this example, the public IP address is 10.20.30.40 (uag.myco.com) and would be translated to 192.168.0.100 (the load balanced VIP DMZ IP address).

UAG Configuration for External URLs for this configuration would be as shown in this table.

Method 1 advantages:

1. Uses standard port numbers.
2. Does not require multiple public virtual IP addresses.

Method 1 disadvantages:

1. Relies on source IP address affinity which is not always possible.

Method 1 is recommended for all environments where source IP address affinity is possible. Where it is not possible, then either method 2 or method 3 should be used.

Method 2 - Multiple Port Number Groups

Multiple port group affinity does not rely on source IP address for affinity. Instead the load balancer is configured to route the secondary Horizon protocols based on unique port numbers assigned to each UAG appliance. The primary Horizon protocol on HTTPS port 443 is load balanced to allocate the session to a specific UAG appliance based on health and least loaded. The secondary connections would then be routed to the correct UAG appliance based on the following Load Balancer configuration table.

The same port mapping scheme can be used for additional UAG appliances 03 > 99. The virtual IP address for the load balancer might be behind a NAT device. In this example, the public IP address is 10.20.30.40 (uag.myco.com) and would be translated to 192.168.0.100 (the load balanced VIP IP address).

UAG Configuration for External URLs for this configuration would be as shown in this table.

Method 2 advantages:

1. Does not rely on source IP affinity.
2. Does not require multiple public virtual IP addresses.

Method 2 disadvantages:

1. Uses non standard port numbers from the Internet although the port numbers on the UAG appliances themselves are standard.

Method 3 - Multiple VIPs

This method is similar to the multiple port groups method except instead of dedicating port number to each UAG appliance it dedicates an individual VIP to each appliance in addition to the primary load balanced VIP. If you have 2 UAG appliances then you would set up 3 VIPs. The primary Horizon protocol on HTTPS port 443 is load balanced to allocate the session to a specific UAG appliance based on health and least loaded. The secondary connections would then be routed to the correct UAG appliance based on the following Load Balancer configuration table.

Note that the secondary protocols don't have to be routed via the load balancer. If required they can bypass the load balancer.

In this example

• the first UAG appliance public IP address is 10.20.30.41 (uag1.myco.com) and would be translated to 192.168.0.101.
• the second UAG appliance public IP address is 10.20.30.42 (uag2.myco.com) and would be translated to 192.168.0.102.

UAG Configuration for External URLs for this configuration would be as shown in this table.

Method 3 advantages:

1. Does not rely on source IP affinity.
2. Uses standard port numbers.

Method 3 disadvantages:

1. Requires an additional public facing VIP for each UAG appliance in addition to the primary load balanced VIP.
   

Health Monitoring

A load balancer monitors the health of each UAG appliance by periodically sending an HTTPS GET /favicon.ico request (e.g. https://uag1.myco-dmz.com/favicon.ico). This monitoring is configured on the load balancer. It will perform this HTTPS GET and expect a "HTTP/1.1 200 OK" response from UAG to know that it is "healthy". If it gets a response other than "HTTP/1.1 200 OK" response or doesn't get any response, it will mark the particular UAG appliance as down and will not attempt to route client requests to it. It will continue to poll so that it can detect when it is available again. A response of 200 from UAG indicates the health of UAG itself as well as the Horizon services and the health of the Connection Server(s) used.

UAG can be put into "quiesce" mode after which it will not respond to the load balancer health monitoring request with a "HTTP/1.1 200 OK" response. Instead it will respond with "HTTP/1.1 503" to indicate that the UAG service is temporarily unavailable. This setting is often used prior to scheduled maintenance, planned reconfiguration or planned upgrade of an UAG appliance. In this mode, the load balancer will not direct new sessions to this appliance because it will be marked as unavailable, but can allow existing sessions to continue until the user disconnects or the maximum session time is reached. Consequently this operation won't disrupt existing user sessions. The appliance will then be available for maintenance after a maximum of the overall session timer, which is typically 10 hours. This capability can be used to perform a rolling upgrade of a set of UAG appliances in a strategy resulting in zero user downtime for the service.

SSL Offloading or Bridging

Many load balancers have the capability of SSL offloading where the SSL connection terminates at the load balancer. This can be useful for managing SSL server certificates and ciphers etc. at the load balancer.

In order for the client connection to be secure right to UAG, if the Load Balancer is configured to terminate SSL, then it is necessary to re-encrypt SSL traffic for communication between the load balancer and UAG. This is often known as SSL bridging as nothing is actually offloaded from UAG. SSL bridging is not necessary but it is supported. If SSL bridging is used, then it is important to install the same SSL server certificate on UAG as is on the load balancer. This is because when a Horizon Tunnel and Blast connection is made by the client, it is expecting the same certificate at the point where TLS is terminated. It does this to detect a malicious MITM attack. In other words UAG and the load balancer must have the same certificate. From UAG 3.5 onwards, it is possible to use a different certificate on the load balancer and UAG in which case you can configure the public load balancer certificate for the Tunnel and Blast sessions so that the thumbprint mismatch will not occur.

UAG supports load balancers that use SSL bridging and load balancers that pass through the SSL communication for termination at UAG.