A Unified Access Gateway appliance in the DMZ can be configured to point to a server or a load balancer that fronts a group of servers. Unified Access Gateway appliances work with standard third-party load balancing solutions that are configured for HTTPS.
If the Unified Access Gateway appliance points to a load balancer in front of servers, the selection of the server instance is dynamic. For example, the load balancer might make a selection based on availability and the load balancer's knowledge of the number of current sessions on each server instance. The server instances inside the corporate firewall usually have a load balancer to support internal access. With Unified Access Gateway, you can point the Unified Access Gateway appliance to this same load balancer that is often already being used.
You can alternatively have one or more Unified Access Gateway appliances point to an individual server instance. In both approaches, use a load balancer in front of two or more Unified Access Gateway appliances in the DMZ.
Horizon Protocols
- 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. The protocol uses XML structured messages over HTTPS. This protocol is sometimes known as the Horizon XML-API control protocol. In a load balanced environment as shown in the Multiple Unified Access Gateway Appliances Behind a Load Balancer figure, the load balancer routes this connection to one of the Unified Access Gateway appliances. The load balancer usually selects the appliance based first on availability, and then out of the available appliances, routes traffic based on the least number of current sessions. This configuration evenly distributes the traffic from different clients across the available set of Unified Access Gateway appliances.
- Secondary Horizon Protocols
After the Horizon Client establishes secure communication to one of the Unified Access Gateway 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 the following:
- 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, TCP 8443, UDP 443, and UDP 8443)
- PCoIP display protocol (TCP 4172, UDP 4172)
These secondary Horizon protocols must be routed to the same Unified Access Gateway appliance to which the primary Horizon protocol was routed. Unified Access Gateway can then authorize the secondary protocols based on the authenticated user session. An important security capability of Unified Access Gateway is that Unified Access Gateway only forwards traffic into the corporate data center if the traffic is on behalf of an authenticated user. If the secondary protocol is routed incorrectly to a different Unified Access Gateway appliance than the primary protocol appliance, users are not authorized and are dropped in the DMZ. The connection fails. Incorrectly routing the secondary protocols is a common problem, if the load balancer is not configured correctly.
Load Balancing Considerations for Content Gateway and Tunnel Proxy
- Configure the load balancers to Send Original HTTP Headers to avoid device connectivity problems. Content Gateway and Tunnel Proxy use information in the request's HTTP header to authenticate devices.
- The Per-App Tunnel component requires authentication of each client after a connection is established. Once connected, a session is created for the client and stored in memory. The same session is then used for each piece of client data so the data can be encrypted and decrypted using the same key. When designing a load balancing solution, the load balancer must be configured with IP/session-based persistence enabled. An alternative solution might be to use DNS round robin on the client side, which means the client can select a different server for each connection.
Health Monitoring
A load balancer monitors the health of each Unified Access Gateway appliance by periodically sending an HTTPS GET /favicon.ico request. For example, 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 Unified Access Gateway to know that it is "healthy". If it gets a response other than "HTTP/1.1 200 OK" response or does not get any response, it will mark the particular Unified Access Gateway 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.
Unified Access Gateway 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 Unified Access Gateway service is temporarily unavailable. This setting is often used prior to scheduled maintenance, planned reconfiguration or planned upgrade of an Unified Access Gateway 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 will not 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 Unified Access Gateway appliances in a strategy resulting in zero user downtime for the service.
