Understanding the key concepts and features can help you to make the most of your enterprise mobility experience with enhanced security architecture, simplified management and a greater emphasis on the end-user VPN connectivity experience.

VMware Tunnel provides granular access control to applications and services, both in your network and in the cloud. The Tunnel client provides per-app management, with explicit trust of individual applications you want to manage. Domain-based filtering is used for easy definition of access control and split-tunneling policies. It is built on native frameworks and is provided across all major platforms. When an application is either launched, or creates a network request, that request is forwarded to the VMware Tunnel client for routing. In this way, local filtering is provided to determine 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 VMware Tunnel gateway leverages TLS and DTLS algorithms to perform the following checks as part of authentication:
  • It uses SSL pinning to ensure that the server identity is correct.
  • It performs TLS mutual authentication with a client certificate that uniquely identifies the device.
  • The Tunnel gateway validates that the client certificate is on an allowlist of trusted certificates within the Workspace ONE UEM Console and performs a device compliance check to ensure the integrity of the user’s device.
Note: For internal routing of traffic, it is required that the VMware Tunnel gateway has properly configured DNS, as routing policies for VMware 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.

VMware Tunnel requires the 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.

VMware Tunnel offers both single-tier and multi-tier deployment models that are configured to support load-balancing for faster availability. Most deployments of Tunnel can make use of least-connections load balancing with no persistence profile, for both the frontend and backend Tunnel servers.

If you are making use of DTLS for high-performance, UDP-heavy applications, only then does persistence matter on the front-end. In this scenario, IP-based persistence is recommended such that a Tunnel client will have both the TLS and DTLS channel assigned to the same front-end server. The back-end server may still function without any persistence. VMware Tunnel requires a TCP/UDP pass-through configuration on the load balancer for the VPN capabilities.

The VMware Workspace ONE Tunnel solution comprises of three main components.
  1. The Workspace ONE UEM console allows administrators to set up the Tunnel server configuration, the Tunnel profiles, and the Device and Server Traffic Rules. It also provides device lifecycle and Tunnel certificate management for Standalone Tunnel enrollment.
  2. The Tunnel server component can run as an edge service on the Unified Access Gateway or deployed through our SASE Secure Access solution. The Tunnel server provides client authentication and remote, secure access to company resources.
  3. The Tunnel clients are deployed on end user devices and are configured via Workspace ONE UEM Tunnel profiles and facilitate secure connection to the Tunnel server(s).

DTLS and TLS Connection for UDP and TCP traffic

You can open a TCP port and a UDP port on the VMware Tunnel server to support TCP and UDP traffic. VMware Tunnel client seamlessly sends the UDP traffic over DTLS and TCP over TLS. After the TLS channel is established, the VMware Tunnel client establishes a secondary DTLS channel.

If the traffic is UDP, a new UDP datagram flow is created to carry the traffic. The flow is transmitted through the new DTLS channel to the VMware Tunnel server. From the server, a UDP connection is established to the UDP host, and the data in the flow is delivered to the UDP host through the connection and conversely.

Similarly, if the traffic is TCP, a new TCP flow is created to carry the traffic. The flow is transmitted through the original TLS channel to the VMware Tunnel Server. From the server, a TCP connection is created to the TCP host and the data is transmitted through the connection to the TCP host and conversely.

Firewall and Load Balancer Configuration

Since DTLS is transmitted on the top of UDP Protocol, the firewall and the load balancer must be configured to allow the UDP traffic to pass through.

To allow the VMware Tunnel client to establish a DTLS connection to the VMware Tunnel server, the firewall must allow the UDP traffic in and out of the VMware Tunnel Server UDP listing port. For example, if the VMware Tunnel server is setup to listen on port 443, the UDP port 443 must be opened at the firewall to allow all the incoming connection from the devices.

In addition, if a load balancer is used to distribute loads between multiple VMware Tunnel servers, the load balancer must be set up so that the UDP traffic from the device must always go to the same VMware Tunnel server.

For information on load balancing with Unified Access Gateway appliances, see Unified Access Gateway Load Balancing Topologies in the Unified Access Gateway Documentation.

Note: The Per-App VPN configuration file, server.conf, offers an option to allowlist IP addresses of the load balancer health monitoring. If you choose to perform the health monitoring, specify the IP addresses of the health monitoring servers within the configuration file that sends the following pings to avoid the health monitoring pings to be counted as bad TLS/DTLS handshakes.
  • Maximum of 8 addresses.
  • Incoming_ping_address_1 0.0.0.0 (Make sure to uncomment this line).

  • Incoming_ping_address_2 0.0.0.0 (Make sure to uncomment this line).

App Tunnel and Secure Browsing

App tunnel is a generic term used to describe the act of creating a secure "tunnel" through which traffic can pass between an end-user device and a secure internal resource, such as a website or file server.

By using the VMware Workspace ONE Tunnel with Workspace ONE Web, you can provide secure internal browsing to any intranet site and web application that resides within your network. Because Workspace ONE Web is designed with application tunneling capabilities, all it takes to enable mobile access to your internal websites is to enable a setting from the Workspace ONE UEM console. By doing so, Workspace ONE Web establishes a trust with VMware Tunnel using a Workspace ONE UEM issued certificate and accesses internal websites by proxying traffic through the VMware Tunnel over SSL encrypted HTTPS. IT can not only provide greater levels of access to their mobile users, but also remain confident that security is not compromised by encrypting traffic, remembering history, deactivating copy/paste, defining cookie acceptance, and more.

