How to setup the new Workspace ONE Tunnel Windows Desktop Application

Hi, my name is Pim van de Vis and I’m honored to be the first guest blogger here. I’m part of the same team as Brooks and might be returning for more content in the future (depending on how happy Brooks will be with this content :)). In this first blog I will describe how to start using the new VMware per-app VPN Tunnel client for Windows 10.

I hear you say: “But a VMware Tunnel app for Windows 10 already exists? Why do we need another one?”

Good question. There are now two VMware Tunnel Clients for Windows 10:

  • Workspace ONE Tunnel Universal Windows Platform (UWP) app
  • Workspace ONE Tunnel Windows Desktop Application

The difference between the two is the packaging format. The old client is a UWP app, coming from the Microsoft Store. The new client is a native win32 application that comes as an executable installer.

The UWP app relies on the native Windows 10 per-app VPN framework, which has some instabilities and bugs. Combined with the limitations of the UWP framework made VMware decide to build a new VPN client from scratch. This new Tunnel client is still a per-app VPN, since that concept works well with Modern Management and other platforms like IOS and Android.

Because the new per-app VPN Tunnel Windows Desktop Application (let’s just call it ‘Tunnel client’ from now on) is not fully documented yet I decided to create this blogpost the get you started with the setup. This way you can test for yourself which Tunnel client works best for your use cases.

Pre-requirements

Let’s start with the prerequisites. In order to start using the Tunnel client, you first need to have a VPN server running, in this case the VMware Tunnel on Unified Access Gateway. The setup of UAG is well documented, so I’m not going to cover that.

Ensure the Tunnel service is up and running and make sure the “Test Connection” on the UEM Console results in a green ‘Success’ message.

Next to this there are some version requirements:

This new Tunnel 1.2 release introduces a new feature, that was not available with the UWP Tunnel client: Support for tunneling the SMB protocol for network drives and printers by flagging “SYSTEM” as an application.

I’ve seen numerous customers that want to embrace and migrate to Modern Management, but still have some on-premises resources they need to access. Typically, these are ‘legacy’ applications, sometimes an on-prem Exchange server, but often also file shares and network printers. Because file shares are not tied to an application, a typical per-app-VPN client cannot be used to access those. With this new Tunnel release it’s now possible to filter SMB traffic and redirect that to the fileservers or print servers you want to make available to your clients. You’d be surprised how many customers are asking for this.

Next to this new feature the 1.2 release also adds support for wildcard certificates, so give it a try!

Configure the Windows Tunnel client

Configuration of the new Tunnel client requires two steps. First, we need to push a new Windows Desktop Profile using the WS1 UEM console. This is needed to install a certificate on the Windows 10 devices, used by the Tunnel client to authenticate. Second, we need to setup ‘Device Traffic Rules’ to determine which traffic needs to be tunneled. This section will describe both steps.

Add a new Windows Desktop Profile

The new Tunnel client supports only “Desktop Profiles”. Using the Workspace ONE UEM console, add a new Windows Desktop – Device Profile and configure “General” & “VPN” sections as shown below. This profile will install a certificate on your clients, used by the Tunnel client to authenticate.

Setting up Device Traffic Rules

Next step is to define some traffic rules. These rules are needed to define which applications should use the Tunnel, and what destinations can be reached through the tunnel. You can determine what traffic should be tunneled, so you can ensure only the necessary traffic gets tunneled. This allows for a so-called split tunnel setup.

Go to the Tunnel configuration home page (Groups & Settings > Configurations > Tunnel) and click ‘Edit’ on the DTR (Device Traffic Rules) card to start configuration. First, we need to define the applications that need to use the Tunnel. In below example, “Google Chrome” a desktop application is added. To add “Store” application, the same process must be repeated except the “App Identifier” field should contain the PFN (Package Family Name).

After the applications are defined, we need to setup traffic rules for these added applications. Here you define the application, the action that is needed (TUNNEL) and the destinations. This will ensure that the Tunnel is only used for specific applications, and only if those applications access specific internal resources. This will allow you to use a split tunnel configuration. For example, you can define that the Google Chrome browser should tunnel all traffic to *.vmware.com, while all other traffic from the browser should go directly to the internet. Below is an example of a Tunnel Traffic Rule:

Support for SMB, enabling network drives and printers

As mentioned, the new 1.2 version of the Tunnel client supports tunneling SMB traffic from ‘system’ to support mapping network shares and network printers. In order to enable this, you just need to add the following app configuration to the Device Traffic Rules and make sure you define the correct Destinations. That’s all there is, you don’t need to tunnel Explorer.exe or something like that.

Push Windows Desktop Tunnel Client

Now that the Tunnel client has the right configuration in place, we need to make sure we install the Tunnel client to all Windows 10 devices that require the Tunnel functionality. We are going to leverage the Software Distribution function of Workspace ONE UEM for this. You can download the latest version of the Tunnel client here:

  1. Login to https://my.workspaceone.com
  2. Click on Workspace ONE Products
  3. Click on Workspace ONE Tunnel
  4. Select the latest version of the “desktop” version of the app
  5. Click “Installs and Upgrades” tab and then downlaod

