This section covers common error messages that you may encounter while working with VMware Tunnel and the procedure to fix the root cause of the problem.

Device configuration error

When the Tunnel VPN profile is not installed on the device, end users might see Device Not Configured when they try to open a Tunnel client.
  1. In the UEM console , navigate to the Device Detail page of the affected device and click the Profiles tab to confirm if the Tunnel VPN profile is installed.
  2. For all the Android devices, open the Workspace ONE Intelligent Hub and under the Profiles section, check if the Tunnel VPN profile exists.
  3. For all iOS devices, navigate to Settings > VPN and verify the VPN configuration details.

TLS Handshake Failure

You encounter this error if the SSL certificate present on the device does not match with the certificate on the server or if the certificate is not valid.
  1. In the UEM console, navigate to the Tunnel configuration page and verify the Front-End Certificate Thumbprint under server Authentication.
  2. For all the Android devices, open the Workspace ONE Intelligent Hub and under the Profiles section, verify the certificate thumbprint for the Type.cer.
    1. For all the iOS devices, navigate to Settings > General > Device Management> Device Manager.
    2. Click More Details and under the Certificate section, click the certificate with the Tunnel hostname.
  3. Scroll down to the SHA-1 text box and verify the certificate thumbprint.
  4. On the server side, open /opt/vmware/tunnel/vpnd/server.conf and search for ssl_thumbprint.
  5. Verify if the thumbprint on the device, server, and the UEM console is the same. If not, restart the vpnd service on the UEM console and republish the VPN profile.

DNS Resolution Failure

You might encounter DNS resolution error if the Tunnel server FQDN does not get resolved to an IP address.

  1. From the device connected network,ensure that the Tunnel server FQDN resolves to an IP address.
  2. In the command prompt, enter the following command: nslookup <Tunnel_Server_FQDN>. Tunnel server FQDN resolves to an IP address.

Unable to Reach the Tunnel Gateway

You may not be able to reach the Tunnel gateway if device is unable to communicate with the Tunnel server on the mentioned port.

  1. From the device connected network, ensure that the device connects to the Tunnel server on the port that is mentioned in the tunnel configuration.The device must get connected and display the Tunnel server Front-end SSL certificate.
  2. In the command prompt, enter the following command:
    openssl s_client -connect <dest_fqdn>:<port> -servername
              <server_fqdn>
    .
  3. In the Tunnel server, enter the following command: netstat -tlpn

    The server must display the port that is mentioned in the tunnel configuration.

  4. In the Tunnel server, enter the following command: systemctl status vpnd. The service must be active and running.
    Note:
    • Verify the Firewall and the load balancer rules.
    • SSL Offloading and SSL Bridging are not supported for the Per-App Tunnel component.

Access Denied Error

You might encounter access denied error if the device details are not present on the Tunnel server or when the device is non-compliant.

  1. Open the Workspace ONE Intelligent Hub and verify the complaince status.
  2. Navigate to the Device detail page for the affected device and verify the device complaince status.
  3. From the /opt/vmware/tunnel/vpnd directory, run ./vpnreport whitelist --udid=<Device_udid>.In the result xml, the ComplianceStatusId must be 3 or 5 for the affected device UUID.
    Note: The connection between the Tunnel server and the API server connection must be successful to achieve the expected result.

No Apps Assigned

You might encounter the No Apps Assigned error within the Workspace ONE tunnel application when the managed application is not mapped with the VMware VPN profile.

  • Navigate to the internal or the public application under Apps & Books and check for the device in the assignment group where the App Tunneling is enabled.

Unable to access Internal sites from managed apps through the VPN

Intranet websites are not accessible from the Tunnel Server.

  1. Ensure that you can access the internal websites from the tunnel server. If it is a Cascade mode, the internal site must be accessible from the Backend server.
  2. Ensure that all the application binaries are whitelisted for the VPN.For example, applications like VMware Horizon Client and Microsoft Outlook might have multiple binaries that need to be whitelisted.

Device Traffic Rules is not sent to the devices

Device Traffic Rules control how traffic is directed through the VMware Tunnel when using the Per-App Tunnel component. These rules allow you to tunnel, block, or bypass traffic as needed. In some scenarios, the updated Device Traffic Rules is not sent to the devices. When the administrator changes the Device Traffic Rules and click Save, the Device Traffic Rules gets mapped to the profile, but the updated Device Traffic Rules is not replaced for the devices where the VPN profile is already installed. Device Traffic Rules is only updated for the newly enrolled devices or for the devices that have the VPN profile reinstalled.

To send the updated Device Traffic Rules to the devices post modifying the Device Traffic Rules, administrators must click Save and Publish. Save and Publish adds a version to the VPN profile and republishes Device Traffic Rules to all the devices.

Note:

  • If the adminsitartor changes the Android application in the Device Traffic Rules and clicks Save and Publish, the VPN profiles for both iOS, Android profiles gets a version update and the VPN profile installs are queued for all the assigned devices.
  • Reinstalling the profile reissues the client certificate to the device with a new thumbprint.

VPN-Managed Application fails to honor Device Traffic Rules on Overriding the Device Traffic Rules

VPN-managed application fail to honor the Device Traffic Rules on overriding the Device Traffic Rules rules for the Child OG. The VPN profile fails to map the correct Device Traffic Rules configuration.

  • Make sure that you create the application and the VPN profile at the OG level which has the traffic rules that are overridden.