Standalone Enrollment for VMware Tunnel Client

To facilitate secure remote access on unmanaged devices, administrators can leverage the Standalone Enrollment mode for the VMware Tunnel Client. There is no requirement for MDM enrollment or Workspace ONE HUB on the device. Basic and SAML authentication is supported for user authentication.

To easily configure the client for Standalone Enrollment, we introduced a new Profiles section under the VMware Tunnel configuration page. The profiles for Standalone Enrollment can now be configured under this new section. Please refer to the VMware Tunnel Management section for more details.

Note: Standalone enrollment is supported for the macOS and Windows platforms with the required minimum UEM version of 2203. The Android platform is supported with the required minimum UEM version of 2209.

Full Device Tunnel

With full device capability, administrators can now direct all application traffic from the device through an encrypted tunnel to access company resources. This may be used by customers still transitioning to Zero Trust access architectures enabled with per-app tunneling.

Full device tunnel is currently supported on Windows, macOS, and Android platforms. On Android devices, all device traffic within the AE container regardless of source application in both Work Managed and Work Profile modes will be tunneled.

Minimum Requirement

Windows:
  • Client version 23.02 and later
  • UEM version 2105 or later
  • MDM managed, Registered mode, and Standalone Enrollment mode supported.
macOS:
  • Client version 22.05 and later
  • UEM version 2203 or later
  • Currently Full Device Tunnel Mode is supported for Standalone enrollment mode only.
Android:
  • Client version 21.12 and later
  • UEM version 2203 and later
  • MDM managed and Standalone Enrollment mode supported

Per-App Tunnel Component

Per-App Tunnel uses the native platform (Apple, Google, Microsoft) APIs to provide a seamless experience for users. The Per-App Tunnel provides most of the same functionality of the Proxy component without the need for additional configuration that Proxy requires.

The Per-App Tunnel component and VMware Workspace ONE Tunnel apps for iOS, Android, Windows Desktop, and macOS allow both internal, public, and purchased (iOS) applications to access corporate resources that reside in your secure internal network. They allow this functionality using per app tunneling capabilities. Per-app tunneling lets certain applications access internal resources on an app-by-app basis. This restriction means that you can enable some apps to access internal resources while you leave others unable to communicate with your back-end systems.

It is considered to be a best practice to use the Per-App Tunnel component as it provides the most functionality with easier installation and maintenance.

Load Balancing

The VMware Tunnel can be load balanced for an improved performance and faster availability. Using a load balancer requires additional considerations. VMware Tunnel 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.

VMware Tunnel requires a TCP/UDP pass through configuration on the load balancer for the per-app VPN capabilities. SSL offloading is not supported and must be deactivated. A standard load balancer at Layer 4 (TCP/UDP) level maintains a TCP connection from the client to the server throughout the duration of the TCP connection. Hence, no additional persistence set up is required at the load balancer to send data from a client to the same server for all the traffic during the connection.

An alternative solution on the client side can use a DNS round robin, which means the client can select a different server for each connection.

The VMware Tunnel proxy authenticates the devices based on the HTTP header information in the request and ensures that the load balancer is configured to send the original HTTP headers so that the headers are not removed when going through the load balancer to the VMware Tunnel. VMware Tunnel proxy supports SSL offloading, bridging, and TCP pass through.

Setting up a Load Balancer for Back-End Tunnel Servers

The persistent rules between the Front-End and Back-End servers must be similar to the persistent rules between the device and the Front-End due to the similar type of TLS communication.

The VMware Tunnel Server maintains a timer and disconnect the TLS channel when the on-demand timeout is reached. The timeout settings at the load balancers must be set to deactivated and the load balancer must permit the VMware Tunnel Server to determine when to disconnect.

App Certificate Authentication and Encryption

When you allowlist an application for corporate access through the VMware Tunnel, Workspace ONE UEM automatically deploys a unique X.509 certificate to enrolled devices. This certificate can then be used for mutual authentication and encryption between the application and the VMware Tunnel.

Unlike other certificates used for Wi-Fi, VPN, and email authentication, this certificate resides within the application sandbox and can only be used within the specific app itself. By using this certificate, the VMware Tunnel can identify and allow only approved, recognized apps to communicate with corporate systems over HTTP(S), or, for Per-App Tunneling, TCP/UDP and HTTP(S).

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.  The VMware Tunnel Device Root Certificate is used to generate client certificates for each device.
  2.  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.

Session Multi-Factor Authentication (MFA)

To facilitate user-interactive authentication for Tunnel in addition to the existing certificate-based authentication, administrators can leverage multi-factor authentication feature for authenticating against the Tunnel Gateway. This implementation leverages SAML 2.0 and integrates with major Identity Providers providing an additional identity layer for user and application access. The Identity Provider may provide additional entitlement restrictions or Conditional Access policies.

Session MFA is available for the Windows client in both Managed and Unmanaged modes and for the macOS client in Unmanaged mode. This feature is also in Technical Preview for the Android and iOS clients in Managed mode

Minimum Requirements:

  • Workspace ONE UEM 2212 or later
  • UAG 2212 or later

Minimum Requirements for the Technical Preview (Android and iOS):

  • Workspace ONE UEM 2302 or later
  • UAG 2302 or later

Please refer to the VMware Tunnel Client Management section for more details.