Using VMware Workspace ONE Tunnel in Per-App VPN mode with Domain Joined Windows clients

Last Updated April 26, 2023

The VMware Workspace ONE Tunnel app supports two methods of virtual private networking: per-device or per-app. When the Tunnel app is operating in per-device mode the VPN connects the operating system and every application and service on the device back to the corporate network.

Per-device VPN is what most VPN apps have been doing since the technology was invented. The risk with per-device VPN is that if a bad actor gains access to the laptop they have full access to all of the apps and all of the the corporate network.

Per-app VPN’s allow individual applications to VPN without requiring the entire device to connect back to the corporate network. If you are following zero-trust security principals where you want to provide the least amount of access to the corporate network as possible, per-app VPN continues to be the recommended approach.

The purpose of this blog is to demonstrate the 5 steps necessary to configure per-app VPN to allow Windows Active Directory joined machines to have line-of-site to the Domain Controller when using Per-App VPN Mode.

Special Note: The process described below is NOT intended to be used to join a computer to a domain. The domain join operations should already be completed.

Pre-requisistes required:

  • Microsoft Active Directory Domain Controller (AD)
  • Access to edit internal and external DNS records
  • Workspace ONE UEM Console version 2102 or higher (UEM)
  • VMware Unified Access Gateway Appliance (UAG)
  • VMware Tunnel for Windows client

There are 5 parts to the setup. Follow them in the order defined below:

  1. Ensure UAG has an internet facing DNS name
  2. Configure Tunnel in UEM Console
  3. Enable Tunnel on Unified Access Gateway
  4. Deploy the Workspace ONE Tunnel app to devices
  5. Deploy a VPN Profile to devices via the UEM Console

The remainder of this blog covers the 5 steps in detail.

Part 1: Set up a public/external facing DNS name for UAG

When the Vmware Tunnel application launches it will create a VPN tunnel using the public/external DNS name defined in the Unified Access Gateway configuration. In my lab I use as that DNS name. Many people have asked exactly how this part gets configured. If you need that assistance keep reading. If you don’t need this assistance, skip to Part 2.

Disclaimer: I am not a networking guru. There are dozens of different ways to configure DNS so treat this as one example.

In my lab I use a pair of Microsoft AD integrated DNS Servers. I have configured two forward lookup zones:

In the forward lookup zone I created a New Alias (CNAME) record named “vpn” that points back to the internal DNS name of the Unified Access Gateway. To configure the DNS records in your environment (using Windows Server 2022 as a guide) here are the steps:

  1. Login to a Windows Active Directory Domain Controller running DNS
  2. From the Windows Start Menu, on the right-hand pane of tiles, choose Windows Administrative Tools to launch the Control Panel > System and Security > Administrative Tools.
  3. Choose DNS to launch DNS Manager
  4. Expand Forward Lookup Zones
  5. In the existing Forward Lookup Zone create a new Host (A or AAA) record for the UAG and define the internal DNS name for the UAG and assign the UAG an internal IP address. Enable “Create associated pointer (PTR) record to create the Reverse Lookup Record
  6. If you need to, add a new Forward Lookup Zone by right-clicking on the Forward Lookup Zone and choose New Zone. For my lab this is where I defined
  7. With the New Zone created, right-click on the zone and create a New Alias (CNAME) record
  8. Click on the Refresh icon at the top of the DNS manager and confirm both the forward lookup zone and reverse lookup zone were successfully created.
  9. At this point it’s a good idea to use nslookup from another device on the subnet and validate DNS resolution is working properly by doing a lookup of the records you just created.

The previous steps allow your internal devices to find the UAG via DNS but you now need a method for the Internet to find your UAG via DNS. My public DNS provider hosts the DNS records that redirect the Internet to my network. Preferably this process involves a static public IP address, maybe a proxy server, or load balancer, or some other network magic. In my lab I use a Ubiquiti UDM Pro (UDMP) at the edge. When I deployed the UDMP, the device did not support more than one public IP address but software updates from Ubiquiti now allow this, I have just not gone back and changed it, so at the moment I’m using port forwarding. For port forwarding to function I need to create a public DNS name and an A record that points the Internet to the UDMP’s WAN interface.

While your public DNS hosting providers process will vary, navigate to the hosting providers admin portal and find Advanced DNS settings and create a new A Record that matches the name you defined in your DNS forward lookup zone. For example mine is and for the IP address, use the public IP address of your edge router, in my case it’s the WAN IP address of the UDMP. The key point here is that the host name defined in the Public DNS entry will become the name used in the configuration of the Vmware Tunnel service.

