Deploying Unified Access Gateway: Workspace ONE Operational Tutorial

Overview

Omnissa provides this operational tutorial to help you with your  Workspace ONE® and Horizon® environment.

A successful deployment of Unified Access Gateway™ is dependent on good planning and a robust understanding of the platform. This tutorial gives you a technical overview to get you started with Unified Access Gateway (UAG) deployment. It covers key points for those deploying Unified Access Gateway appliances for the first time. In addition, the tutorial provides detailed step-by-step guidance on how to deploy Unified Access Gateway with single or multiple NICs on:

• vSphere using vSphere Web Client (GUI-based).
• vSphere using PowerShell.
• Amazon Web Service using PowerShell.
• Microsoft Azure using PowerShell.
• Google Cloud using PowerShell.

What is Unified Access Gateway?

Unified Access Gateway is a security platform that provides edge services and access to defined resources that reside in the internal network. It acts as the security gateway for Workspace ONE and Horizon deployments, enabling secure remote access from an external network to a variety of internal resources. Unified Access Gateway supports multiple use cases:

• Per-App Tunnelling of native and web apps on mobile and desktop platforms to secure access to internal resources through the Tunnel service.
• Secure on-premises email infrastructure that grants access only to authorized devices, users, and email applications based on managed policies. This capability leverages the Secure Email Gateway service integrated with  Workspace ONE® UEM.
• Access from Workspace ONE® Content to internal file shares or SharePoint repositories by running the Content Gateway service.
• Reverse proxying of web applications.
• Identity bridging for authentication to on-premises legacy applications that use Kerberos or header-based authentication.
• Secure external access to desktops and applications on Horizon® Cloud Service™ on Microsoft Azure, and Horizon® 8 on-premises.

When providing access to internal resources, Unified Access Gateway can be deployed within the corporate DMZ or internal network, and act as a proxy host for connections to your company’s resources. Unified Access Gateway directs authenticated requests to the appropriate resource and discards any unauthenticated requests, it also can perform the authentication itself, leveraging additional authentication when enabled.

Audience

This operational tutorial is intended for IT professionals and Workspace ONE UEM administrators of existing production environments.

Knowledge of additional technologies such as network, VPN configuration, Workspace ONE® Intelligence, and Workspace ONE UEM is also helpful.

Getting Started

Unified Access Gateway can be deployed across multiple hypervisors, hosted on-premises, or in the cloud using multiple deployment methods.

This chapter provides a technical overview of the core components of Unified Access Gateway, platforms supported, security, networking configuration, and deployment methods in addition to key guidance for a successful deployment.

Supported Platforms

Unified Access Gateway is packaged as an OVA and can be deployed on the following platforms.

• VMware vSphere ESXi host with a vCenter Server
• Microsoft Hyper-V
  • Supports only Tunnel, Content Gateway, and Secure Email Gateway edge services.
• Amazon AWS EC2
• Microsoft Azure
• Google Cloud Platform

Unified Access Gateway FIPS Support

For vSphere, two versions of the Unified Access Gateway OVA are available: standard OVA (non-FIPS) and a FIPS version of the OVA.

• FIPS version supports only Horizon (pass-through auth only) and Workspace ONE Tunnel (Per-App) edge services.

When deploying Unified Access Gateway FIPS version:

• All Unified Access Gateway unsupported features are greyed out on the administration console.
• The whole Horizon environment (Connection Server, Agents, and so on) must also be FIPS.

If you need to enable Horizon Smart Card/CAC for Horizon access through Unified Access Gateway in FIPS mode, you must enable Horizon Smart Card/CAC authentication on the Connection Server.

Important: The FIPS 140-2 version runs with the FIPS-certified set of ciphers and hashes and has restrictive services enabled that support FIPS-certified libraries. When Unified Access Gateway is deployed in FIPS mode, the appliance cannot be changed to the standard OVA deployment mode. The Horizon Edge authentication is not available in the FIPS version.

Certificates

TLS/SSL is required for client connections to Unified Access Gateway appliances. Client-facing Unified Access Gateway appliances and intermediate servers that terminate TLS/SSL connections require TLS/SSL server certificates.

TLS/SSL server certificates are signed by a Certificate Authority (CA). A CA is a trusted entity that guarantees the identity of the certificate and its creator. When a certificate is signed by a trusted CA, users no longer receive messages asking them to verify the certificate, and thin clients, desktops, and mobile devices can connect without requiring additional configuration.

Certificates imported into Unified Access Gateway are assigned on an individual basis for each service, such as:

• Management service interface used by Administration console
• Horizon and Web Reverse Proxy, which runs based on esmanager service
• Tunnel used by Per-App Tunnel
• Content Gateway
• Secure Email Gateway

TLS/SSL server certificates can be imported and assigned to the Admin interface and Internet Interface using the administration console. If you do not import the certificates during deployment, a self-signed TLS/SSL server certificate is generated.

• Certificates assigned to the Admin interface apply to the administration console running on port 9443.
• Certificates assigned to the Internet interface apply to ESManager (Horizon and Web Reverse Proxy) only on port 443.
• Certificates for Content Gateway, Tunnel, and Secure Email Gateway must be configured on Workspace ONE UEM Console - they are pulled into Unified Access Gateway during each service initialization based on the port each service was assigned.

For production environments, we recommend that you replace the default certificate as soon as possible or configure a trusted certificate during the deployment. The default certificate is not signed by a trusted CA. Use the default certificate only in a non-production environment.

Security Protocols and Cipher Suites

Security protocols and cipher suites are configured on a per-service basis on Unified Access Gateway. Administrators can update the security protocols and cipher suites any time after deployment using the Unified Access Gateway administration console or REST API.

NOTE: We have tested all the edge services with the respective ciphers using different endpoints, browsers, and mail clients. Deactivating any other cipher might affect client behavior. The TLS or cipher suites mentioned in this chapter, take into consideration the Unified Access Gateway 3.9 as a reference, which can be different for prior versions.

Horizon and Web Reverse Proxy Edge Service (esmanager)

ESmanager is the service responsible for hosting Horizon and Web Reverse Proxy services, when configuring the security protocols and cipher suites on the Unified Access Gateway administration console or General section in PowerShell, those apply to esmanager on port 443 only.

By default, on Unified Access Gateway 3.9 the TLS v1.2 is enabled. TLS v1.0, TLS v1.1, and SSL v3.0 are deactivated.

TLS v1.3 is available on Unified Access Gateway 3.10 and later, and enabled by default.

Security protocols and cipher suites can be configured using:

• PowerShell INI file settings, under General Section.
• Unified Access Gateway administration console, under System Configuration.

Default Cipher Suites for Unified Access Gateway NON-FIPS version:

• TLS 1.2
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS 1.3
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256

Default Cipher Suites for Unified Access Gateway FIPS version:

• TLS 1.2
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • ​TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Note: Update the security protocols and cipher suites for Blast (8443 port) and PCoIP (4172 port) when not running on port 443 is not supported on Unified Access Gateway, they both have TLS 1.1 and 1.2 enabled by default on Unified Access Gateway 3.9 and below. On Unified Access Gateway 3.10 and above Blast (8443 port) no longer uses TLS 1.1, it supports TLS 1.2 only.

Tunnel Edge Service

By default, only TLS v1.2 is enabled for Tunnel, Per-App Tunnel component.

Default Cipher Suites for Tunnel edge Service TLS handshake between service and device.

• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256

Default Cipher Suites for Workspace ONE Tunnel edge service DTLS handshake between service and device.

• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA
• ECDHE-RSA-AES256-GCM-SHA
• ECDHE-ECDSA-AES128-GCM-SHA
• ECDHE-RSA-AES128-GCM-SHA
• ECDHE-ECDSA-AES256-SHA
• ECDHE-RSA-AES256-SHA

Cipher suites can be configured through Workspace ONE UEM console, under Security / Tunnel using Custom Settings configuration - Workspace ONE UEM 2003 and Unified Access Gateway 3.9 are required.

As an example, to update encryption algorithms use the following Custom Setting:

• Key: openssl_cipher_list
• Type: String
• Value: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256

Note: For Tunnel Proxy, TLS v1.2 is enabled. TLSv1 and TLSv1.1 are deactivated. Tunnel Proxy component is obsolete and for those use cases, it's recommended to migrate to Per-App Tunnel.

If you still need to update security protocols and cipher suites for Tunnel Proxy, that must be configured through command line on the Unified Access Gateway appliance, updating the following parameters on the /opt/omnissa/tunnel/proxy/service/proxy-conf/proxyServiceWrapper.conf file.

-Djdk.tls.disabledAlgorithms=RC4

-Djdk.tls.disabledAlgorithms=RC4\,SSLv2Hello\,SSLv3\,TLSv1\,TLSv1.1

Content Gateway Edge Service

By default, for Content Gateway TLS v1.2 and TLS v1.1 are enabled. TLSv1 is deactivated.

Default Cipher Suites for Content Gateway edge service.

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA

Security protocols and cipher suites can be configured through Workspace ONE UEM console, under Content Gateway using Custom Settings configuration - Workspace ONE UEM 2003 and Unified Access Gateway 3.9 are required.

