Tunneling

Using MobileIron’s AppTunnel feature, a secure enterprise app can securely tunnel HTTP and HTTPS network connections from the app to servers behind a company’s firewall. A Standalone Sentry is necessary to support AppTunnel with HTTP/S tunneling. The MobileIron server administrator handles all HTTP/S tunneling configuration on the server. Once the administrator has configured tunneling for the app on the server, the AppConnect for iOS Wrapper Library, the MobileIron client app, and a Standalone Sentry handle tunneling for the app.

Consider the following information to ensure that your wrapped app can successfully tunnel network connections:

• AppTunnel supports only NSURLConnection and NSURLSession

• Accessing sockets directly does not use AppTunnel

• AppTunnel supports redirects and authentication requests on HTTP/S upload

• AppTunnel support in Xamarin apps

• AppTunnel with TCP tunneling

• When to make network requests when using AppTunnel

AppTunnel supports only NSURLConnection and NSURLSession

An app accesses its enterprise servers as it normally would using URL requests, using the iOS APIs NSURLConnection and NSURLSession.

Note The Following:  

• AppTunnel with HTTP/S tunneling does not support using NSURLSession in a background session. The traffic does not reach its destination.
• Apps can also use networking libraries that use NSURLConnection or NSURLSession. For example, apps can use AFNetworking 3.0 because it uses NSURLSession.
• An app that uses WKWebView cannot use AppTunnel with HTTP/S tunneling.

Accessing sockets directly does not use AppTunnel

AppTunnel with HTTP/S tunneling is not supported if the app:

• accesses sockets directly.

• uses APIs that access sockets directly.

In these cases, the app cannot access a host behind the enterprise’s firewall using AppTunnel with HTTP/S tunneling.

For example, AppTunnel with HTTP/S tunneling is not supported with the following APIs:

• Apple’s reachability APIs that detect network and host connectivity

• CFNetwork APIs

• ASIHTTPRequest

NOTE:

Network connections using sockets for TCP connections can tunnel data by using AppTunnel with TCP tunneling. See AppTunnel with TCP tunneling.

AppTunnel supports redirects and authentication requests on HTTP/S upload

When an app uses AppTunnel with HTTP/S tunneling, AppTunnel handles the following HTTP/S upload scenarios:

• HTTP/S redirect responses from the network server (HTTP/S 3XX status code).

  If a network server redirects an HTTP/S upload request (tunneled or not) to another URL that the MobileIron server administrator has configured for tunneling, the request is tunneled.

• Authentication required response from the network server (HTTP/S 401 status code).

  The AppTunnel feature handles sending a second HTTP/S request with authentication credentials.

AppTunnel support in Xamarin apps

Apps built with the Xamarin development platform are written in C#. They can access network servers various ways. AppTunnel with HTTP/S tunneling is supported only as follows:

• The app uses the NSURLConnection or NSURLSession APIs exposed to C# through the Xamarin.iOS binding.

• The app uses the ModernHttpClient library with NSURLSession. The ModernHttpClient library with CFNetwork will not work.

  For example, the app initializes the instance of the ModernHttpClient as follows:

  	var httpClient = new HttpClient (new NativeMessageHandler ());

AppTunnel with TCP tunneling

AppTunnel can tunnel TCP traffic between an app and a server behind the company’s firewall. AppTunnel with TCP tunneling does not require an app to be an AppConnect app; both AppConnect apps and standard apps can use AppTunnel with TCP tunneling. The MobileIron server administrator configures AppTunnel with TCP tunneling, including installing MobileIron Tunnel (an iOS app) on the device.

When to make network requests when using AppTunnel

If a wrapped app makes HTTP/S network requests before the AppConnect library in the app has received the AppTunnel rules from the MobileIron server, the network requests will fail for URLs behind the enterprise’s firewall.

When this occurs, an app should try the request again. For example, the app can try the request again after some time has elapsed, or the next time it becomes active.

Alternatively, an app can wait to make a network request until after the AppConnect library has received the AppTunnel rules. An AppConnect wrapper callback method is available for the app to know when the rules have been received. See Callback method involving network requests with AppTunnel.