Introduction - Unified Access Gateway Advanced Services

This workshop guides you through the end-to-end setup of VMware Tunnel and Content Gateway Edge Services on Unified Access Gateway.

In both modules you will be deploying the Unified Access Gateway Appliance and configure each Edge Services both via PowerShell method, in addition to that you will be enabling VMware Tunnel and Content Gateway on Workspace ONE UEM Console, as configure Apps to use Per App VPN capability, and setup internal repositories to be accessible by Content Locker, etc..

This workshop is aimed at educating you on the available Edge Services on Unified Access Gateway, and this first version start with VMware Tunnel that enables Per App VPN on managed mobile devices to secure access internal resources and Content Gateway that provides secure access to internal repositories using Content Locker App.

In order to complete this workshop, a iOS device is required. You will be enrolling a device, download an app and configure that app to access internal websites hosted on this lab.

At the end of this lab, you will learn about each Edge Services, the common use cases and problems they solve, when to use one vs other, and how to implement each one of them.

Before getting started, let's go over the lab network setup followed by a brief outline of each deployment method.

1. Lab Architecture

DMZ & Internal networks:

External requests to the vApp are sent to the vPod Router, which will direct those requests to the appropriate resource based on the incoming port. Ports 4000-6500 are reserved for the lab components so all traffic coming in on these ports will be forwarded to your Unified Access Appliance appliance's appropriate Edge Service.  In addition, ports 443 and 9443 will be forwarded to your Unified Access Gateway Appliance over the respective ports.

The vApp Networks (Internal, DMZ, and Transit) are created within the Lab vApp.  The Internal and Transit networks are NATed to the SE-UCS-Network for outbound internet connectivity while the DMZ network routes through the vPodRouter 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.

This setup was taken so that the lab environment can attempt to emulate a typical customer environment.

vPod Router | ESXi01 6.5.0 U1 | Control Center | vCenter Server 6.5 U1 deployed in the ESXi01

2. HOL Architecture Overview

Lab Network Overview

In our lab environment, there are two networks that you can deploy your servers into, however for this lab you will be deploying the Unified Access Gateway Appliance on a DMZ and assigning the respective Network Interface Cards (NICs).

As you can see on the Architectural diagram, there are two major networks. On the bottom is the vApp network required to support the lab and on the top is the Lab network, identified as vCenter Networking. For the purpose of this lab we will focus on the Lab network, which is hosted on the ESXi and represented by the following three networks.

  • VM Network & Management: Dedicated network to access Management Console
  • Internal Network: Represents the internal network on 172.16.0.x range. ControlCenter, ESXI, vCenter and Intranet Server 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 will be deployed. The Unified Access Gateway Internet facing NIC will be associated to this network.
HOL Architecture Overview

Understanding the Assigned Hostnames and Ports

For this lab, you will be assigned 2 ports and 2 hostnames that route through the F5 as shown in the above diagram.  You will be using non-standard ports for these services in the 6000 - 6500 port range due to how the F5 is configured to inspect and route traffic to the SE Lab networks.  Follow the steps with the above diagram to see how the traffic is routed:

  1. The hostnames you received ( are CNAMEs that point to the external IP of the F5.  When these hostnames are resolved, they will be routed to the F5 to be inspected and forwarded to the SE Lab networks.
  2. If the request includes only the hostname (, the F5 will use the Hostname iRule. This Hostname iRule inspects inbound traffic to the F5 over port 443 (HTTPS).  The traffic is decrypted using the * SSL certificate and chain. The Hostname iRule then inspects the traffic, re-encrypts the traffic using the * SSL certificate and chain,  and then routes the inbound request to the appropriate destination server based on the hostname of the request.  This process is known as SSL Bridging, which is NOT supported by Per-App Tunnel.
  3. If the request includes the hostname and port (, the F5 will use the Port iRule.  This Port iRule inspects inbound traffic to the F5 over non-443 ports.  Unlike the Hostname iRule, the Port iRule parses the request for the port number and then routes the inbound request to the appropriate destination server based on the port of the request.  This process does not involve decrypting or re-encrypting the traffic and simply forwards the request to the desired destination.  This process uses SSL Passthrough.
  4. From the F5 Hostname or Port iRules, the traffic will be forwarded to the configured IP address, which will be NIC 0 of the vPodRouter VM in your vPod for this lab.  This configuration has been made automatically for you when the lab was started.
  5. The vPodRouter is configured to forward Unified Access Gateway traffic to the IP address over the DMZ Network.
  6. The Nested DMZ Network ( on vmnic2) is provided by NIC 2 on the ESXi-01 Host (
  7. The request reaches the nested Unified Access Gateway appliance deployed on

Avoiding SSL Bridging

As described above, we use non-443 ports for this lab for VMware Tunnel and Content Gateway to avoid decrypting and re-encrypting the traffic since this is not supported with Per-App Tunnel.  In other scenarios, you would normally use the standard ports where possible.  This exercise will demonstrate that the ports for both services can be configured as necessary to work within the necessary architecture.

3. Network Interfaces

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

It is up to the customer to determine what is appropriate for their environment when selecting the number of NICs during installation. However, it is important for you to understand the expected behavior when 2 or 3 NICs are enabled. For this lab, as well as many customer use cases, we will provide two modules, where the first one will install Unified Access Gateway on a single NIC and the second one will install Unified Access Gateway with two NICs.

4. Customer Considerations

Since this workshop is designed for the purpose of deploying the Unified Access Gateway server through vSphere, the vCenter setup is hosted in a nested template, which will not be case when working with customers in a live environment.

Customer environments will include multiple networks and may or may not have a Network Protocol Profiles (NPP) that correspond to the networks they will connect the Unified Access Gateway to. Prior to version 3.3 NPP was a requirement. However, in version 3.3 NPP is no longer required. Keep in mind, the Unified Access Gateway requires a Netmask, Default Gateway, and subnet to be defined for each network enabled during deployment.


Add your comment

E-Mail me when someone replies to this comment

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.