With the public A record created, head over to your routers configuration page for port forwarding and setup port forwarding. By default VMware Tunnel uses Port 8443 for Per-App VPN and Port 2020 for Proxy so I have 2 port forward rules. The destination IPs would be the internal IP address you previously defined in your internal DNS for the UAG.

Note: VMware announced end of support for the Proxy functionality of Tunnel, so Port 2020 is not something I would recommend moving forward with.

The end result of this configuration is that a device on the Internet looking for is now able to reach the internal IP address of the UAG to establish the connection.

Part 2: Configure the Tunnel in the UEM Console

With the Public DNS name from Part 1 now available for use the next step is to configure the Tunnel using the Workspace ONE UEM Console.

  1. In UEM Console choose Groups and Settings > Configurations > Tunnel
  2. Create your Tunnel.
    1. Deployment Type = Basic (Cascade is supported just not in use in my example)
    2. Hostname = the public DNS name you defined with your hosting provider. In my case it’s
    3. Port = 8443
    4. Server Authentication = Airwatch SSL
    5. Client Authentication = Airwatch SSL
    6. Networking = Enabled with “Default AWCM + API traffic via Server Traffic Rules
    7. Logging = Disabled
    8. Custom Settings not configured
    9. Save the configuration
  3. While you’re in the UEM settings configure the Device Traffic Rule Sets that enable Windows domain joined devices to function as if they were on the corporate LAN:
    1. Under the Device Traffic Rule Sets choose Edit to bring up the “Manage Traffic Assignments”
    2. Select the Default Assignment to bring up the Device Traffic Rules menu
    3. Choose “Manage Applications”
    4. Add the following 5 Windows applications:
This rule enables access to network shares like SYSVOL
This rule enables Group Policy to continue to function off network
This rule enables access to Netlogon
While not specific to domain join, this rule is helpful for accessing mapped network drives
This rule is not related to domain join, but is helpful for your IT Admins who need to use RDP for server management off network.

4. Now that the apps are created, from the Device Traffic Rules page choose Add Rule and add each of the apps to tunnel as illustrated below:

Configure Tunnel for your AD Domain name

5. Define the domain name in the Destination. For example I’m using a wildcard of *

6. Choose Save and Publish

Part 3: Enable Unified Access Gateway Tunnel

The next step is to link the UAG to the UEM Tunnel configuration. This is done using the UAG Admin portal:

  1. Launch the UAG admin portal from your web browser by opening https://yourUAGDNSname:9443/admin
  2. Under General Settings > Edge Service Settings > click Show and then click the Gear icon under Tunnel Settings
  3. Choose Enable Tunnel Settings
  4. Define the API Server URL in the format
    where xxx equals the UEM Console url.
    For example if UEM is use
  5. The API Server username and password is any account on the UEM server that has been granted API access rights. By default the role “Console Administrator” has this permission. Note that what you type here must match the login format used for UEM. In my lab that means the username typed in here is lab\bgarmon
  6. The Org Group ID also comes from the UEM server, find it by hovering over the OG name in the UEM Console and use the value found in “Group ID”
  7. The Tunnel Server Hostname is the PUBLIC DNS name you defined at the ISP. In my example it’s
  8. BEFORE clicking SAVE, I recommend to SSH into the UAG and tail the log files to confirm what happens next succeeds. If you have a typo in your config you won’t really see any indication in the UAG admin portal that something didn’t work but you’ll spot it immediately in the SSH logs if you do the following:
    1. From your SSH client, SSH as root to the UAG
    2. Type in (but do not press enter):

      tail -f /var/log/vmware/appliance-agent/appliance-agent.log

      The reason you can’t hit enter yet is that this log file doesn’t exist until the first time the SAVE button is pressed in the Tunnel Settings page.
    3. Make sure both SSH and Tunnel Settings page are visible on your screen at the same time. In the Tunnel Settings click SAVE and immediately switch to SSH and press enter to send the tail command. You should immediately see text scrolling in SSH. The screenshot below shows what you should be looking for to confirm success
  9. Flip back to the UAG General Settings page you should find a Green icon under the Edge Service Settings next to Tunnel.
  10. You’ve completed the UAG Tunnel Configuration. Next up are the Windows 10 device settings configuration.
SSH output for Tunnel Settings showing successful configuration

Part 4: Deploy the Windows Tunnel client app from UEM

A brief history lesson to make sense of the different Tunnel versions for Windows:

  • Versions 2.0 and below supports per-app VPN and MDM management
  • Version 2.1 through Version 2.1.X supports per-app VPN, MDM management and per-device VPN
  • Version 3.x is designed for stand alone uses cases where Workspace ONE UEM is not in use. This version supports per-app VPN and per-device VPN but NO MDM management – so don’t use this version for this configuration.
  • Version 23.02 is released as a combination of 2.x and 3.x allowing both MDM and standalone using the same client.

