Load Balancing across VMware Unified Access Gateway Appliances

Version 17

     

    Introduction

     

    From version 2.9 the appliance is is now called Unified Access Gateway (UAG) instead of the old name of Access Point. It's the same, just a different name.

     

    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/Access Point, refer to my earlier blog article. It is used with:

     

    • VMware Horizon View
    • VMware Horizon Air (DaaS)
    • VMware Horizon Air Hybrid Mode
    • VMware Identity Manager
    • Airwatch Tunnel Gateway/Proxy

     

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

     

    APLB1.png

    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.

     

    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

     

    "To affinity and beyond!"

     

    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 (ap.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.

     

     

    UAG ApplianceConfiguration ItemValue
    AP01tunnelExternalURLhttps://ap.myco.com:443
    AP01blastExternalURLhttps://ap.myco.com:443
    AP01pcoipExternalURL10.20.30.40:4172
    AP02tunnelExternalURLhttps://ap.myco.com:443
    AP02blastExternalURLhttps://ap.myco.com:443
    AP02pcoipExternalURL10.20.30.40:4172

     

    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.

     

    Virtual IP AddressPrimary/SecondaryProtocolNameReal Servers
    192.168.0.100:443PrimaryTCPAPLB - HTTPS

    192.168.0.101:443

    192.168.0.102:443

    192.168.0.100:10143SecondaryTCPAP01 - HTTPS192.168.0.101:443
    192.168.0.100:10143SecondaryUDPAP01 - BLAST-UDP192.168.0.101:8443
    192.168.0.100:10172SecondaryTCPAP01 - PCOIP192.168.0.101:4172
    192.168.0.100:10172SecondaryUDPAP01 - PCOIP-UDP192.168.0.101:4172
    192.168.0.100:10243SecondaryTCPAP02 - HTTPS192.168.0.102:443
    192.168.0.100:10243SecondaryUDPAP02 - BLAST-UDP192.168.0.102:8443
    192.168.0.100:10272SecondaryTCPAP02 - PCOIP192.168.0.102:4172
    192.168.0.100:10272SecondaryUDPAP02 - PCOIP-UDP192.168.0.102:4172

     

    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 (ap.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.

     

     

    UAG ApplianceConfiguration ItemValue
    AP01tunnelExternalURLhttps://ap.myco.com:10143
    AP01blastExternalURLhttps://ap.myco.com:10143
    AP01pcoipExternalURL10.20.30.40:10172
    AP02tunnelExternalURLhttps://ap.myco.com:10243
    AP02blastExternalURLhttps://ap.myco.com:10243
    AP02pcoipExternalURL10.20.30.40:10272

     

    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.

     

     

    Virtual IP AddressPrimary/SecondaryProtocolNameReal Servers
    192.168.0.100:443PrimaryTCPAPLB - HTTPS

    192.168.0.101:443

    192.168.0.102:443

    192.168.0.101:443SecondaryTCPAP01 - HTTPS192.168.0.101:443
    192.168.0.101:8443SecondaryUDPAP01 - BLAST-UDP192.168.0.1081:443
    192.168.0.101:4172SecondaryTCPAP01 - PCOIP192.168.0.101:4172
    192.168.0.101:4172SecondaryUDPAP01 - PCOIP-UDP192.168.0.101:4172
    192.168.0.102:443SecondaryTCPAP02 - HTTPS192.168.0.102:443
    192.168.0.102:8443SecondaryUDPAP02 - BLAST-UDP192.168.0.102:8443
    192.168.0.102:4172SecondaryTCPAP02 - PCOIP192.168.0.102:4172
    192.168.0.102:4172SecondaryUDPAP02 - PCOIP-UDP192.168.0.102:4172

     

    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 (ap1.myco.com) and would be translated to 192.168.0.101.
    • the second UAG appliance public IP address is 10.20.30.42 (ap2.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.

     

     

    UAG ApplianceConfiguration ItemValue
    AP01tunnelExternalURLhttps://ap1.myco.com:443
    AP01blastExternalURLhttps://ap1.myco.com:443
    AP01pcoipExternalURL10.20.30.41:4172
    AP02tunnelExternalURLhttps://ap2.myco.com:443
    AP02blastExternalURLhttps://ap2.myco.com:443
    AP02pcoipExternalURL10.20.30.42:4172

     

    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://ap1.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.

     

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

     

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