How to set up VMware Tunnel in cascade mode

Workspace ONE Tunnel is a per-app VPN technology, which is pretty easy to deploy and work on all major platforms today (iOS, Android, macOS and Windows 10). In order for this to work you need to deploy a Unified Access Gateway in a DMZ and configure a few things in Workspace ONE UEM console.

Deploying such virtual appliance can be really simple – one machine with one NIC. This is what I typically deploy for testing or PoC. But what if you require something little bit more secure?

Cascade mode

Cascade mode is a method of deployment. You deploy two layers of Unified Access Gateways – one can be in DMZ the other one can be in internal network zone, or one can be in external DMZ and the other one in internal DMZ.

To quote the official documentation:

The front-end server facilitates authentication of devices by connecting to AWCM when requests are made to the VMware Tunnel. When a device makes a request to the VMware Tunnel, the front-end server determines if the device is authorized to access the service. Once authenticated, the request is forwarded securely using TLS over a single port to the back-end server.

The back-end server connects to the internal DNS or IP requested by the device.

Cascade mode communicates using TLS connection (or optional DTLS connection). You can host as many front-end and back-end servers as you like. Each front-end server acts independently when searching for an active back-end server to connect devices to the internal network. You can set up multiple DNS entries in a DNS lookup table to allow load balancing.

Both the front-end and back-end servers communicate with the Workspace ONE UEM API server and AWCM. The API server delivers the VMware Tunnel configuration and the AWCM delivers device authentication, device access control list, and traffic rules. The front-end and back-end server communicates with API/AWCM through direct TLS connections unless you enable outbound proxy calls. Use this connection if the front-end server cannot reach the API/AWCM servers. If enabled, front-end servers connect through the back-end server to the API/AWCM servers. This traffic, and the back-end traffic, route using server-side traffic rules. 

How to set it up?

It is easy with 2 little things that can stop you if you don’t pay attention to them and that’s why I am writing this post.

The process is as follows:

1. Deploy front-end and back-end UAG

It’s the same process for both appliances – I would recommend using the Powershell deployment approach (https://minarik.io/unified-access-gateway-powershell-deployment), but of course manual OVA deployment will work just fine.

It’s obvious that those two appliance will have different networking configuration and most likely the front-end UAG will not have access to the internal DNS, which is fine.

2. Configure Tunnel in Workspace ONE UEM

Nothing difficult over here. In the section Configuration > Tunnel create new config. Select the “Cascade” deployment mode. You will need to enter the front-end/back-end hostname and ports.

Front-end hostname is the public FQDN, which is accessible from devices no matter where they are located.

Back-end hostname is internal FQDN (name from you internal DNS).

Ports are fully customisable, the default port is 8443, but you can put there what ever you want. In my case I do run Tunnel on port 5443. Those two ports does not need to match, but in my eyes it’s easier to use a single port for both.

You can keep everything else (certificates, logging level, server traffic rules…) is default.

3. Create a VPN configuration profile for devices

I will show this for iOS, but similar step will be needed for Android.

You need to create new profile with a VPN payload. Select the “Workspace ONE Tunnel” connection type. Server field should be automatically filled for you.

You can have multiple device traffic rules, but at this point the “Default – Default” is OK.

Speciality for iOS are native Apple apps like Safari or Mail. For those you can specify the domain, which should go through the Tunnel. This is the internal domain (in my lab it’s minarik.cloud).

4. Push a managed application with Tunnel config

Application must be managed by Workspace ONE in order for it to leverage the Tunnel.

Simply add a new managed application – like for example Workspace ONE Web.

And assign a Tunnel profile, there should be only one. The name will correspond with the VPN device profile you’ve created in the previous step.

For iOS this is all in terms in application. For Android you need to deploy Workspace ONE Tunnel app to every device.

5. Create device traffic rules

Now we need to set the rules which application should have access to which servers/domains in the datacenter.

In the Configuration > Tunnel page navigate to Device Traffic Rules and Edit it.

Modify the Default rule set.

Create the rules to your liking. Action TUNNEL means that per-app VPN will be used. BYPASS means direct connection to internet. You can use wildcards as well e.g. *.minarik.cloud.

6. Enable REST API

Unified Access Gateway is downloading the Tunnel configuration using a REST API on the Workspace ONE UEM. Make sure that the REST API is enabled.

7. Enable Tunnel on back-end UAG

Fill in the details in the UAG administration (listening on port 9443).

8. Enable Tunnel on front-end UAG

Fill in the details in the UAG administration (listening on port 9443). Here comes the two little things to pay attention to.

The front-end appliance must be able to resolve the back-end appliance hostname. Typically you have a different/no DNS in the DMZ, which means that you need to put the name into the host entries.

Second thing is that front-end must trust the back-end SSL certificate. If you open https://backend_uag:your_tunnel_port get the certificate and upload it as trusted to the front-end.

Note: If the certificate is not trusted the Tunnel service will be shown as green (in the UAG console), but the VPN will not be established and stuck in “Connecting…” state on the device. Same applies if the front-end cannot resolve the back-end FQDN.

That’s it. You can test it from the device.

Troubleshooting tips

First of all enable the SSH access during the Powershell deployment. Once everything is tuned and working you can redeploy the UAG without the SSH.

If you see a red light in the Tunnel status on UAG check this log file the error is typically written there:

/opt/vmware/gateway/logs/esmanager.log

Other Tunnel related logs are written into this file:

/var/log/vmware/tunnel/vpnd/tunnel.log

In general when a Tunnel is configured – meaning UAG downloaded the configuration from API server – you should see files in the following folder, specifically you can check the server.conf.

 /opt/vmware/tunnel/vpnd 

It’s better to check the host entries directly in the /etc/hosts file, because sometimes it’s not shown in the UAG admin console. Keep in mind that you should not edit this file manually, but always do the changes in the admin console.

Other stuff which can help is the:

systemd-resolve --status

Which will show you the currently used DNS server. The /etc/resolve.conf will not give you the correct data.

For a multi-NIC deployment it might be beneficial to know about this command to trace the path:

tracepath -n X.X.X.X

Additional network tools (like tcpdump) are hidden and available after running this command.

 /etc/vmware/gss-support/install.sh