The VMware Tunnel is a product you can install on physical or virtual servers that reside in either the DMZ or a secured internal network zone. VMware Tunnel comprises two separate components, Proxy and Per-App tunneling, each with their own features.

Consider using the Per-App Tunnel component as it provides the most functionality with easier installation and maintenance. Per-App Tunnel uses the native platform (Apple, Google, Microsoft) APIs to provide a seamless experience for users.

The Proxy component provides most of the same functionality of Per-App Tunnel with the need for additional configuration. This component can be leveraged only by the applications having the Workspace ONE (AirWatch) SDK implemented or using the App Wrapping. This includes most of the VMware productivity applications.

VMware Tunnel offers single-tier and multi-tier deployment models. Both the configurations support load-balancing for faster availability. The Proxy component supports SSL offloading, while Per-App tunneling cannot be SSL-offloaded.

Per-App Tunnel Architecture

VMware Tunnel provides granular access control to applications and services both in your network and in the cloud. The VMware Tunnel client provides per-app management, permitting explicit trust of individual applications you want to manage, and domain-based filtering for the easy definition of access control and split-tunneling policies.

VMware Tunnel is built on native frameworks provided across all major platforms. When an application is launched or creates a network request, that request is forwarded to the Tunnel client for routing. In this way, Tunnel provides local filtering for determining what traffic must be tunneled into your network, sent to the Internet or another proxy, or blocked from leaving the device.

Data that is passed to the Tunnel gateway leverages TLS and DTLS algorithms to perform the following checks as part of authentication:
  • VMware Tunnel uses SSL pinning to ensure that the server identity is correct.

  • VMware Tunnel performs TLS mutual authentication with a client certificate that uniquely identifies the device.
  • VMware Tunnel gateway validates that the client certificate is on a whitelist of trusted certificates within the Workspace ONE UEM Console, and performs a device compliance check to ensure the integrity of the user’s device.

For internal routing of traffic, it is required that the Tunnel gateway has properly configured DNS, as routing policies for Tunnel are defined on hostnames and not IP address. If internal DNS is not exposed in the DMZ, then it is recommended to deploy VMware Tunnel in a cascade mode to make use of the internal DNS controllers.

Proxy (SDK/Browser) Architecture

The VMware Tunnel Proxy component uses HTTPS tunneling to use a single port to filter traffic through an encrypted HTTPS tunnel for connecting to internal sites such as SharePoint or a wiki.

When accessing an end site, such as SharePoint, an intranet, or wiki site, traffic is sent through an HTTPS tunnel, regardless of whether the end site is HTTP or HTTPS. For example, if a user accesses a wiki site, whether it is http://<internalsite>.wiki.com or https://<internalsite>.wiki.com, the traffic is encrypted in an HTTPS tunnel and sent over the port you have configured. This connection ends once it reaches the VMware Tunnel and is sent over to the internal resource as either HTTP or HTTPS.

HTTPS Tunneling is enabled by default. Enter your desired port for the Default HTTPS Port during VMware Tunnel configuration, as described in VMware Tunnel Configuration.

The current authentication scheme requires the use of a chunk aggregator of fixed size. A low value puts restrictions on the amount of data that is sent from the devices in a single HTTP request. By contrast, a faster value causes extra memory to be allocated for this operation. Workspace ONE UEM uses a default optimum value of 1 MB, which you can configure based on your maximum expected size of upload data. Configure this value in the proxy.properties file on the VMware Tunnel Proxy server in the /conf directory.

Managing VMware Tunnel Certificates

VMware Tunnel uses certificates to authenticate communication among the Workspace ONE UEM console, VMware Tunnel, and end-user devices. The following workflows show the initial setup process and certificate integration cycle.

Complete the following steps for initial setup workflow:

  1. VMware Tunnel connects to the Workspace ONE UEM API and authenticates with an API Key and a Certificate.
    • Traffic requests are SSL encrypted using HTTPS.
    • Setup authorization is restricted to admin accounts with a role enabled for the VMware Tunnel setup role (see preliminary steps).
  2. Workspace ONE UEM generates a unique identity certificate pair for both the Workspace ONE UEM and VMware Tunnel environments.
    • The Workspace ONE UEM certificate is unique to the group selected in the Workspace ONE UEM console.
    • Both certificates are generated from a trusted Workspace ONE UEM root.
  3. Workspace ONE UEM generates a unique self-signed certificate to be used as the server certificate. Optionally, you can also use your own Public SSL certificate instead of the self-signed certificate on the Front-end VMware Tunnel server (if VMware Tunnel is deployed using the cascade mode) or on the backend server (if VMware Tunnel is deployed using the basic mode).
  4. Workspace ONE UEM sends the unique certificates and trust configuration back to the VMware Tunnel server over HTTPS.

    The VMware Tunnel configuration trusts only messages signed from the Workspace ONE UEM environment. This trust is unique per group.

    Any additional VMware Tunnel servers set up in the same Workspace ONE UEM group as part of a highly available (HA) load-balanced configuration are issued the same unique VMware Tunnel certificate.

    For more information about high availability, refer to the VMware Workspace ONE UEM Recommended Architecture Guide.

Complete the following steps for certificate integration cycle:

  1. Workspace ONE UEM generates Device Root Certificates that are unique to every instance during the installation process.

    For Proxy: The Device Root Certificate is used to generate client certificates for each of the applications and devices.

    For Per-App Tunnel: The VMware Tunnel Device Root Certificate is used to generate client certificates for each device.

  2. For Proxy: The certificate an application uses to authenticate with the VMware Tunnel is only provided after the application attempts to authenticate with the Workspace ONE UEM enrollment credentials for the first time.

    For Per-App Tunnel: The certificate is generated at the time of profile delivery.

  3. VMware Tunnel gets the chain during installation. The VMware Tunnel installer is dynamically packaged and picks these certificates at the time of download.
  4. VMware Tunnel makes an outbound call to the AWCM/API server to receive updated details on the device and certificates. The following details are exchanged during this process: DeviceUid, CertThumbprint, applicationBundleId, EnrollmentStatus, complianceStatus.
  5. VMware Tunnel maintains a list of devices and certificates and only authenticates the communication if it sees a certificate it recognizes.

    X.509 (version 3) digitally signed client certificates are used for authentication.