Make sure your UEM Console is updated to 2102 or higher. The instructions below were tested against the Tunnel version 23.02 using Per-App Tunnel. Consult VMware’s production documentation if you will be leveraging the full device based tunnel configuration for any configuration changes that might be required.

Note: VMware continues to release minor updates to the Tunnel client application so you’ll need to adjust the meta-data in the instructions below to match the latest version of the client you download.

  1. Download the most recent 23.02 version of VMware Tunnel for Windows from
  2. Browse and download an app icon for Workspace One Tunnel to use later in this process.
  3. In the UEM Console choose Apps & Books > Applications > Native > choose Add Application > Upload
  4. On the Edit Application fill out the tabs as follows:
    1. Details tab: Name > Change this to VMware Tunnel for Windows
    2. Details tab: Supported Processor Architecture: 64-bit
    3. Details tab: App Version: 23.02
    4. Details tab: Current UEM Version 23.02 (this might read Version if you are on a UEM build prior to 21.01)
    5. Files tab: App Uninstall Process: Custom Script Type: Input
    6. Files tab: App Uninstall Process: Uninstall Command:
      VMwareTunnelInstaller_23.02.exe /uninstall /Passive
    7. Deployment Options tab: Install Context: Device
    8. Deployment Options tab: How to Install > Install Command:
      VMwareTunnelInstaller_23.02 .exe /install /Passive /norestart
    9. Deployment Options tab: Admin Privileges > YES
    10. Deployment Options tab: Device Restart: User engaged restart
    11. Deployment Options tab: Number of days after which device automatically reboots: 0
    12. Deployment Options tab: Retry Count: 3
    13. Deployment Options tab: Retry Interval: 1
    14. Deployment Options tab: Install Timeout: 5
    15. Deployment Options tab: Installer Reboot Exit Code: 3010
    16. Deployment Options tab: Installer Success Exit Code: 0
    17. Deployment Options tab: When To Call Install Complete: Choose Defining Criteria and select Add select Criteria Type File Exists with a path of
      C:\Program Files\VMware\Workspace ONE Tunnel\VMwareTunnel.exe
      Version 23.02
    18. Images Tab: Choose Icon Tab > Upload an image file for Tunnel app
    19. Choose Save & Assign
    20. In the Assignment Distribution menu give it a name like “Tunnel for Windows Default
    21. Choose an Assignment Group
    22. Change the App Delivery Method to Auto
    23. Choose the Restrictions menu on the left and enable “Make App MDM Managed if user installed”
    24. Enable “Desired State Management”
    25. Choose Create
    26. Choose Save
    27. Choose Publish

For more information about client deployment options for Tunnel, VMware is now publishing a comprehensive guide to rolling out Tunnel which can be found on VMware’s TechZone by clicking here. Leverage the TechZone article for the most recent updates to this process.

Part 5: Create UEM Console Profile for VPN

Note that beginning with Tunnel version 3.0 the UEM console now supports providing Configurations and Device Traffic Rules through Configurations and not profiles. The instructions below assume you are using Tunnel 23.02 and the current Profile configuration.

  1. In the UEM Console choose Devices > Profiles & Resources > Profiles
  2. Choose Add > Add Profiles > Windows > Windows Desktop > Device Profile
  3. Under General give the profile a name and assign it a SmartGroup
  4. Choose the VPN payload and fill out the following:
    1. Connection Name: It now defaults to “Default VPN”
    2. Connection Type: Workspace ONE Tunnel
    3. Device Traffic Rule Sets: Default – Default
    4. Under Custom Configuration XML add the following XML which is how the Tunnel is configured to launch before the Windows 10 Login screen appears:
<?xml version='1.0' encoding='utf-16'?>

5. Configure the Trusted Network Detection to be the name of your domain. What this setting does is to ensure that when your device is on the trusted network, the Tunnel will not be established.

6. Under DNS Resolution via Tunnel Gateway you must define how DNS will be resolved. The end goal is to make Tunnel aware of when it will use the internal DNS servers. This area of the product has been enhanced in the latest UEM Console release so you now have two options to choose from: Enable Enhanced Domain Resolution, or Disable Enhanced Domain Resolution and define the Domains.

If you enable Enhanced Domain Resolution, Tunnel will read the Device Traffic Rules and use the Device Traffic Rules to define the domains. I suspect this may be a better method to use in production, but it’s a new setting I haven’t worked with much so experiment at will. In my example I set Enhanced Domain Resolution to Disabled and I’m defining * and in the domain list.

The end result of your profile should look similar to this (taken from Workspace ONE UEM Console 2102):