As an example, to only enable TLS 1.2  when using Unified Access Gateway 3.9 use the following Custom Setting to inform the algorithms to be deactivated:

• Key: extconf##serviceWrapper##UPDATE##wrapper.java.additional.6=-Djdk.tls.disabledAlgorithms=RC4
• Type: String
• Value: wrapper.java.additional.6=-Djdk.tls.disabledAlgorithms=RC4\,SSLv2Hello\,SSLv3\,TLSv1\,TLSv1.1

When using Unified Access Gateway 3.10, use the following custom setting to inform what algorithms would be used by the service:

• Key: aw.http.protocols
• Type: String
• Value: TLSv1.2

Secure Email Gateway Edge Service

By default, only TLS v1.2 and TLS v1.1 are enabled for Secure Email Gateway.

Secure Email Gateway edge service uses the cipher suites defined on the JRE. You can see the full list here under Default Enable Cipher Suites for JDK 8. Secure Email Gateway also deactivates the following algorithms as described below.

Security protocols and cipher suites for Secure Email Gateway must be configured through command line on the Unified Access Gateway appliance, updating the following parameters on the /opt/omnissa/docker/seg/container/config/seg-jvm-args.conf file.

-Djdk.tls.disabledAlgorithms="MD5, RC4, TLSv1, TLSv1.1, SSLv2Hello, SSLv3, DSA, DESede, DES,

3DES, DES40_CBC, RC4_40, MD5withRSA, DH, 3DES_EDE_CBC, DHE, DH keySize < 1024, EC keySize < 224"

 

-Dhttps.protocols=TLSv1.2

Network Considerations

Understanding your DMZ network design and how traffic is routed is important when deploying Unified Access Gateway, and will define several settings that are required for the deployment.

Unified Access Gateway requires DNS configuration for the appliance, netmask, default gateway, and subnet to be defined, for each network that is enabled during deployment.

DNS Configuration

Up to two DNS can be configured with the Unified Access Gateway appliance, DNS can be configured during deployment and updated later using the administration console.

The edge services will leverage the DNS configured on the appliance to resolve internal resource names, for example:

• Web Reverse Proxy will resolve the name of the internal website.
• Horizon will resolve the Connection Server name.
• Tunnel in basic mode configuration will resolve the name of the internal website and application.

When using Tunnel in cascade mode, the UAG frontend appliance will resolve only the name of the UAG backend, the resolution of internal resources required by the end-user will be performed by the DNS configured on the backend UAG.

Use of .local hostnames

Do not use .local for hostnames, as this is reserved for Multicast DNS (mDNS), and resolve requests for names ending in .local will not be sent to normal (Unicast) DNS. Earlier versions of Unified Access Gateway, based on Photon 2, did allow .local names to be resolved, but this has been rectified in Unified Access Gateway 3.7 and later.

If hosts in the environment have been named with a .local suffix, then there are three workarounds until you can move away from the reserved suffix .local.

1. Use an IP address in place of hostname references in settings such as ntpServers, proxydestinationUrl, etc.
2. Add the host entry for the .local host in the Unified Access Gateway hosts file using the administration console or PowerShell .ini file settings. Never edit /etc/hosts file directly.
   1. On Unified Access Gateway, local host file entries are searched before performing a DNS search. Such a search ensures that if the host name is present on the hosts file, then the .local names can be used and a DNS search is not required at all.
3. Add an alias CNAME record in DNS to give an alternative name for any .local host.
   1. For example, for the myinternalserver.local DNS entry, use myinternalserver.internal as a CNAME and then use the .int name for any hostname references on the Unified Access Gateway.

After deployment, you can validate the DNS server IP addresses that have been configured on Unified Access Gateway using the administration console under Network Settings or using the following command.

systemd-resolve --status

Make sure that the Unified Access Gateway can ping each DNS server IP address:

ping <DNS Server IP Address>

To validate how hostnames are getting resolved by the DNS on Unified Access Gateway, use the following command:

nslookup <hostname>

NOTE: When using tcpdump, the output with nslookup on Unified Access Gateway 3.7 and newer, will show DNS queries going to 127.0.0.53 UDP port 53. This is the local DNS listener systemd-resolv which then forwards the DNS query to the configured DNS servers as shown with systemd-resolve --status

Network Segmentation Options

Unified Access Gateway supports deployments with one, two, or three NICs. This means that the server can be partitioned to receive traffic on a single interface or to route traffic to different interfaces, based on the source of the request. Most often, if you need to implement multiple NICs, you already follow this standard with other web applications in your organization.

You must determine what is appropriate for your environment when selecting the number of NICs during installation. You need to understand the expected behavior when two or three NICs are enabled.

Keep in mind that based on the number of NICs, Unified Access Gateway will require a netmask, default gateway, and subnet to be defined for each network that is enabled during deployment.

Single-Nic Deployment

In a single-NIC deployment, all traffic (Internet, backend, and management) uses the same network interface. Authorized traffic is then forwarded by Unified Access Gateway through the inner firewall to resources on the internal network using the same NIC. Unauthorized traffic is discarded by Unified Access Gateway.

Two-NIC Deployment

A two-NIC deployment separates the Internet traffic onto its own NIC, while the management and backend network data still share a NIC. The first NIC is still used for Internet-facing unauthenticated access, but the backend authenticated traffic and management traffic are separated onto a different network. This type of deployment is suitable for production environments.

In this two-NIC deployment, traffic going to the internal network through the inner firewall must be authorized by Unified Access Gateway. Any unauthorized traffic is not allowed on this backend network. Management traffic such as the REST API for Unified Access Gateway uses only this second network.

If a device on the unauthenticated front-end network is compromised—for example, if a load balancer were compromised—then reconfiguring that device to bypass Unified Access Gateway would still not be possible in this two-NIC deployment. It combines layer 4 firewall rules with layer 7 Unified Access Gateway security.

Similarly, if the Internet-facing firewall is misconfigured to allow TCP port 9443 through, the Unified Access Gateway Management REST API would still not be exposed to Internet users. A defense-in-depth principle uses multiple levels of protection, such as knowing that a single configuration mistake or system attack will not necessarily create an overall vulnerability.

In a two-NIC deployment, it is common to put additional infrastructure systems such as DNS servers, RSA SecurID Authentication Manager servers, and so on in the backend network within the DMZ so that they are not visible from the Internet-facing network. This guards against layer-2 attacks from a compromised front-end system on the Internet-facing LAN and thereby effectively reduces the overall attack surface.

When the Horizon service is enabled on Unified Access Gateway, most network traffic is the display protocol traffic for Blast Extreme and PCoIP. With a single NIC, display protocol traffic to or from the Internet is combined with traffic to or from the backend systems. When two or more NICs are used, the traffic is spread across front-end and backend NICs and networks. This can result in performance benefits by reducing the potential bottleneck of a single NIC.

Three-NIC Deployment

A three-NIC deployment separates the Internet traffic onto its own NIC and separates management and backend network data onto dedicated networks. HTTPS management traffic to port 9443 is then only possible from the management LAN. This type of deployment is suitable for production environments.

Two sections are provided to explore these options. As a first step toward understanding basic deployments, you can install Unified Access Gateway with one NIC using vSphere Client, described in  Deploying Unified Access Gateway in vSphere with One NIC Through vSphere. You can then advance to the next step and install Unified Access Gateway with two NICs as a production environment using PowerShell, described in  Deploying Unified Access Gateway in vSphere with Two NICs Through PowerShell.

Default Gateway and Static Routes

By design you can set a default gateway on Unified Access Gateway, however, you may need to route traffic to different subnets that are not possible through the current default gateway.

Unified Access Gateway supports static routes, allowing the administrator to route traffic to a specific subnet using a different gateway. The list of static routes is defined for each NIC.

The following diagram shows an example where incoming traffic uses the INTERNET gateway (default gateway) and to access the internal resources, traffic must be forwarded to the INTERNAL gateway. For that reason, a static route on NIC 1 was defined below, where traffic into the internal subnets will be routed to the internal gateway (172.16.71.1).

routes1=172.16.76.0/22 172.16.71.1,10.0.0.0/16 172.16.71.1,10.0.1.0/16 172.16.71.1

Routes can be defined during deployment using PowerShell, adding under the General section the routes# parameter for the respective nic (# network interface - 1, 2, 3) or through the administration console under Network Settings.

Deployment Methods

A PowerShell script can be used to deploy Unified Access Gateway and configure all edge services across all platforms. You download the ZIP file, configure the PowerShell script for your environment, and run the script to deploy Unified Access Gateway. This method allows administrators to automate the deployment and configuration, making the appliance ready on first boot.

PowerShell is the only available method for Unified Access Gateway deployment on Microsoft Azure, Hyper-V, and Amazon AWS EC2.

For Unified Access Gateway deployment on vSphere, the following methods are supported:

• vSphere Web Client OVF Template Wizard
• Unified Access Gateway Deployment Utility
• PowerShell

The vSphere Web Client can be used to deploy the Unified Access Gateway OVA. You are prompted for basic settings, including the NIC deployment configuration, IP address, and management interface passwords. After the OVA is deployed, log in to the Unified Access Gateway admin user interface to configure Unified Access Gateway system settings, edge services in multiple use cases, and authentication in the DMZ. The configuration performed after deployment can be exported as a JSON file and used to reimport later on new appliances.