Unable to view internal and public applications under the Device Traffic Rules application list

Internal and public applications are not displayed under the Device Traffic Rules application list.

You might encounter this issue if the VPN profile is not mapped with the correct Tunnel Configuration.

  1. Navigate to Profile > List View.
  2. Select the profile that is mapped to the application and click VPN Payload. Verify the Tunnel server configuration.
  3. If the Tunnel not configured message is displayed, click Add version and remove the VPN payload.
  4. Add a new VPN Payload.

Tunnel Server is not up to update with respect to the Compliance Change Events

Devices fail to honor compliance policy updates.

You might encounter this issue if the device compliance change event fails to reach the Tunnel server.

  1. In the Workspace ONE UEM console, navigate to All Settings > System > Advanced > Site Url.
    1. Verify the AirWatch Cloud Messaging connection.
  2. Perform the Tunnel test connection from the Tunnel configuration page.
  3. From the Tunnel server, verify the service status by running the following commands:
    1. systemctl status vpnd.
    2. systemctl status vpnreportd.
      Note:
      If you have multiple AirWatch Cloud Messaging that uses implicit clustering, configure the load balancer to use the cookie persistence that routes the AirWatch Cloud Messaging traffic.

Tunnel Front-End server fails to communicate with the Back-End server

Due to the incorrect network configuration or usage of an incorrect certificate for the server-client authentication, you might experience a communication failure between the Tunnel Front-End server and the Back-End server.

  1. Ensure that the Front-End server can communicate with the Back-End Tunnel server on the port mentioned in the tunnel configuration.
  2. Run the following command in the Tunnel Front-End server :
    openssl s_client -connect <dest_fqdn>:<port> -servername
              <backend_fqdn>
    .Must display the Tunnel Back-End server SSL certificate.
  3. In the server.conf file, verify the following:

    On the Tunnel, front-end server verify if the c_r_t (that is, cascade_root_thumbprint ) has the thumbprint of the Back-End server's SSL certificate.

    1. The c_r_t in the Tunnel front-end server is same as the cascade_back_end_thumbprint in the Back-end server.

    On the Tunnel back-end server c_r_t should have the root CA's thumbprint of the Tunnel front-end server's SSL certificate.

    1. When the AirWatch certificate is used for Server Auth, the c_r_t in the back-end server is always same as the ssl_thumbprint in the Tunnel front-end server.
    2. When a third-party SSL certificate is used for Server Auth, the c_r_t in the back-end server is the third party's root CA's thumbprint.
  4. Verify if there are any firewall or load balancer rules blocking between the Front-End server to Back-End Tunnel Server.
    Note:
    • SSL Offloading and SSL Bridging are not supported for the Per-App Tunnel configuration.
    • If you are using Public certificate for the server authentication, the certificate must have a Server and Client authentication under Enhanced Key Usage field .

Unable to load and add Device Traffic Rules and Server Traffic Rules in the Tunnel configuration Page

When you load the Tunnel configuration page, Tunnel Configuration doesn't exist is displayed and you may not be able to add Device Traffic Rules or Server Traffic Rules.

  1. Open the Internet Information Services (IIS) Manager on the API server.
    1. In the Windows Start menu, click Administrative Tools > Internet Information Services (IIS) Manager.
  2. In IIS Manager, under Connections, expand your server name, and then expand Sites.
  3. Right-click on a website, and click Edit Bindings.
  4. In the Site Bindings window, select the http/https binding for this website, and click Edit.
  5. In the Edit Site Binding window, keep the hostname blank , and click OK.
  6. Restart the IIS sites for the changes to take effect.
  7. Alternatively, instead of clearing the IIS bindings hostname and keeping the hostname blank, you can complete the following steps:
    1. Update the Tunnel microservice appsettings.json's Host key under the AirWatchApiClient to include the hostname that is used in the IIS bindings.
      "AirWatchApiClient": {
          "Host": "acme.example.com",
          "ClientTimeoutInSeconds": 40,
          "HostDiscoveryTimeoutInSeconds": 30,
      	"Port": 8081
      Note: The port key will only be used if the customer is using a custom port.
    2. Restart the Airwatch Tunnel Service
    3. Refresh the browser if you are using the Tunnel configuration screen after the service restart.

Verify VMware Tunnel Microservice

You can use the VMware Tunnel health endpoint to verify the upstream or downstream connectivity to the VMware Tunnel microservice.

  1. Use the following REST API to get the VMware Tunnel microservice health from Workspace ONE UEM API Explorer.
    GET {environment}/api/mdm/tunnel/health
    aw-tenant-code: API key configured
    Basic auth
    
  2. Verify the API response of VMware Tunnel health endpoint.
    200 ok
    { 
     "api_to_tunnel_microservice_connectivity": "True", 
     "tunnel_microservice _to_api_connectivity": "True", 
     "database_connectivity_status": "True" 
    }

Unable to upload third-party SSL certificate

You may not be able to upload third-party SSL certificate when the third-party library currently used for the encryption/decryption (BouncyCastle) fails to read the certificate password due to a pad block corrupted issue.
  1. Import the non-working certificate onto the windows certificate store on the app server of the console where this issue is seen.
  2. Once imported, export the certificate from the store with the same password if required. The exported certificate will be available on your local machine on the path you chose to save it.
  3. Use this exported certificate for uploading on the third-party server authentication tab of the Tunnel configuration. The certificated should upload successfully and the Tunnel config can be saved.