How to setup the new Workspace ONE Tunnel Windows Desktop Application

by

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}
  6. Optionally add an icon under Images Tab > Icon.
  7. 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”

Share on:

52 thoughts on “How to setup the new Workspace ONE Tunnel Windows Desktop Application”

    • 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.

      Reply

    • 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.

      Reply

  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?

    Reply

    • 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.

      Reply

        • 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?

          Reply

      • Issue resolved: if you use a custom certificate for server authentication, you need to fill the Custom Configuration XML in the WS1 Tunnel Profile with the ServerCertSN.

        Reply

    • Yes, you can still use the ‘old’ UWP Tunnel client from the MS Store, but that might not get updates and is limited in speed and functionality. That is why a new win32 Tunnel client was created.

      Reply

  7. Thank you very much for your article because Workspace One Support site is really poor in documentation regarding the windows tunnel part.
    I installed Workspace One Tunnel 1.2 but in the application I’m still in grey (Not Configured Authentication Certificates not prsent) despite the certificate is in the right place.
    Reading you I see that I need to create a custom xml configuration file, but how do I do that?
    I found my ServerCertSN in my certificate in the Subject line. (alphanumeric;vpn@air-watch.com)
    Thank you in advance for your help and have a nice day.

    Reply

  8. how can i manage ip rather than domain.
    how can i manage ip instead of domains?
    let me explain.
    in my internal network many addresses are used via ip and not dns.
    if as a destination to manage instead of * .mydomain.com I put an ip for example 192.168.100.11 (or a better ip network 192.168. *) does it work anyway or will i have problems?

    Reply

    • I seriously don’t know, because I always test with DNS. It’s not that hard to setup (and I hate remembering IP addresses) 🙂
      But feel free to give it a try and provide your feedback here.

      Reply

  9. Hi Pim,

    After more than a month of problems with VMware tunnel windows 1.3, since yesterday everything works : ).

    I had different concerns:

    1. The custom xml file I was using was the wrong certificat, I had to put on my wildcard

    *.myexternaldomain.ch

    2. Then I had a problem with my .local domain and I had to modify my UAG terminal to make it work.

    3. when I launched I tried to go to an internal website with Internet Explorer it didn’t work while with Google Chrome or Edge it was OK.
    While analyzing I understood that I needed two Internet Explorer applications, one x64 and one x86.

    Shares work by DNS name or internal ip (192.168.x.x), intranet sites and OK printers too.

    Thanks for your help with this blog.
    David Dor

    Reply

  10. We just tested this app on three different laptops and the tunnel app worked per se but it slowed our computers down. The tunnel was using over 50% of the CPU. And internet connection seems slow. Not sure what we are doing wrong.

    Reply

    • This sounds like a conflict, maybe with anti virus or a security product?
      Probably best to open a support ticket so we can analyze the logs.

      Reply

  11. Has anyone used VMware tunnel for byod. I was looking at this for a solution but we require 2fa. For the life of me I cannot find anything for VMware tunnel to prompt for creds or rsa. Anyone have a solution?

    Reply

    • The Tunnel currently uses certificates for authentication, so the device needs to be enrolled and thus trusted. You can use a token during device enrollment to make sure you have the 2FA in place at that point.
      Feel free to submit a feature request for 2FA tunnel authentication here: https://wsone-uem.ideas.aha.io/

      Reply

  12. Hey Pim, thanks for the great post.
    When using the tunnel, is there any reason that could cause certain domains to not resolve? we have a few domains we wish to resolve via the tunnel e.g. *.abc.xyz.local & def.xxx. We are able to resolve the def.xxx addresses via the tunnel. However, the *.abc.xyz.local addresses do not resolve. These however, resolve fine when accessed via the Web app on an iOS or Android device.
    Any ideas what could be the issue here?

    Reply

  13. Hi Pim,

    Thank you for the post. I found that when we try and access an internal site via the tunnel, the browser first says that site cannot be found and then auto-refreshes to load the page after the tunnel has connected (all done within 3-4 seconds).
    Is this expected?

    Reply

    • Hi,
      Thanks for your comment. The Tunnel needs to connect first, which is fast, but can still take a couple of seconds. If the URL is getting access before the Tunnel connection is established, the user could get a message. It depends on the browser how to handle this, not much the Tunnel can do about that. I have seen this behavior before.

      Reply

  14. Hi Pim
    We have found that in split DNS scenarios (different DNS servers for internal and external networks but hosting the same domain name) the Tunnel checks both the internal and the external DNS and uses the first answer it gets.

    We expected the Tunnel to use the internal response if matching a Device Traffic Rule and the external response if not, but looks like we are having a random behaviour based on witch DNS server responds first.

    Quite strange… so I was wondering if it could be something in our implementation or if it is working as intended

    Thank you very much for your help with this blog

    Reply

    • Thanks for your comment.
      I’ve heard some other split DNS questions last week, so I would like to get into this.
      I’ll send you an email to follow up.

      Reply

  15. hi, we configured one single URL to be tunneled when using chrome. However the connection on Windows 10 is taking up to 30 seconds to establish – and it does not matter if the URL is the one configured or another public URL which should be bypassed.
    The log has ha lot of entries like: “DEBUG: Domain not found in dns Cache table for ip 216.58.215.228”. There is Symantec Endpoint Protections installed, but has no network related components active.
    Also the Powershell command “Get-DnsClientNrptRule” takes a long time to show up.
    On MacOS it works instantly as expected (safari).

    Reply

      • Hi. thanks for you answer. I have added the URL there but no difference.
        But then I discovered something strange: We have Symantec Endpoint Protection installed in our company.
        Just for fun I right click the system tray icon and disable Symantec, it still behaves the same way.
        But if I UNINSTALL Symantec it immediately starts working as expected, and the URL via Tunnel opens immediately! But in Symantec there are no network related things configured, and also no Firewall settings.

        As soon I uninstall Symantec also the Powershell command is displayed instantly!

        Task Manager shows me 8% CPU load when Symantec is installed and Tunnel app is running on a process called “svchost.exe -k netsvcs -p -s Winmgmt” which is the WMI service of Windows. I can see this behavior also on other clients, where the VMware Workspace One Tunnel is not installed. This process load appears at the same time as the URL via tunnel is accessed. When Symantec is uninstalled, the process load does not happen.

        Honestly, I don’t know where to begin investigating now…

        Reply

        • I think it would be best to open a support ticket with Symantec and/or VMware to investigate this. Because it sounds like a conflict, that might needs some settings changes.

          Reply

  16. Can any Android app use the Per-App VPN configuration, i’m trying to give access to Google Chrome but no luck, enable the VPN un the Tunnel App but does boy resolver the domain, any ideas?

    Reply

  17. Anybody had error code “Device unknown to gateway Please contact your IT Admin”?
    Windows device is enrolled, certs are present(Airwatch certs), iOS and Android tunnel is working as excepted.
    Thanks for help

    Reply

  18. Following your guide, I’ll try to make brief and please tell me what I can check. Here is my environment:

    SaaS Customer
    No Internet facing firewall rules have been added to accomodiate UAG (pfsense firewall)
    1 NIC Setup
    On WS1, Rest API Enabled
    On the UAG, Tunnel settings show green
    On WS1, Checking Groups & Settings > Tunnel > Test Connection shows green (success) for Console to AWCM & Tunnel to API.
    Client where Profile has been pushed down, when opening WS1 Tunnel App, shows Google Chrome under Applicaiton access (only app I have set right now) but tunnel shows “Disconnected” “Tunnel cannot reach Gateway”
    When looking at the console of the UAG, and running command “systemctl status vpnd” shows green Active (running) but error shows:
    ERROR: API: Bad connection to API. Check connection to API service.
    ERROR: API: AllowListManager Query returns Bad Responce
    ERROR: API: AllowListManager AsyncAPIQuery: OnError

    Any ideas? I would really appreciate any help! Thank you!

    Reply

    • Update:
      I added an internal DNS entry for the DAG01 server to resolve to the internal private IP. When testing the tunnel on the same internal network as the DAG01 server, I get “Trusted Network” and the tunnel shows disconnected. I assume this is expected behavior. Now when testing from the outside the network, the client now shows Disconnected: SSL Trust with gateway failed. Also, I restarted the DAG01 vm and I do not get the errors anymore as mentioned in the previous post…just two INFO lines: INFO: AllowListManger: allowlist refreshed. # of allowed listed devices = 4. INFO: Configuration Manager: API configuration download complete.

      So maybe my problem is a certificate problem in some way? Thanks!

      Reply

Leave a Comment