Unified Access Gateway OVA and PowerShell Files

To deploy Unified Access Gateway appliance, download the following:

• Latest Unified Access Gateway virtual appliance image OVA file (including PowerShell Script) from my.workspaceone.com for the platform you plan to deploy.
• Download the  VMware OVF Tool 4.3 or later and install it on the same machine that will be used to run the Unified Access Gateway PowerShell deployment script. Required only for Unified Access Gateway deployment on vSphere.
• Hypervisor credentials with permission to create VMs, credentials will be used to deploy the appliance.

See the  Product Interoperability Matrices to determine the compatibility of Unified Access Gateway with other VM products.

Deploying Unified Access Gateway on vSphere with One NIC through vSphere Web Client

This section guides you through the GUI-based deployment and configuration of the Unified Access Gateway appliance on vSphere using the VMware vSphere Web Client.

These exercises provide instructions for deploying a Unified Access Gateway appliance in vSphere using a single Network Interface Card (NIC) deployment. The Unified Access Gateway administration console is used to configure the certificates and change network settings.

These exercises cover Unified Access Gateway 3.3.1+ deployment in vSphere 6.5 U1.

The purpose is to provide a basic deployment option for exploration or proof of concept, to demonstrate available tools in the administration console, and to describe the components that support the features and services. If you want a more advanced deployment with two or more NICs in a production environment, see  Deploying Unified Access Gateway on vSphere with Two NICs Through PowerShell.

Architecture

The architectural diagram below shows an example environment that emulates a typical environment, including DMZ and internal networks.

In this example, external requests to the vApp are sent to the vPod Router, which directs those requests to the appropriate resource, based on the incoming port. Ports 4000-6500 are reserved for the environment components so all traffic coming in on these ports is forwarded to the appropriate Edge Service for the Unified Access Gateway appliance. In addition, ports 443 and 9443 are forwarded to the Unified Access Gateway appliance over the respective ports.

The vApp networks (internal, DMZ, and transit) are created within the vApp. The internal and transit networks are NATed to the SE-UCS-Network for outbound internet connectivity while the DMZ network routes through the vPod Router for inbound and outbound access. Note that the vPodRouter does not have a NIC on the internal network and thus cannot route external traffic to resources on the internal network.

vPod Router | ESXi01 6.5.0 U1 | Control Center | vCenter Server 6.5 U1 hosted on ESXi01

Unified Access Gateway on vSphere with Two NICs through PowerShell Architecture

The following architectural diagram shows an example of two major networks that you can deploy your appliances into. For this set of exercises, you deploy the Unified Access Gateway appliance on a DMZ and assign the respective NICs.

At the top of the diagram is vCenter Networking. At the bottom of the diagram is the vApp network required to support the environment. For these exercises, the focus is on the network hosted on the ESXi, and represented by the following three networks:

• VM Network & Management: Represents the dedicated network to access the Management Console
• Internal Network: Represents the internal network on 172.16.0.x range. The Control Center, ESXI, and vCenter are part of the internal network.
• DMZ Network: Represents the DMZ network on 192.168.110.x which is where the Unified Access Gateway appliance is to be deployed. The Unified Access Gateway Internet-facing NIC is associated with this network.

Network Interfaces

Unified Access Gateway supports deployments with one, two, or three NICs. This means that the appliance can be partitioned to receive traffic on a single interface or to route traffic to different interfaces, based on the source of the request. Most often, if you need to implement multiple NICs, you already follow this standard with other web applications in your organization.

You must determine what is appropriate for your environment when selecting the number of NICs during installation. You need to understand the expected behavior when two or three NICs are enabled.

Two sections are provided to explore these options. As a first step toward understanding basic deployments, you can install Unified Access Gateway with one NIC using vSphere Client, described in  Deploying Unified Access Gateway on vSphere with One NIC Through vSphere Web Client. You can then advance to the next step and install Unified Access Gateway with two NICs as a production environment using PowerShell, described in Deploying Unified Access Gateway on vSphere with Two NICs Through PowerShell.

General Considerations

In the exercises for deploying the Unified Access Gateway appliance through vSphere, the vCenter setup is hosted in a nested template. This is not usually the case when working with users in a live environment.

User environments can include multiple networks and can optionally have a Network Protocol Profiles (NPP) that corresponds to the networks to connect to the Unified Access Gateway. Prior to version 3.3, NPP was a requirement. Since version 3.3, NPP is no longer required.

Note: Keep in mind that the Unified Access Gateway requires a netmask, default gateway, and subnet to be defined for each network enabled during deployment.

Prerequisites

Before you can perform the exercises to deploy Unified Access Gateway using vSphere Web Client, you must satisfy the following requirements:

• Latest Unified Access Gateway virtual appliance image OVA file for vSphere from  my.workspaceone.com, such as .euc-access-point-3.9.X.X-XXXXXXXXXXX.ova.
• Set up a VMware vSphere ESXi host with a vCenter Server
• Set up a vSphere data store and the network to use
• vCenter credentials with permission to create VMs, the credentials will be used to deploy the appliance.

See the Product Interoperability Matrices to determine the compatibility of Unified Access Gateway with other VM products.

Note: Starting with Unified Access Gateway 3.3, you can deploy Unified Access Gateway without specifying the netmask and default gateway settings in Network Protocol Profiles (NPP). You can specify this networking information directly during the deployment of your Unified Access Gateway appliance.

Note: To perform most of the exercises, you must log in to the vSphere Web Client.

Deploying Unified Access Gateway with vSphere

In this section, you explore the vSphere Admin UI and learn how to deploy an OVF Template by configuring the necessary fields for the Unified Access Gateway. You deploy the Unified Access Gateway in a one-NIC configuration, meaning that the Internet-facing, internal-facing, and management networks all reside on a single NIC.

Deploying the OVF Template

1. Click the VMs and Templates button.
2. Right-click the vSphere appliance, such as vc.corp.local.
3. Click Deploy OVF Template...

Uploading OVF Template

1. Select Local File.
2. Click Browse.
3. Click Desktop.
4. Click UAG Resources.
5. Click UAG Files.
6. Select the euc-unified-access-gateway-3.3.#.#-#####.ovf file.
7. Click Open.
8. Click Next.
9. Select Nested_Datacenter.
10. Click Next.
11. Select Host_Cluster.
12. Click Next.
13. Review the details here. These items are updated as you complete the OVF Template wizard.
14. Click Next.

Select Configuration

1. Select Single NIC.
2. Click Next.

Note: The drop-down menu provides a short description of each configuration and sizing of the Unified Access Gateway VM.

• Single NIC: In this exercise, the Single NIC configuration means that all traffic to the Unified Access Gateway is received on the same interface regardless of the source, and the Admin UI runs on the same NIC over port 9443.
• Two NICs: Directs traffic from external networks to the public interface, and traffic from within the network to an internal interface. The Admin UI runs on the same internal interface.
• Three NICs: Directs traffic from external networks to the public interface, and traffic from within the network to an internal interface. In this configuration, the Admin UI runs on a separate, dedicated Network Interface. When selecting multiple NICs, you must then configure the corresponding network values for each NIC in the Setup Networks and Customize Template sections later in the wizard.

Users who require multiple NICs typically follow this same protocol for other web application servers within their organization. For more information on deploying the Unified Access Gateway with multiple NICs, see Deploying and Configuring Unified Access Gateway.

Select Storage and Networks

1. Select Thin provision.
2. Select a datastore, such as datastore2_ESXi01.
3. Select Next.
4. For this appliance, select the destination of each source, such as DMZ_VM_DPortGroup in this example.
   Note: A single-NIC configuration was selected, meaning the Internet, management, and backend traffic all go through one NIC. However, this step of the wizard asks for three destination networks, which leads to some confusion when you are configuring the Unified Access Gateway for the first time. Since this is a single-NIC deployment, select the same network for all the source network.
5. Click Next.

Customize Template

Scroll through the Customize Template and provide the information required.

1. Uncheck the Join CEIP check box.
2. Click the Networking Properties down arrow.
3. Scroll down.
4. Enter the DNS server addresses, such as 192.168.110.10 in this example.
5. Enter the IPMode, such as STATICV4 in this example.
6. Enter the Default Gateway address, such as 192.168.110.1 in this example.
7. Enter the NIC 1 (eth0) IPv4 address, such as 192.168.110.20 in this example.
8. Scroll down.
9. Enter the NIC1 (eth0) IPv4 netmask, such as 255.255.255.0 in this example.
10. Enter the Unified Gateway Appliance Name, such as UAG01.
11. Click Password Options.
12. Scroll down.
13. Enter the admin user, which enabled REST API access.
14. Reenter to confirm the password.
15. Enter the root user password of the Unified Access Gateway VM.
16. Reenter to confirm the password.
17. Click Next.
18. Review all the settings entered in the Network Mapping and Properties windows to ensure there are no errors.
19. Click Finish.

Monitoring OVF Import and Deployment

You can follow the status of the OVF deployment through the task console.

