Understanding the key concepts that are used throughout VMware Tunnel helps you make most of your enterprise mobility experience with enhanced security architecture, simplified management and a greater emphasis on the end-user VPN connectivity experience.
Read through the key concepts to become familiar with the VMware Tunnel technologies and features.
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. When designing a load balancing solution, the load balancer must be configured with an IP or session-based persistence enabled. The load balancer sends data from a client to the same server for all its traffic during the connection. An alternative solution might be to – on the client side – use a DNS round robin, which means the client can select a different server for each connection. VMware Tunnel requires a TCP/UDP pass-through configuration on the load balancer for the per-app VPN capabilities. The VMware Tunnel Proxy authenticates devices based on the HTTP header information in the request and ensures that the load balancer is configured to Send Original HTTP Headers so that these headers are not removed when going through the load balancer to VMware Tunnel. VMware Tunnel Proxy supports SSL offloading, bridging, and TCP pass-through.
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.
- 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 are introducing a New Tunnel Profiles section under the Tunnel configuration page. The Tunnel profiles for Standalone Enrollment can now be configured under this new section. Please refer to the VMware Tunnel Management section for more details.
Full Device Tunnel
With Full Device Tunnel 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.
- Client version 2.1 and later
- UEM version 2105 or later
- MDM managed, Registered mode, and Standalone Enrollment mode supported.
- Client version 22.05 and later
- UEM version 2203 or later
- Currently Full Device Tunnel Mode is supported for Standalone enrollment mode only.
- Client version 21.12 and later
- UEM version 2203 and later
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.
Proxy is the VMware Tunnel component that handles securing traffic between an end-user device and a website through the Workspace ONE Web mobile application. VMware Tunnel Proxy is also available on Windows.
To use an internal application with VMware Tunnel Proxy, then ensure the VMware Workspace ONE SDK is embedded in your application, which gives you tunneling capabilities with this component.
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 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 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).