Using a Load Balancer or Reverse Proxy to Enable External Access to Omnissa Access

During Omnissa Access deployment, the Omnissa Access instance is set up inside the internal network. A load balancer or reverse proxy, such as Unified Access Gateway, NSX® Advanced Load Balancer™, Apache, or Nginx, is a required component of every Omnissa Access deployment and must be installed in the DMZ before you begin deployment.

The load balancer or reverse proxy provides the single point of entry needed to scale your environment over time, add instances for redundancy, and distribute traffic across your deployment. High availability requires a load balancer. Single-node deployments are not supported.

The following diagram shows the basic deployment architecture that you can use to enable external access.

Note: The same Omnissa Access FQDN is used for both internal and external access in this deployment.

Specify Omnissa Access FQDN during Deployment

During the deployment of the Omnissa Access appliance, you must use a single Omnissa Access FQDN and the port number. These values must point to the FQDN that you want end users to access.

The Omnissa Access machine always runs on port 443.

Load Balancer Settings to Configure

Load balancer settings to configure include enabling X-Forwarded-For headers and setting the load balancer time-out correctly. In addition, SSL trust must be configured between the Omnissa Access machine and the load balancer.

• X-Forwarded-For Headers

  You must enable X-Forwarded-For headers on your load balancer. This determines the authentication method. See the documentation provided by your load balancer vendor for more information.

  Note: For NGINX, Omnissa recommends Forward the real client IP (X-Forwarded-For and X-Real-IP).

• Load Balancer Timeout

  For Omnissa Access to function correctly, you might need to increase the load balancer request timeout from the default. The value is set in minutes. If the timeout setting is too low, you might see this error, “502 error: The service is unavailable”.

• Do not block session cookies

  Do not block session cookies by adding rules to the load balancer. Adding such rules to the load balancer can result in inconsistent behavior and failed requests.

• Session Persistence

  Session persistence (sticky sessions) is required on the load balancer for Omnissa Access. Omnissa recommends enabling HTTP cookie persistence.

  Note: A common symptom related to this in the admin UI is: User is not authorized to perform this task. Confirm that the load balancer has session persistence enabled.

• WebSocket support

  The load balancer must have WebSocket support to enable secure communication channels between connector instances and the Omnissa Access Nodes.

  For your deployment, if Workspace ONE Hub Services is integrated, WebSocket support is required for Hub Services notifications. Therefore, Web Socket support must be provided for end user browsers and devices.

  Note: For NGINX, Omnissa recommends HTTP/1.1 with Upgrade and Connection "upgrade".

• Ciphers with forward secrecy

  Apple iOS App Transport Security (ATS) requirements apply to the Workspace ONE app on iOS. To enable users to use the Workspace ONE app on iOS, the load balancer must use ciphers that provide forward secrecy. The following cipher suites meet this requirement:

  • ECDHE_ECDSA_AES and ECDHE_RSA_AES in GCM mode (AES-GCM with SHA-256/384)
  • Any TLS 1.3 cipher suite (all TLS 1.3 suites provide forward secrecy by design)

  As stated in Apple's Platform Security documentation:

  "By default, App Transport Security limits cipher selection to include only suites that provide forward secrecy, specifically: ECDHE_ECDSA_AES and ECDHE_RSA_AES in Galois/Counter Mode (GCM)... Servers must support TLS 1.2 and forward secrecy, and certificates must be valid and signed using SHA-256 or stronger with a minimum 2048-bit RSA key or 256-bit elliptic curve key."

• Certificate-based authentication

  Certificate authentication has the following configuration requirements for the load balancer:

  • Port: 17443
  • Protocol: TCP
  • OSI: Layer 4
  • SSL: Passthrough

• Apple Mobile Single Sign-On (SSO)

  Apple Mobile SSO has the following configuration requirements for the load balancer:

  • Port: 17443
  • Protocol: TCP
  • OSI: Layer 4
  • SSL: Passthrough

• Android Mobile Single Sign-On (SSO)

  Android Mobile SSO has the following configuration requirements for the load balancer:

  • Port: 15262
  • Protocol: TCP
  • OSI: Layer 4
  • SSL: Passthrough
  • Proxy protocol: Enabled and Layer 4

  
  Note: Refer to Load Balancer Requirements to Use the Cert Proxy Service for additional considerations.