Windows 10 Device Profile for Custom Tunnel Configuration

Final Steps

Congratulations on completing the configuration. With this configuration in place Windows devices will be able to:

  • Map Network Drives
  • Establish RDP Sessions
  • Apply Active Directory Group Policy updates

10 thoughts on “Using VMware Workspace ONE Tunnel in Per-App VPN mode with Domain Joined Windows clients

  1. Hi there,

    thank you for this interesting article, if it works this would be exactly what I’ve been searching for.
    Is the version 2010 really the minimum for this? I’d like to test this with 2005.

    Is there any kind of documentation where this snippet is described for the pre logon connection and is this eventually the reason why it has to be version 2010?


    Thanks and greetings,


    1. Device Traffic Rules were re-designed both in the Server side configuration of them, and in how they are now applied to Personas, thus a newer console version of the Workspace ONE UEM Console is recommended.

      The pre-login connection is effectively telling the Tunnel Agent to load before a user logs onto Windows thus allowing the connection to be established before the user login.

  2. Thanks for sharing. It’s helpful. I’m trying to set it up but stuck in the step where ACC service > Properties > Logon tab and add AD username/password. After that, service won’t start. I’m getting error message related to logon info. When i removed the username/password, service can start. Cloud connector log shows error msg “query with error time out 12000”.

    Do you have any idea why? Thanks.

    1. Re-run through Part 7, starting at Step 7 which is where you set the permissions for the account. That it is not starting indicates you’ve got something wrong with the permissions set.

  3. Hi ,
    Thanks for the share.
    i got a small issue regarding connection to external website.
    I want to block all connection to website but access only for youtube for example but no success.
    I am using chrome enterprise and blocked * and Bypass *
    But still blocking youtube, any idea why?


  4. Regarding the least-privileged service account, what would be different in terms of the domain user delegate permissions if we are not using the ACC to create the computer objects but instead are requiring the end user machine for line of sight for both the domain join portion and the first time user logon portion of the unattend.xml configuration? I understand that the ACC ODJ is the recommended way to go, but given an environment where this method won’t be utilized, would we only need the “add workstations to the domain” permission to successfully perform the djoin.exe within the unattend.xml setting for On Premise AD Join, or does the service account also need to be able to create a computer object first? Since there is no ACC involved here I’m assuming we don’t stage and create a computer object prior to the domain join and instead we outright join the machine to the domain under the assumption that it will do so in the default Computers container. Is that the case here? Since the ACC is not staging the computer account, there is no blob file written to the WS1 UEM database correct?

    1. The Workspace ONE UEM Domain Join feature only works if you include the ACC. By removing ACC from the equation you can’t use the Domain Join Feature. What you can do without the ACC is use UEM to build a PKG that includes an unattended.xml file that allows you to do a domain join using what is called Drop Ship Provisioning Offline, but for DSP offline to be used in that scenario your devices need to be on the same LAN as the DC in order for the domain join to function.

      Your questions about changes to the delegate permissions and service account changes are not necessary if you are not going to leverage the UEM Domain join feature. And you are correct if you don’t use the Domain Join feature you won’t have any blob file written to the UEM database or anywhere else as there is nothing in UEM that will ever trigger djoin.exe to execute.

      1. Thanks! We are going to be using WS1 Tunnel app to initiate the PreLogon VPN using Device traffic rules as you’ve outlined in another article to establish the line of site without being on the corporate network. My question can be summarized by comparing 2 options. Option 1 uses ACC for ODJ with unattend.xml setting set to “Workgroup” since the ACC will handle the domain join portion via the staging of the computer object in the OU they have rights to do so and writing that blob to the WS1 UEM database. In this option, we need “create computer objects” and “join workstations to the domain”.
        Option 2 does not use ODJ but the unattend.xml setting would be set to “On-Premises AD Join” and instead just does a straight domain join presumably with the “join workstations to the domain” as long as line of sight is available via being on corporate LAN or via a PreLogon VPN solution such as Tunnel. Is is accurate to say option 1 requires 2 delegate permissions while option 2 requires 1 permission? The idea is to grant the least amount of privileges needed with option 2 if there is no writing of computer objects necessary, i.e., no (pre)staging of computer objects and a straightforward domain join. Appreciate any insight here.

        1. From what I’m reading the “Create computer objects” permission already includes the permission to join workstations to the domain without the need to explicitly grant the 2nd permission and also it is not impacted by the ms-DS-MachineAccountQuota default limit of 10:

          I’m also reading that setting ms-DS-MachineAccountQuota to 0 does not mean the ability for “Authenticated Users” to join an unlimited number of machines but “zero” and is the recommended way to go:

Leave a Reply

Your email address will not be published. Required fields are marked *