Using the WS1 UEM console, go to “Apps & Books” and add a new application. Since this application installs a driver, a full device restart is required for it to function properly. If you are on 1912 or later you can take advantage of the new “User Engaged Restart” feature to give users more control over when they reboot.

  1. Go to Apps & Books > Applications > Internal > Add Application
  2. Upload the exe file: VMwareTunnelInstaller.exe
  3. Files Tab
    1. Specify this ‘Uninstall command’:
      • VMwareTunnelInstaller.exe /Uninstall /Passive /norestart
  4. Deployment Options Tab
    1. Install Context: Device
    2. Install command: VMwareTunnelInstaller.exe /Install /Passive /norestart
    3. Admin Privelages: Yes
    4. Device Restart: User Engaged Restart (requires WS1 1912 console and hub or later. If you are not yet on this version, select “Require Reboot).
    5. Number of days after which device automatically reboots: Up to you, but I usually do between 1-3
    6. Retry Count, Retry Interval, Install Timeout: Default
    7. Installer Reboot Exit Code: 9009,3010
    8. Installer Success Code: 0
    9. ‘When To Call Install Complete’ – Identify Application By:
      1. App exists. You will need to find out the GUID of the Tunnel version you are using. Easiest way to do this is to install it manually on one system first, run this powershell command: gwmi win32_product, then find the App GUID for Tunnel. Tunnel version 1.2.0.18 has GUID {10494B75-B525-4801-B143-1386063DF2C9}
  5. Optionally add an icon under Images Tab > Icon.
  6. Click “Save and Assign” and add an assignment

That’s it! These are the required steps to get started and install and configure the new Tunnel client. When you deploy the Tunnel app to a device, you will see the User Engaged Restart screen:

Validate Configuration or health of Tunnel Client

The final section of this blog will describe how to validate if the correct configuration is in place, and how to troubleshoot if something is not working as expected.

With the installation of the Tunnel client comes an application that can be used to check the status of the Tunnel by the end-user. Below picture shows what the UI should look like when Tunnel is configured correct and connected:

When the Profile is not installed, the certificate will be missing, and this is what the UI tells you in that case:

If this is the case, check the local machine certificate store whether a Tunnel VPN certificate is present. It should look like this:

When the Tunnel is Disconnected or if traffic rules (DTR) are not applied appropriately as per the DTR configuration in the UEM Console, please check the UI if the expected settings are in place:

If the “Application Access” section is empty in the UI, please check the registry data if the correct configuration is in place. Check the value “DeviceTrafficRules” at location Computer\HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Tunnel

Finally, there are two logfiles that you can check for more information.

First the is the installer log that will show any failures during the actual installation of the VMware Tunnel client. This logfile can be found in the following location: %TEMP%\VMware_Tunnel_<date>_000_VmwareTunnelClientInstaller.log

And there is also the Tunnel logfile that contains all the information about settings up connection, traffic tunneling, routing, etc. If you want to use this log to analyze the Tunnel behavior, I recommend changing the log level to ‘debug level first. In order to do this, use the Registry editor and change the value of ‘LogLevel’ to ‘4’. This value can be found at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Tunnel

With the new 1.2 version of the Tunnel client you can also enable debug logging by right clicking on the UI icon:

After setting the log level to ‘Debug’ the actual Tunnel logfile can be found at this location:
“C:\ProgramData\VMware\VMware Tunnel\win_tunnel.log”

This Post Has 11 Comments

  1. Nice article, Thanks for the insight. I will give it a try

  2. Does the tunnel also work for DFS share?

    1. It’s not primary designed for it, but there are ways to get it to work with various windows services. I’ll see if I can find someone who has done it and the steps they took.

    2. I’ve done some testing with DFS Namespace and there seems to be some additional hurdles to be taken for this. I’m talking with development now to see what we can do with regards to DFS.

  3. Hi Brooks,

    I’ve a small problem, I get Not Configured in Tunnel client although a certicate has been deployed in the local machine certificate store, do you have any idea of what I could check to troubleshoot this?

    1. Does it say anything below the ‘Not Configured’ message? And what does the Tunnel.log file say in %ProgramData%? Make sure to enable Debug logging first, see the last part of this blogpost on how to do that.

      1. Below I’ve got “Authentication certificates are not present” , can I send send you the log file?

        1. Are you testing with the 1.2 Tunnel client and not an older release? With 1.2 we have added support for wildcard certificates and certs that contains multiple SAN names. What kind of certificate are you using?

  4. Yes we are on 1.2 version, server certificate is wildcard, client certificate is airwatch default

    1. Ok, thanks for confirming. Please send me the logfile so I can have a look.

  5. Thanks for the article Pim, appreciated!!!

Leave a Reply