App traffic allowed through Tunnel VPN (Android native and Android enterprise)

When a Tunnel VPN session is created, the Tunnel configuration is provided to the Android operating system. The Tunnel configuration includes information such as allowed and disallowed apps, routes, and domain name servers. Android enforces access to Tunnel, based on the provided configuration. The apps that use MobileIron Tunnel is determined by the allowed and disallowed configuration. You configure either an allowed list or a disallowed list.

  • Allowed: Only the apps that are on the allowed list (whitelist) have access to Tunnel. Traffic from all other apps is not allowed to go through Tunnel and goes through the device network.
  • Disallowed: All apps have access to Tunnel, except the ones on the disallowed list (blacklist). Traffic from the disallowed list goes through the device network.

Ensure that you have configured either an allowed app list or a disallowed app list. If an allowed list is not configured, MobileIron strongly suggests adding at least the following to a disallowed list to avoid OS traffic going through Tunnel VPN:

  • Mobile@Work if your UEM is MobileIron Core (com.mobileiron)
  • MobileIron Go if your UEM is MobileIron Cloud (com.mobileiron.anyware.android)
  • Android play store (com.android.vending)
  • Google Play Service (com.google.android.gms)
  • Carrier Service (com.google.android.ims)
  • (For Samsung devices) Samsung Experience Service (com.samsung.android.mobileservice)
  • All apps that have been enabled by default in the “Allow App while Data Saver On” or “Unrestricted data access” list under the data saver settings. These are mandatory apps required for the Android system.

In addition, the following also determine how an app uses Tunnel:

Tunnel routes and MobileIron Tunnel for Android

During the creation of the VPN session, configured routes are set to the TUN interface. If the administrator did not configure any routes in Tunnel configuration, Tunnel uses 0.0.0.0/0. The configured routes are used in the following ways:

  • Only traffic from apps that can use Tunnel goes through the configured routes.
  • You cannot configure a different set of routes for different allowed apps.
  • Traffic from non Android enterprise apps or to disallowed Android enterprise apps does not go through the routes configured for Tunnel.

DNS servers and MobileIron Tunnel for Android

DNS requests coming from allowed apps are resolved by the domain name servers (DNS) configured for the VPN during the VPN creation session. These servers are different from the DNS for the original Wi-Fi or cellular connection.

In addition, the Tunnel SplitDomain feature allows you to use two different domain name servers to resolve DNS requests, based on the requested domain. The two domain name servers typically are the DNS configured for the device network and the DNS configured for VPN.

Always-on Tunnel VPN and MobileIron Tunnel for Android

On Android 5 and 6 devices, always-on is a MobileIron implementation. The feature is enabled by default. You can configure by using the key appRunningCheckIntervalSec, which configures the check interval.

On Android enterprise devices running Android N (7.0) and through the most recently released version as supported by MobileIron, Google provides the always-on feature. You can configure the Google implementation of always-on VPN in the Android enterprise (Android for Work) configuration in MobileIron Core and in the Always-on configuration in MobileIron Cloud.

Connection recovery for MobileIron Tunnel for Android

If a connection fails, Tunnel tries to reconnect periodically, by default. Tunnel makes three quick attempts at one-second intervals, and then at one-minute intervals. Tunnel attempts to reconnect when there is a network status change or there is a configuration change. Tunnel will also attempt to reconnect if Standalone Sentry times out due to TCP idle time. If Tunnel is idling, Standalone Sentry closes the TCP connection. In this case, Tunnel will attempt to reconnect. The recommended idle timeout is one hour.

You can configure connection recovery using the following keys: quickRetryMaxAttempts, quickRetryIntervalSec, slowRetryIntervalSec.