Knowing how the Omnissa Workspace ONE Tunnel solution works together is important to understanding how other features can then be added to help with enhanced security, simplified management, and emphasis on the end-user VPN connectivity experience.
Workspace ONE Tunnel can be installed on physical or virtual servers that reside in either the DMZ (demilitarized zone) or a secured internal network zone. It offers single-tier and multi-tier deployment models. Both the configurations support load-balancing for faster availability. Tunnel provides granular access control to applications and services both in your network and in the cloud.
The Tunnel Client provides 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.
For internal routing of traffic, it is required that the Workspace ONE Tunnel gateway has properly configured DNS (domain name system), 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 Tunnel in a cascade mode to make use of the internal DNS controllers.
The device contains the applications required by the end-user to perform their daily job. Some applications require access to internal resources to function. Those applications, based on Per-App VPN configuration, use Workspace ONE Tunnel which communicates with the Tunnel Service on Unified Access Gateway hosted on the DMZ, to validate if the device requesting access is in compliance or not before authorizing access through the internal resource.
Tunnel Modes
Per-App Tunnel Mode is the most commonly used Tunnel mode. It works with the device's Workspace ONE Tunnel App ( iOS, Android, Windows Desktop, and macOS) to allow internal, public, and purchased applications to access corporate resources that reside in your secure internal network on an application-by-application basis. By providing this per-application type of tunneling, you as the administrator (admin) can ensure that only authorized applications will be able to have access to your internal resources. All other applications that have not been approved will be unable to communicate with your back-end systems.
This mode provides most of the same functionality of the former Proxy component without the need for additional configuration. However, customers that are still transitioning to Zero Trust access architectures can make use of the Full Device Tunnel mode instead. Full Device mode allows administrators to direct all application traffic from the device through an encrypted tunnel to access company resources.
Full Device Tunnel Mode
Full Device mode still allows you, as the admin, to direct all application traffic from the device through an encrypted tunnel to access company resources. It is currently supported on Windows, macOS, and Android platforms. On Android devices, all device traffic within the AE container, regardless of the source application, will be tunneled in both Work Managed and Work Profile modes.
Each platform has its own Minimum Requirements:
| For Windows | For macOS | For Android |
|---|---|---|
| Client version 23.02 and later | Client version 22.05 and later | Client version 21.12 and later |
| UEM version 2109 or later | UEM version 2203 or later | UEM version 2203 or later |
| MDM managed, Registered mode, and Standalone Enrollment mode supported. | Currently Full Device Tunnel Mode is supported for Standalone enrollment mode only. | MDM managed and Standalone Enrollment mode supported |
When deploying Workspace ONE Tunnel, you will also choose either Single-Tier (Basic) Mode or Multi-Tier (Cascade) Mode.
Single-Tier (Basic) Mode consists of a single Unified Access Gateway (UAG) appliance, typically situated in the DMZ (demilitarized zone), where devices can connect to the appropriate port for each feature, authenticate with a certificate issued from the Workspace ONE UEM console, and connect to internal sites. Single-Tier models have a single instance of Workspace ONE Tunnel configured with a public DNS (domain name system).
Multi-Tier (Cascade) Mode has a separation between servers with firewalls between the tier. Typical Workspace ONE Multi-Tier deployments have a DMZ (demilitarized zone) that separates the Internet from the internal network. Workspace ONE Tunnel supports deploying a front-end server in the DMZ that communicates with a back-end server in the internal network. The multi-Tier deployment model includes two instances of Tunnel with separate roles. The Workspace ONE Tunnel front-end server resides in the DMZ and can be accessed from public DNS (domain name system) over the configured ports. The servers in this deployment model communicate with your API and AWCM servers (AirWatch Cloud Messaging). For SaaS deployments, Workspace ONE hosts the API and AWCM components in the cloud. For an on-premises environment, the AWCM component is typically installed in the DMZ with the API. For more information on deploying the Unified Access Gateway appliance, refer to Configuring the Tunnel Edge Service.
Trusted Network Detection
Trusted Network Detection is a feature used by the Tunnel client to determine whether or not to establish a connection to the Tunnel Service based on the network the device is connected to. If the device is connected to a 'Trusted Network', the Tunnel client will not tunnel traffic.
Trusted Network Detection Support Matrix
| Platform | MDM Enrollment | Standalone Enrollment |
|---|---|---|
| Android | Yes | Yes |
| iOS | Yes, starting in UEM 2310 | Roadmap |
| Windows | Yes | Yes |
Support for the macOS Tunnel client is on our Roadmap. This feature is independent of Tunnel mode (Per-App or Full Device).
Session Authentication with Security Assertion Markup Language
To facilitate user-interactive authentication for Tunnel in addition to the existing certificate-based authentication, you as the admin can leverage the 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 as well.
Minimum Requirements:
-
Workspace ONE UEM 2210 or later
-
UAG 2212 or later
For more information, refer to the Client Configuration topic for your specific client type.
Standalone Enrollment for Workspace ONE Tunnel Client
To facilitate secure remote access on unmanaged devices, you can leverage the Standalone Enrollment mode for the Tunnel client. There is no requirement for MDM enrollment or Workspace ONE HUB on the device. Basic and SAML (Security Assertion Markup Language) authentication is supported for user authentication. To configure your client for Standalone Enrollment, refer to the Client Configuration topic for your specific client type.
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.
DTLS and TLS Connection for UDP and TCP Traffic
You can open a Transmission Control Protocol (TCP) port and a User Datagram Protocol (UDP) port on the Workspace ONE Tunnel server to support TCP and UDP traffic. The Workspace ONE Tunnel client seamlessly sends the UDP traffic over DTLS and TCP over TLS. After the TLS channel is established, the Workspace ONE 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 Workspace ONE 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 Workspace ONE 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.
Load Balancing
Workspace ONE Tunnel can be load balanced for an improved performance and faster availability. Using a load balancer requires additional considerations and will require 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.
Workspace ONE Tunnel also requires a TCP/UDP pass through configuration on the load balancer for 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 Workspace ONE 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 Workspace ONE Tunnel. Tunnel proxy supports SSL offloading, bridging, and TCP pass through.
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 Workspace ONE Tunnel client to establish a DTLS connection to the Workspace ONE Tunnel server, the firewall must allow the UDP traffic in and out of the Workspace ONE Tunnel Server UDP listing port. For example, if the Workspace ONE 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 Workspace ONE Tunnel servers, the load balancer must be set up so that the UDP traffic from the device must always go to the same Workspace ONE Tunnel server.
For information on load balancing with Unified Access Gateway appliances, see Unified Access Gateway Load Balancing Topologies in the Unified Access Gateway
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).
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 Workspace ONE 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 Tunnel server to determine when to disconnect.
App Certificate Authentication and Encryption
When you allowlist an application for corporate access through 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 Workspace ONE 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. For more refer to the Managing Certificates topic.
App Tunnel and Secure Browsing
App tunnel is a generic term used to describe the act of creating a secure path 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 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 Workspace ONE Tunnel using a Workspace ONE UEM issued certificate and accesses internal websites by proxying traffic through the Tunnel over SSL encrypted HTTPS. This provides greater levels of access to mobile users and you can remain confident that security is not compromised by encrypting traffic, remembering history, deactivating copy/paste, defining cookie acceptance, and more.
Was this page helpful?