1. Click the Home icon.
2. Click Tasks.
3. Wait until the Deploy OVF package and Deploy OVF Template complete.
4. Click Back.

If your Import OVF package task fails with the error saying, "Failed to deploy OVF package" on the Tasks Console, restart the deployment by returning to step  Deploying the OVF Template.

Power On Unified Access Gateway Appliance

1. Select the virtual machine, such as euc-unified-access-gateway-xxxx in this example.
2. Click the Power on icon.
3. Click the Refresh icon.
4. The UAG VM Screen turns blue as soon the initialization finishes.
5. Wait until an IP address is assigned to this VM, such as 192.168.110.20 in this example.

Warning: Do not continue to the next step until the VM receives the associated IP address!  This can take one or two minutes.

Configuring TLS/SSL Certificates

Navigate to Unified Access Gateway administration console

1. Click the New Tab button.
2. Enter the URL, such as https://192.168.110.20:9443/admin for this example, and press Enter.
3. Click the Advanced link.
4. Accept the security exception and click the Proceed to 192.168.110.20 (unsafe) link.

Log in and Select Manual Configuration

On Unified Access Gateway console:

1. Enter the username, such as admin in this example.
2. Enter the password created for the Admin API in the Deploy OVF Wizard.
3. Click Login.

A successful login redirects you to the window where you can import settings or manually configure the Unified Access Gateway appliance.

Under Configure Manually, click Select.

Configure TLS/SSL Certificates

TLS/SSL is required for client connections to Unified Access Gateway appliances. Client-facing Unified Access Gateway appliances and intermediate servers that terminate TLS/SSL connections require TLS/SSL server certificates.

A detailed explanation about Certificates is available under the Getting Started chapter, it's assumed you read that first.

Under Advanced Settings, click the gear icon for TLS Server Certificate Settings.

1. Select the gear icon for TLS Server Certificate Settings under Advanced Settings.
2. Check Internet interface.
3. Check Admin interface.
4. Select PFX as Certificate Type.

Certificates that you import into the Unified Access Gateway appliance must be trusted by client machines and must also apply to all instances of Unified Access Gateway and any load balancer, either by using wildcards or by using Subject Alternative Name (SAN) certificates.

NOTE: The certificate assigned to the Internet interface applies only to Horizon and Web Reverse Proxy Edge Service. The certificates for the Content Gateway, Tunnel, and Secure Email Gateway Edge Services must be configured through the Workspace ONE UEM Console.

Click Select to upload the certificate in PFX format.

1. Navigate to the PFX Certificate, as in this example in Microsoft Explorer:
   1. Click Local Disk (C:).
   2. Click AW Tools.
   3. Click the PFX certificate file, such as airwlab.com.pfx.
2. Click Open.
3. Enter the certificate password.
4. Click Save.

You receive a message stating that the Internet-facing interface certificate has changed. You must reload the administration console to see the changes you made.

5. Click the Close button on the Unified Access Gateway administration console browser tab.
6. Click the New Tab button.
7. Browse to your Unified Access Gateway URL, such as https://uagmgt-dmz.airwlab.com:9443/admin in this example, or click a bookmark if you created one.

You should no longer see a certificate error on the Browser navigation bar.

Updating Network Settings

You can now log in to the Unified Access Gateway administration console and update the network settings so that the Unified Access Gateway is deployed on a different IP than originally.

Log in to the Unified Access Gateway administration console (such as https://uag.airwlab.com:9443/admin).

1. Enter the username, such as admin in this example.
2. Enter the password.
3. Click Login.
4. Under Configure Manually, click Select.
5. Under Advanced Settings, click the gear icon for Network Settings.

Edit and Change Network Settings

1. Click the down arrow for NIC 1, the Internet-facing interface.
2. View the configuration detail displayed about NIC 1.
3. Click the gear icon for NIC 1 to update the IP address.

The Unified Access Gateway administration console allows you to update the IPv4 address and IP allocation mode associated to NIC 1.

1. In the IPv4 Address field, enter the new IP address (such as 192.168.110.21 in this example) to update it.
2. Click Save.

Validate Network Changes

After saving, a message appears: NIC1 configuration in progress. This means that the Unified Access Gateway is updating the NIC with the new IP address, and restarting the NIC. Users lose connectivity with the administration console and this message disappears when the configuration is finished.

After the configuration completes, click Close.

The page automatically reloads on the new IP address you configured for your Unified Access Gateway. You can also enter the new IP manually to navigate to the Unified Access Gateway administration console.

1. Enter the URL to access the Unified Access Gateway administration console, based on the new IP address, such as https://192.168.110.21:9443/admin in this example.
2. Enter the username, such as admin in this example.
3. Enter the password.
4. Click Login.

You now have access to the Unified Access Gateway administration console using the new IP address.

Deploying Unified Access Gateway on vSphere with Two NICs through PowerShell

This section guides you through the configuration and deployment of the Unified Access Gateway appliance using a PowerShell script. The exercises also describe how to set up a reverse proxy to access internal websites through the Unified Access Gateway administration console.

In these exercises, the Unified Access Gateway appliance is deployed with two NICs. One NIC faces the Internet, and the second one is dedicated to management and backend access.

These exercises cover Unified Access Gateway 3.3.1 deployment in vSphere 6.5 U1.

The purpose is to provide a deployment option for an environment that could be used for production. If you want a more basic deployment with a single NIC for proof of concept, see  Deploying Unified Access Gateway with One NIC through vSphere.

Architecture

The architectural diagram below shows an example environment that emulates a typical environment, including DMZ and internal networks.

In this example, external requests to the vApp are sent to the vPod Router, which directs those requests to the appropriate resource, based on the incoming port. Ports 4000-6500 are reserved for the environment components so all traffic coming in on these ports is forwarded to the appropriate Edge Service for the Unified Access Gateway appliance. In addition, ports 443 and 9443 are forwarded to the Unified Access Gateway appliance over the respective ports.

The vApp networks (internal, DMZ, and transit) are created within the vApp. The internal and transit networks are NATed to the SE-UCS-Network for outbound internet connectivity while the DMZ network routes through the vPod Router for inbound and outbound access. Note that the vPodRouter does not have a NIC on the internal network and thus cannot route external traffic to resources on the internal network.

vPod Router | ESXi01 6.5.0 U1 | Control Center | vCenter Server 6.5 U1 hosted on ESXi01

Unified Access Gateway on vSphere with Two NICs Through PowerShell Architecture

The following architectural diagram shows an example of two major networks that you can deploy your appliances into. For this set of exercises, you deploy the Unified Access Gateway appliance on a DMZ and assign the respective NICs.

At the top of the diagram is vCenter Networking. At the bottom of the diagram is the vApp network required to support the environment. For these exercises, the focus is on the network hosted on the ESXi, and represented by the following three networks:

• VM Network & Management: Represents the dedicated network to access the Management Console
• Internal Network: Represents the internal network on 172.16.0.x range. The Control Center, ESXI, and vCenter are part of the internal network.
• DMZ Network: Represents the DMZ network on 192.168.110.x which is where the Unified Access Gateway appliance is to be deployed. The Unified Access Gateway Internet-facing NIC is associated to this network.

Network Interfaces

Unified Access Gateway supports deployments with one, two, or three NICs. This means that the appliance can be partitioned to receive traffic on a single interface or to route traffic to different interfaces, based on the source of the request. Most often, if you need to implement multiple NICs, you already follow this standard with other web applications in your organization.

You must determine what is appropriate for your environment when selecting the number of NICs during installation. You need to understand the expected behavior when two or three NICs are enabled.

Two sections are provided to explore these options. As a first step toward understanding basic deployments, you can install Unified Access Gateway with one NIC using vSphere Client, as described in  Deploying Unified Access Gateway on vSphere with One NIC Through vSphere Web Client. You can then advance to the next step and install Unified Access Gateway with two NICs as a production environment using PowerShell, as described in Deploying Unified Access Gateway on vSphere with Two NICs Through PowerShell.

General Considerations

In the exercises for deploying the Unified Access Gateway appliance through vSphere, the vCenter setup is hosted in a nested template. This is not usually the case when working with users in a live environment.

User environments can include multiple networks and can optionally have a Network Protocol Profiles (NPP) that corresponds to the networks to connect to the Unified Access Gateway. Prior to version 3.3, NPP was a requirement. Since version 3.3, NPP is no longer required.

Note: Keep in mind that the Unified Access Gateway requires a netmask, default gateway, and subnet to be defined for each network enabled during deployment.

Prerequisites

To deploy Unified Access Gateway using a PowerShell script, you must use the following products and respect versions:

• Latest Unified Access Gateway virtual appliance image OVA file for vSphere (including PowerShell scripts)  my.workspaceone.com, such as .euc-access-point-3.9.X.X-XXXXXXXXXXX.ova.
• Download the VMware OVF Tool 4.3 or later and install it on the same machine that will be used to run the Unified Access Gateway PowerShell deployment script.
• Set up a VMware vSphere ESXi host with a vCenter Server.
• Set up a vSphere data store and the network to use.
• vCenter credentials with permission to create VMs, the credentials will be used to deploy the appliance.

See the Product Interoperability Matrices to determine the compatibility of Unified Access Gateway with other VM products.

Starting with version 3.3, you can deploy Unified Access Gateway without specifying the netmask and default gateway settings in Network Protocol Profiles (NPP). You can specify this networking information directly during the deployment of your Unified Access Gateway instance.

Note: To perform most of these exercises, you must log in to the vSphere Web Client and start PowerShell.

Start Windows PowerShell

1. Click the PowerShell icon located on the Windows taskbar.
2. Navigate to the Unified Access Gateway Resources Directory under the desktop user folder by entering cd '.\Desktop\UAG Resources' and then press Enter.

Preparing the INI File for Deployment

In this exercise, you learn how to use the INI file to deploy and configure a Unified Access Gateway using PowerShell, and how to edit the contents of the INI file for your Unified Access Gateway deployment.

Configure General Deployment Settings

An INI file containing all of the configuration settings is required to deploy the Unified Access Gateway appliance.

In this exercise, you use the uag-2NIC.ini file to provide the respective parameters for your deployment.

You deploy a new Unified Access Gateway appliance called UAG02 in the example, which has two NICs. NIC1 is Internet-facing and NIC2 is for backend and management.

Open the UAG-2NIC.ini File for Editing

Navigate to the uag-2NIC.ini file, such as:

1. Click the File Explorer icon on the taskbar.
2. Click Desktop.
3. Click UAG Resources.
4. Right-click the uag-2NIC.ini file.
5. Click Edit with Notepad++.

Configure General Settings

In the General section, provide the following settings on the INI file:

1. In the name field, enter a name, such as UAG02 in this example.
2. In the source field, enter the path, such as C:\Users\Administrator\Desktop\UAG Resources\UAG Files\euc-unified-access-gateway-3.3.0.0-8539135_OVF10.ova, and use File Explorer to verify that the OVA file has the name indicated.
3. In the target field, enter the destination path, such as vi://administrator@vsphere.local:PASSWORD@vc.corp.local/Nested_Datacenter/host/Host_Cluster.
   Note: You can replace the password with 'PASSWORD' and the script prompts for the password during the PowerShell execution.
4. In the diskmode field, enter thin.
5. In the ds field (ds refers to data store), enter datastore2_ESXi01.
6. In the deploymentOption field, enter twonic.

Continue the General section configuration, and set the following additional values for the parameters on the INI file, keeping in mind that ip0 is the Internet-facing NIC, and ip1 is the internally facing NIC:

1. In the ipMode field, enter STATICV4.
2. In the defaultGateway field, enter the IP address, such as 192.168.110.1.
3. In the dns field, enter the IP address, such as 192.168.110.10.
4. In the ip0 field, enter the IP address, such as 192.168.110.20.
   Important: ip0 is the Internet-facing NIC.
5. In the ip1 field, enter the IP address, such as 172.16.0.20.
   Important: ip1 is the internally facing NIC.
6. In the netmask0 and netmask1 fields, enter the netmask, such as 255.255.255.0.
7. In the netInternet field, enter DMZ_VM_DPortGroup.
8. In the netManagementNetwork and netBackendNetwork field, enter Internal_VM_DPortGroup.

Configure TLS/SSL Certificate

The SSLCert and SSLCertAdmin contain information regarding the SSL Certificates for the administration and Internet interfaces.

1. In the pfxCerts field under SSLCert, enter C:\AW Tools\airwlab.com.pfx (this certificate is for the Internet interface).
2. In the pfxCerts field under SSLCertAdmin, enter C:\AW Tools\airwlab.com.pfx (this certificate is for the administration interface).

Note: The certificate password is requested during the deployment.

Deploying the Unified Access Gateway Appliance

Now that you have configured the INI file for your Unified Access Gateway deployment, you can run the uagdeploy.ps1 Powershell script and provide this INI file as the configuration to automate the deployment.

Execute Deployment Script

As the script starts, a couple of questions ask for the following information:

1. When prompted, enter the information requested, such as in the following example:
2. .\uagdeploy.ps1 .\uag-2NIC.ini
3.            -rootPwd PASSWORD
4.            -adminPwd PASSWORD
5.            -disableVerification false
6.            -noSSLVerify false

           -ceipEnabled yes

• -rootPwd - set the root password for the Unified Access Gateway appliance.
• -adminPwd - set the admin password for the REST API management access.
• -disableVerification - perform validation of signature and certificate.
• -noSSLVerify - perform SSL verification for the vSphere connection.
• -ceipEnabled - Join the Customer Experience Improvement Program ("CEIP") program.

Note: You might get prompted to enter the password related to the certificates defined on the SSLcert and SSLcertAdmin settings. Certificates can be passed in PEM format using the pemCerts and pemPrivKey settings for the SSLCert and SSLCertAdmin sections of the INI file.

The deployment starts and you can follow the progress on the same window or on your vSphere Web Client, which you opened at the beginning of this tutorial.

Confirm that the Deployment Script Completes

After successfully finalizing the deployment, the script automatically powers on the VM UAG02.

The Received IP address presented by the script log is a temporary IP. The final IPs for NIC 1 and NIC2 are assigned to the Unified Access Gateway appliance during the first start. You can return to the vSphere Web Client to validate that as described in the next step.

Validate the Deployment

1. Click VM and Templates.
2. Click UAG-2NIC.
3. Click View all 2 IP addresses.

Important: If the Unified Access Gateway appliance does not finalize the configuration during the first startup, you receive an error message from vSphere Web Client. If that happens, wait for the appliance to finalize, and refresh the entire Google Chrome browser.

Log in to Unified Access Gateway Console

1. Click the New Tab button to open a new tab.
2. Browse to the Unified Access Gateway Administration Console using the URL, such as  https://uagmgt-int.airwlab.com:9443/admin or by clicking a bookmark if you created one.
3. Enter the username, such as admin in this example.
4. Enter the password created for the Admin API in the Deploy OVF Wizard.
5. Click Login.

A successful login redirects you to the initial window where you can import settings or manually configure the Unified Access Gateway appliance.

1. Click Admin.
2. Click Logout.

Configuring Web Reverse Proxy

At this point, the Unified Access Gateway has been deployed and you can access the Unified Access Gateway administration console to add and change configurations of your Unified Access Gateway appliance.

This exercise shows you how Unified Access Gateway can be used as a Web reverse proxy and can act as either a plain reverse proxy or an authenticating reverse proxy in the DMZ. In this exercise, you learn how to set up a plain reverse proxy.

Power ON Intranet VM

Return to the vSphere Web Client to Power ON the VM Intranet, which is hosted on the internal network to be used as part of the Web Reverse Proxy exercise.

1. Click VM and Templates.
2. Click Intranet.
3. Click the Power ON icon.

Log in to Unified Access Gateway Console

1. Click the New Tab button to open a new tab.
2. Browse to the Unified Access Gateway URL, such as https://uagmgt-int.airwlab.com:9443/admin in this example, or click a bookmark if you created one.
3. Enter the username, such as admin in this example.
4. Enter the password created for the Admin API in the Deploy OVF Wizard.
5. Click Login.
6. Under Configure Manually, click Select.

Add Reverse Proxy Settings

1. Click the Show toggle next to Edge Service Settings. After you click, it switches to display the Hide option.
2. Click the gear icon next to Reverse Proxy Settings.
3. Click Add to create a new reverse proxy setting that can be used to access the intranet.

Define Features Used by Reverse Proxy

Click Enable Reverse Proxy Settings only. The toggle switches to YES.

Note: The Enable Identity Bridging feature can be configured to provide single sign-on (SSO) to legacy Web applications that use Kerberos Constrained Delegation (KCD) or header-based authentication. However, this feature is not enabled for this exercise.

Configure Intranet Reverse Proxy Settings

1. Enter the Instance Id, such as intranet, which is a unique name to identify and differentiate a Web reverse proxy instance from all other Web reverse proxy instances.
2. Enter the Proxy Destination URL, such as http://intranet.corp.local, which represents the address of the Web Application.
   1. Enter the Proxy Pattern, such as (|/intranet(.*)|), which specifies that the matching URI paths will forward to the destination URL.
3. Click Save.
4. Click Close.

Additional parameters can be configured for this type of reverse proxy. For more information, see Configure Reverse Proxy With Workspace ONE Access.

Validating Reverse Proxy Configuration

1. Click the down arrow for the Reverse Proxy Settings.
2. Click the refresh icon for the Edge Service Settings.
3. Confirm that the intranet proxy status is GREEN.

After you add the reverse proxy settings for the intranet, the Unified Access Gateway appliance tests the communication between Unified Access Gateway appliance and the intranet. The status turns GREEN if a connection is possible, otherwise, it shows RED.

Important: It can take a few minutes for the intranet proxy to show as GREEN. If you do not see it, click the refresh icon until you see the status change to either GREEN or RED.

Access the Intranet through Reverse Proxy

1. Click the New Tab button to open a new tab.
2. Enter https://uag.airwlab.com/intranet in the address bar and press Enter.
   Note: The uag.airwlab.com resolves to the IP associated with the Unified Access Gateway Internet NIC, which in this example is 192.168.110.20.

The result is a sample intranet page hosted on an internal IIS Server.

• Access to the intranet goes through Unified Access Gateway port 443, as a result of the TLS port sharing configuration enabled by default during deployment.
• Access to the administration console goes through Unified Access Gateway port 9443 and IP 172.168.0.20 in this example, associated with the internal NIC.

Deploying Unified Access Gateway on Amazon Web Services

This section guides you through the configuration and deployment of Unified Access Gateway appliances as Amazon EC2 instances on Amazon Web Services (AWS). This deployment uses a PowerShell script and includes the steps to import the Unified Access Gateway OVA image into AWS and register it as an Amazon Machine Image (AMI).

The exercises cover a Unified Access Gateway 3.9.1 deployment on Amazon Web Services.

The purpose is to provide a deployment option for a production environment on Amazon Web Services.

Architecture

The following architectural diagrams show an example environment on AWS which emulates a typical cloud environment, including public and private networks.

Unified Access Gateway appliances are deployed across different regions, each appliance contains two NICs configured with the respective public and private subnets. Traffic into the Unified Access Gateway appliances comes through the frontend Amazon Elastic Load Balancer.

Amazon Elastic Load Balancing supports the following types of load balancers:

• Application Load Balancer
• Network Load Balancer
• Classic Load Balancer

Application Load Balancers are used to route HTTP/HTTPS (or Layer 7) traffic. Network Load Balancers and Classic Load Balancers are used to route TCP (or Layer 4) traffic.

For more information, see  Elastic Load Balancing features on the AWS website.

The type of Elastic Load Balancing to use with Unified Access Gateway depends on the edge service requirements. As an example, for the Horizon Edge service, the Application Load Balancer should be used, and the Network Load Balancer should be used for Tunnel.

Architecture for Horizon Use Cases

In this architecture, each Unified Access Gateway appliance dedicates an individual VIP to each appliance in addition to the primary load-balanced (AWS Application Load Balancer) VIP. Because you have 4 appliances, you will set up 5 VIPs. The primary Horizon XML-API protocol on HTTPS port 443 uses an application load balancer to allocate the session to a specific Unified Access Gateway appliance based on health and least loaded. The secondary connections (Tunnel, Blast, and PCoIP) would then be routed to the correct Unified Access Gateway appliance based on the VIP IP configured on each appliance.

For more information, see  Understand and Troubleshoot Horizon Connections.

Tunnel Use Cases

In this architecture, Tunnel traffic (Per-App) is balanced by an AWS Network Load Balancer that 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.

Network Interfaces on AWS

As Unified Access Gateway supports deployments with one, two, or three NICs, traffic can be partitioned to receive traffic on a single interface or to route traffic to different interfaces, based on the source of the request. When deploying with multiple NICs, the subnets attached to the appliance must be in the same availability zone.

Prerequisites

Before you can deploy Unified Access Gateway on Amazon EC2 using a PowerShell script, you must satisfy the following requirements.

Amazon Requirements

Prepare the network environment on EC2:

• Security Groups
• VPC, Subnets, and Elastic IP
• At least one S3 bucket

Make sure your AWS account has permission to fully manage the above items, including creating AMI and EC2 instances.

Unified Access Gateway Requirements

Download Unified Access Gateway OVA for Amazon EC2 and PowerShell script - the minimum version is Unified Access Gateway 3.5,  the latest version recommended.

• Latest Unified Access Gateway virtual appliance image OVA file for Amazon AWS (includes PowerShell Script) from  my.workspaceone.com.

PowerShell Requirements

On the machine that will be used to perform the import of AMI and deployment of Unified Access Gateway, install the following PowerShell modules.

Open the PowerShell command windows with administrative rights and run the following command:

• Install-Module -Name AWSPowerShell -Force
• Install-Package 7Zip4PowerShell

Download the sample script  Import Unified Access Gateway into Amazon Web Service and register as AMI.

Importing Unified Access Gateway Image as an Amazon Machine Image (AMI)

The Unified Access Gateway VMDK image must be imported as an Amazon Machine Image (AMI) to be deployed as an Amazon EC2 instance.

There are several steps to be completed; some can be performed using the AWS Console and others must be performed through PowerShell. The steps are as follows:

1. Extract the .vmdk image from the Unified Access Gateway OVA file using PowerShell.
2. Create a bucket on Amazon S3 using the AWS Console or PowerShell.
3. Upload the .vmdk image into the S3 bucket using the AWS Console.
4. Create a VM import service role (vmimport) and apply a policy to the rule using PowerShell, partially supported by AWS Console.
5. Import the .vmdk image into the Amazon EBS snapshot using PowerShell.
6. Register the Unified Access Gateway image as an AMI using PowerShell.

This process can be a challenge for some administrators, as it requires an extra level of knowledge of AWS and PowerShell commands. The step-by-step process is documented as part of the  Unified Access Gateway PowerShell Deployment to Amazon Web Services Guide, however, the sample script ( Import Unified Access Gateway into Amazon Web Service and register as AMI) automates all these steps. Make sure you have downloaded the sample as the next steps rely on that sample.

Extract VMDK Image from Unified Access Gateway OVA

Run the following command, and replace the items between <> with the respective values.

expand-7zip <UAG OVA file including location> <Directory where VMDK will be extracted>

Execute ImportUAGasAMI.ps1 to Import UAG as AMI

Execute ImportUAGasAMI.ps1 using the following parameters:

• -accessKey - User Access Key that has the permissions to execute the script.
• -secretKey - User Security Key that has the permissions to execute the script.
• -vmdkImage - Location path and name of Unified Access Gateway vmdk file name that you just extracted.
• -bucketName - Name of the S3 bucket where the VMDK will be uploaded - if the bucket does not exist, the script will create it for you.
• -region - AWS region where the operation will be performed (ie: us-east-1).

This PowerShell script will be equivalent to steps #2 to #6. Following is a command line example.

.\ImportUAGasAMI.ps1 -accessKey 8daudna9ajd -secrectKey 9aadndma034jrm!f9ajs -vmdkImage C:\uag\euc-unified-access-gateway-3.9.1.0-11012815-system.vmdk -bucketName uag-images -region us-east-1

As the script runs, you will see similar screens based on each step executed.

When the import is finalized, you can see the AMI ID generated for the Unified Access Gateway. Take note of this ID as it will be used later for the deployment steps.

Confirm Snapshot Uploaded to AWS Console

In the AWS Console, you should see your imported EC2 snapshot.

Under EC2 Elastic Block Store:

1. Click Snapshots.
2. Click the snapshot you just imported. You can identify it in the Description.

Confirm AMI Registration on AWS Console

In the AWS Console, you should see your Unified Access Gateway imported image registered as EC2 AMI.

Under EC2 AMI Images:

1. Click AMIs.
2. Click the AMI ID generated by the import process.

Preparing INI File for Deployment

In this section, you learn how to deploy Unified Access Gateway as an Amazon EC2 instance, starting with the preparation of the INI file and where to obtain the information required by the INI.

If you are familiar with Unified Access Gateway deployment on other platforms (vSphere, Azure, Hyper-V), the INI settings will look similar for the general appliance configuration. However, some parameters are not required.

For AWS EC2 deployments, the following settings in the General section are not used.

• diskMode
• ds
• folder
• netInternet
• netManagementNetwork
• netmask0
• netmask1
• netmask2
• netBackendNetwork
• source
• target
• All of the IPv4 settings
• All of the IPv6 settings

For AWS EC2, there is a new section called AmazonEC2 that contains all of the settings specific to AWS EC2.

INI File Sample Definition

[General]
name=UAG-AWS
 
deploymentOption=twonic
 
[AmazonEC2]
 
# authentication
 
credentialProfileName=awsCredentialProfile
 
# type, region, and image
 
instanceType=c4.large
region=us-east-2
amiId=ami-kc0embb7c
 
# eth0 settings
subnetId0=subnet-3d339847
securityGroupId0=sg-32323d938939283920
publicIPId0=eipalloc-043ecs323d3434c17
 
# eth1 settings
subnetId1=subnet-ad3434s1

This is a sample INI that deploys a UAG instance with two NICs, based on c4.large sizing and attaches a public IP address to the instance, in addition to the two private IP addresses for each of the network interface. The PowerShell script will use the Access Key and Secret Key stored on the local profile named awsCredentialProfile – this is discussed in the next topic.

Use this as a template to define the INI file for your deployment.

For a full definition of each of the INI parameters, see  Prepare an INI File.

Certificates

You can configure certificates for the Internet and Admin Interface using the SSLCert and SSLCertAdmin INI sections, where you specify PFX or PEM certs.

[SSLCert]
pfxCerts=
pemPrivKey=
pemCerts=
 
[SSLCertAdmin]
pfxCerts=
pemPrivKey=
pemCerts=
 

NOTE: You might receive an error message Error: Failed to deploy UAG - User data is limited to 16384 bytes when deploying the appliances through PowerShell. This happens because the configuration data in your INI file is too large for Amazon AWS EC2 deployment. It is a known limitation that Amazon might increase in the future.

While this limit is in place, it might be necessary to reduce the amount of configuration data specified in your INI file. For example, you can check the SSL certificate files to see if unnecessary root or intermediate certificates can be removed. Alternatively, if the SSL certificates are not required during deployment, you can remove the certificates and upload the SSL certificates after deployment by using the Unified Access Gateway Admin UI or REST API.

Create AWS Credentials

For security reasons, the INI file does not contain the Access Key ID or Secret Access Key so they must be stored in a named or default profile. These AWS credentials are used to cryptographically sign the corresponding web service requests used by the PowerShell script. They should be stored in a named profile which is then referenced from the INI file.

• Create an Amazon AWS account if you do not have one.
• Create an access key and obtain the values of the Access Key ID and Secret Access Key. See  AWS Account and Access Keys.
• Use the following PowerShell example command to store these values in a profile named awsCredentialProfile: replace the <> values.

Set-AWSCredential-AccessKey <Secret Key>  -SecretKey <Secret Key> -StoreAs <AWS Profile Name>

For more information, see  Using AWS Credentials.

Network Parameters

Some important considerations regarding network configuration.

• When using subnetId# or publicIPId0 parameters, the IP is assigned based on your network configuration on AWS.
• You can use the privateIPAddress# parameters to set the IP address used by EC2 DHCP for eth0, eth1, or eth2. Normally this is not required but can be used to set a static private IP address instead of a dynamic one.
• You can assign different Security Groups based on the securityGroupId# parameters.
• The subnets assigned to the UAG instance must be in the same availability zone, otherwise, the deployment will fail.
• The use of a public IP address attached to the UAG EC2 instance is optional; if your appliances are behind a load balancer, they are not required.
• A subnet can be configured to automatically assign a public IPv4 address to assigned instances, even if you do not configure the public IP address on the INI file. This behavior can be changed for each subnet under the Modify auto-assign IP settings.

How to Find the Public IP Address IDs on AWS Console

On the VCP Dashboard, under Elastic IPs, find all the respective Elastic IP Allocation IDs available. This is the value to use with the publicIPId# parameter.

How to Find the Subnet IDs on AWS Console

On the VCP Dashboard, under Subnets, find all the respective Subnet IDs available and their respective availability zone (AZ).

The subnets assigned to the appliance must be on the same AZ.

How to Find the Security Groups IDs on AWS Console

Security Groups are firewalls that can be associated with each of the Unified Access Gateway NICs.

On the VCP Dashboard, under Security Groups, find all the Group IDs available and assign them to the respective NICs, using the securityGroupId# parameter. If this setting is not specified, the default EC2 Security Group is used.

For example, in a two-NIC deployment, define two Security Groups and assign to the respective NIC:

• For Internet NIC (securityGroupId0), create a Security Group as follows:
  • Add inbound rules to allow traffic only into the required ports (80, 443, 8443, 4172, and so on) and protocols (TCP/UDP) for Horizon Use Cases.
  • Add inbound rules on 443 TCP/UDP for Tunnel and outbound rules for 443/TCP for Workspace ONE UEM API Server.
• For Backend/Management NIC (securityGroupId1), create another Security Group as follows:
  • Add an inbound rule to allow traffic into TCP/9443 only from a specific IP source to access UAG Admin UI.
  • Add an outbound rule to the internal resources
  • If you want to enable access with SSH, add another inbound rule for SSH/22.

When deploying with three NICs, securityGroupId3 is assigned to Management only.

Deploying Unified Access Gateway Appliance as Amazon EC2 Instance

With all the requirements for AWS environment and Unified Access Gateway completed you are now ready to deploy Unified Access Gateway.

Deploy Using PowerShell

Ensure you have the uagdeployec2.ps1 and uagdeploy.psm1 files on your client machine, those are the UAG scripts required for deployment.

Execute the following command to create your AWS profile credentials and add them to the INI file if you have not already, as covered in the previous chapter.

Set-AWSCredential-AccessKey <Secret Key>  -SecretKey <Secret Key> -StoreAs <AWS Profile Name>

Run the following command to initiate the deployment.

.\uagdeployec2.ps1 <INI File> <ROOT PASSWORD> <ADMIN PASSWORD> <no/yes>

• <INI FILE> - replace with the name of your INI file that contains the configuration for the appliance.
• <ROOT PASSWORD> - password for the root user.
• <ADMIN PASSWORD> - password for the UAG admin UI/REST API user access.
• <no/yes> - Customer Experience Program.

The deployment execution should look like the image shown, where the output of a successful deployment presents the ID of the instance created.

The instance is automatically initiated after the deployment is completed.

NOTE: If you run the script again using the same instance name defined in the INI file on the parameter name under the General section, the instance will be terminated and a new one deployed.

Validate Unified Access Gateway EC2 Instance on AWS Console

On AWS Console under EC2 Dashboard:

1. Click Instances.
2. Click the Unified Access Gateway EC2 instances to obtain all the information related to the image.

Clean userData Value from Unified Access Gateway EC2 Instance

It is highly recommended to clear the userData value to avoid the password from being visible in cleartext on the AWS CLI.

1. Stop the Unified Access Gateway instance.
2. Clear the userData value from the current instance of Unified Access Gateway by using the following command:

edit-EC2InstanceAttribute -InstanceId <INSTANCE_ID> -Attribute userData - Value "blank".

Access the Unified Access Gateway Administration Console

You can access the administration console using https://<UAG_IP_OR_HOSTNAME>:9443/admin from the same subnet to configure the appliance and edge services. Access is restricted to the management interface in a multiple NIC deployment, and to the internet interface in a single deployment.

For test and validation when not in the same subnet for management and before adding the appliance to the load balancers target group, you can add a temporary public IP to the appliance for validation, and later remove that IP.

Deploying Unified Access Gateway on Microsoft Azure

This section guides you through the configuration and deployment of Unified Access Gateway appliances on Microsoft Azure using a PowerShell script, including the steps to upload the Unified Access Gateway VHD image into Microsoft Azure.

The exercises cover Unified Access Gateway 3.9.1 deployment on Microsoft Azure.

The purpose is to provide a deployment option for a production environment on Microsoft Azure leveraging your existing subscription.

NOTE:  Horizon Cloud support deployment on Azure, allowing customers to leverage their existing capacity on Azure to deploy virtual Desktop and Apps. This offer deploys out-of-the-box Unified Access Gateway appliances to secure access to the virtual desktop and applications. Customers can configure only a subset of Unified Access Gateway features in this environment using the Horizon Cloud administration console.

This tutorial provides guidance on how to deploy Unified Access Gateway appliances as part of your Azure environment, and not through the Horizon Cloud on Azure.

Architecture

The following architectural diagrams show an example environment on Microsoft Azure which emulates a typical cloud environment where Unified Access Gateway appliances are deployed to enable access to internal resources. The appliances are deployed with multiple NICs and configured to the respective public and private networks. For high availability and scalability, traffic is load-balanced using the native Azure Load Balancer.

Multiple Unified Access Gateway appliances are deployed as part of a resource group. Each appliance contains two NICs configured with the respective public and private subnets. Traffic into the Unified Access Gateway appliances comes through the frontend Azure load balancer.

The Load Balancer requirements for Unified Access Gateway depend on the edge services requirements, e.g., for Horizon edge service Application Load Balancer should be used, and a Network Load Balancer should be used for Tunnel.

Azure load balancers are offered in two SKUs: Standard and Basic. These SKUs differ in scenario scale, features, and pricing. Any scenario that's possible with a Basic Load Balancer can be created with a Standard Load Balancer.

To learn more about Azure Load Balancer, see  Azure Load Balancer documentation on the Microsoft website.

Prerequisites

Before you can deploy Unified Access Gateway on Microsoft Azure using a PowerShell script, you must satisfy the following requirements.

Microsoft Azure Requirements

An Azure environment where you can perform the management and creation of the following objects.

• Resource Group.
• Storage account and container.
• Virtual Network, Subnets, Public IP.
• Security Groups.

Make sure your Azure account has permission to fully manage the above items, including creating Virtual Machine instances.

Unified Access Gateway Requirements

Download Unified Access Gateway OVA for Microsoft Azure and PowerShell script - minimum version of Unified Access Gateway 3.5,  latest version recommended.

• Latest Unified Access Gateway virtual appliance image VHD file for Microsoft Azure (includes PowerShell Scripts) from  my.workspaceone.com.

PowerShell Requirements

On the machine that will be used to perform the upload of VHD image and deployment of Unified Access Gateway, install the following PowerShell modules.

Open the PowerShell command windows with administrative rights and run the following command:

• Install-Module -Name AzureRM -Force

Preparing the Microsoft Azure Environment

First, to configure your Microsoft Azure environment, several details from the setup are required in the INI file for deployment.

Make sure you have:

• Created an Azure subscription if you do not already have one.
• Defined the resource group to be used to deploy the appliance.
• Created a storage account blob container to store Unified Access Gateway VHD images.
• Created virtual network and subnet(s).
• Created Network Security Group for firewall rules.
• Created a public IP address.

Follow the steps to  Prepare your MS Azure Environment.

All the network-related resources must be part of the same resource group where you will deploy the Unified Access Gateway appliances; this is a requirement.

Uploading Unified Access Gateway VHD Image to Microsoft Azure

First, you must upload the Unified Access Gateway VHD image to Microsoft Azure for it to be deployed as an Azure Virtual Machine.

This chapter will guide you through each step.

Upload the VHD Image to the VHDS Container

Use the following example PowerShell commands to upload the VHD image to the VHDS container.

Replace the variables with the real values related to your Azure environment.

• storage account - replace with the storage account name authorized to store the Unified Access Gateway images.
• UAG VHD FILENAME - the name of the Unified Access Gateway .vhd file on Azure after upload.
• UAG VHD FILE AND LOCATION - name and location of Unified Access Gateway .vhd file on the local machine.

$imageURI = "https://<storage account>.blob.core.windows.net/vhds/<UAG VHD FILENAME>
$imagePath = "UAG VHD FILE AND LOCATION”
Add-AzureRmVhd -ResourceGroupName <RESOURCE GROUP NAME> -LocalFilePath $imagePath -Destination $imageURI -NumberOfUploaderThreads 32
 

Confirm VHD Image Upload to Azure

You can access the Azure Portal to confirm the upload to the respective container previously defined.

Preparing INI File for Deployment

In this section, you learn how to deploy Unified Access Gateway as a Microsoft Azure instance, starting with the preparation of the INI file and where to obtain the information required by the INI.

If you are familiar with Unified Access Gateway deployment on other platforms (vSphere, Azure, Hyper-V), the INI settings will look similar for the general appliance configuration. However, some parameters are not required.

For Microsoft Azure deployments, the following settings in the General section are not used.

• diskMode
• ds
• folder
• netInternet
• netManagementNetwork
• netmask0
• netmask1
• netmask2
• netBackendNetwork
• source
• target
• All of the IPv4 settings
• All of the IPv6 settings

For Microsoft Azure, there is a new section called Azure that contains all of the settings specific to Azure.

INI File Sample Definition

[General]
name=UAG-AZ
 
deploymentOption=twonic
 
[Azure]
 
#Blob container, name for the storage of the Unified Access Gateway disk image
 
diskStorageContainer=uagdisks
 
#URI of the Unified Access Gateway .vhd image file to deploy
 
imageURI=https://uagstore.blob.core.windows.net/vhds/euc-unified-access-gateway-3.9.1.0-12345678_OVF10.vhd
 
#Azure account subscription ID
 
subscriptionID=12345678-1234-1234-1234-123456788901
 
# size, resource group, network
 
vmSize=Standard_A2_v2
 
resourceGroupName=uagrg
virtualNetworkName=VirtualNetwork
 
# eth0 settings
subnetName0=frontend-subnet
networkSecurityGroupName0=UAGInternetSG
publicIPAddressName0=UAG1PublicIP0
 
# eth1 settings
subnetName0=Backend-subnet
networkSecurityGroupName0=UAGManagementSG

This screenshot depicts a sample INI that deploys a UAG instance with two NICs, based on Standard_A2_v2 sizing, and attaches a public IP address to the instance, in addition to the two private IP addresses for each of the network interfaces.

The PowerShell script does not contain credentials to access your Azure environment. Instead, you initialize a session prior to the script execution using the following command:

connect-AzurermAccount

For more information, see Prepare an INI File on Omnissa docs.

Certificates

You can configure certificates for the Internet and Admin Interface using the SSLCert and SSLCertAdmin INI sections, where you specify PFX or PEM certs.

[SSLCert]
pfxCerts=
pemPrivKey=
pemCerts=
 
[SSLCertAdmin]
pfxCerts=
pemPrivKey=
pemCerts=

Network Parameters

Some important considerations regarding network configuration:

• Subnets, security groups, and public IPs must be part of the same Resource Group. This is a requirement for the Unified Access Gateway PowerShell script, otherwise, the deployment will fail.
• You can assign different Security Groups based on the securityGroupId# parameters
• The use of a public IP address attached to the UAG instance is optional, assuming your appliances will be behind load balancers, they are not required.

How to Find the Public IP Address Name on Azure Portal

Search for Public IP Address on the search bar to return the list of Public IP addresses available or create a new one to obtain the Name to use in the INI file.

How to Find the Virtual Network and Subnets Configuration on Azure Portal

Search for Virtual Network to return a list of virtual networks or create a new one on your environment:

• Select one of the virtual networks or create one.
• Access the virtual network to identify the subnet names.

Use the virtual network and subnet name in the INI file.

How to Find the Security Group Names on Azure Portal

Security Groups are firewalls that can be associated with each of the Unified Access Gateway NICs.

Search for Network security groups to locate all the Security Groups available and assign them to the respective NICs, using the networksecurityGroupName# parameter.

For example, in a two-NIC deployment, define two Security Groups and assign to the respective NIC:

• For Internet NIC (networksecurityGroupName0), create a Security Group as follows:
  • Add inbound rules to allow traffic only into the required ports (80, 443, 8443, 4172, and so on) and protocols (TCP/UDP) for Horizon Use Cases.
  • Add inbound rules on 443 TCP/UDP for Omnissa Tunnel and outbound rules for 443/TCP for Workspace ONE UEM API Server.
• For Backend/Management NIC (networksecurityGroupName1), create another Security Group as follows:
  • Add an inbound rule to allow traffic into TCP/9443 only from a specific IP source to access UAG Admin UI.
  • Add an outbound rule to the internal resources
  • If you want to enable access with SSH, add another inbound rule for SSH/22.

When deploying with three NICs, networksecurityGroupName3 will be assigned to Management only.

Deploying Unified Access Gateway Appliance on Microsoft Azure

With all the requirements for Azure environment and Unified Access Gateway completed you are now ready to deploy Unified Access Gateway.

Deploy using PowerShell

Ensure you have the uagdeployaz.ps1 and uagdeploy.psm1 files on your client machine, those are the UAG scripts required for deployment.

Execute the following command to log in to your Azure environment if you have not already, as covered in the previous chapter.

connect-AzurermAccount

Run the following command to initiate the deployment.

.\uagdeployaz.ps1 <INI File> <ROOT PASSWORD> <ADMIN PASSWORD> <no/yes>

• <INI FILE> - replace with the name of your ini file that contains the configuration for the appliance.
• <ROOT PASSWORD> - password for the root user.
• <ADMIN PASSWORD> - password for the UAG admin UI/REST API user access.
• <no/yes> - Customer Experience Program.

The deployment execution should look like the image shown. The instance is automatically initiated after the deployment is completed.

NOTE: If you run the script again using the same instance name defined in the INI file on the parameter name under the General section, the instance will be terminated and a new one deployed.

Validate Unified Access Gateway Instance on Azure Portal

On Azure Portal, search for Virtual Machines or the name of the Unified Access Gateway you provided on the INI file.

Click the instance.

Access the Unified Access Gateway Administration Console

You can access the administration console using https://<UAG_IP_OR_HOSTNAME>:9443/admin from the same subnet to configure the appliance and edge services. Access is restricted to the management interface in a multiple-nic deployment, and to the internet interface in a single deployment.

For test and validation when not in the same subnet for management and before adding the appliance to the load balancers target group, you can add a temporary public IP to the appliance for validation, and later remove that IP.

Deploying Unified Access Gateway on Google Cloud Platform

This section guides you through the available resources to help you prepare and deploy Unified Access Gateway appliances as Google Compute Engine VM on Google Cloud Platform, including step-by-step instructions on how to prepare the environment and deploy the appliances using PowerShell script.

Before getting hands-on with the deployment, start with the feature walkthrough video Deploying Unified Access Gateway on Google Cloud Platform, which provides a great level of detail about the deployment process and shows how to get this one.

Deployment Guide

In case you need detailed and step-by-step instructions, visit the  Unified Access Gateway PowerShell Deployment to Google Cloud Platform guide.

Summary and Additional Resources

In these exercises, you have learned how to:

• Deploy the Unified Access Gateway on one NIC using the vSphere Web Client
• Deploy the Unified Access Gateway on two NICs using PowerShell
• Deploy Unified Access Gateway on Amazon Web Services (AWS)
• Deploy Unified Access Gateway on Microsoft Azure
• Deploy Unified Access Gateway on Google Cloud Platform

For more information, check out the  Unified Access Gateway Activity Path on  Digital Workspace Tech Zone.

Additional Resources

For more information about Workspace ONE, explore the Workspace ONE UEM Product Page.

Check out the Workspace ONE and Horizon Reference Architecture which provides a framework and guidance for architecting an integrated digital workspace using Workspace ONE and Horizon. 

Changelog

The following updates were made to this guide:

Date	Description of Changes
2024/05/29	Updated links and references to latest documentation.
2022/02/24	Guide has been reviewed and content is up to date.
2021/03/29	Added the following chapter: Deploying Unified Access Gateway on Google Cloud Platform.
2020/05/05	Updated the following chapters:                      Overview Added the following chapters: Getting Started Deploying Unified Access Gateway on Amazon Web Services Deploying Unified Access Gateway on Microsoft Azure

About the Author and Contributors

This tutorial was written by:

•  Andreano Lanusse, Staff Architect, Technical Marketing, Omnissa.

Feedback

Your feedback is valuable.

To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.