Best Practices & Limitations for developing iOS applications leveraging per app VPN using VMware Tunnel

Use high level "connect by name" APIs like URLSession

To support VPN On Demand you must use some sort of connect by name API. These includes CFSocketStream and anything layered on top of that (including URLSession). Doing separate resolve then connect is usually more work and is incompatible with VPN On-Demand.

Note: BSD Sockets does not have a connect by name API. Therefore, try to avoid using these if your app is going to leverage AirWatch per-app Tunnel solution.

Boxer over per-app VPN is not currently supported, however, it is on the roadmap. 

 

It is not recommended to set up your own DNS resolution

When working with VPN in general, it is recommended to not set up your own DNS resolution. The system DNS resolver has lots of smarts to cope with all sorts of odd situations, and those situations often crop up in a VPN scenario. For example, a company example.com might have two DNS servers:

Example:

An external DNS server, that contains a limited set of DNS records for their public ’net presence

(like www.example.com)

An internal DNS server, that contains a larger set of DNS records for all their internal systems

(like human-resources.example.com)

Their VPN is configured such that the system DNS resolver uses the internal server for example.com when the VPN is up. If you, as an app developer set up your own DNS resolution, this will not work.

 

iOS Reachability API

As mentioned in the Designing for Real World Networks article, a network call should always be made using a high level API such as the NSStream or NSURL API families. Either API family will trigger the per-app VPN correctly. For more expanse, refer to the “Design for Variable Network Interface Availability” section of the provided link.

After the recommended network call is made, whether it be a successful or failed attempt, you can make the native Reachability to determine the state of the VPN interface and further troubleshoot if necessary. If a failure is encountered, you can use the results of the Reachability event to trigger a subsequent connection, if necessary or allow the application to operate in offline mode.

In either situation, the proper use of the recommended API families may eliminate the need for the native Reachability calls altogether based on the system level response depending on the amount of detail needed.

Note: Failure to make a network call prior to the Reachability call may result in inconsistent workflows when attempting to trigger or engage Per-App VPN protocols.

 

 

Xamarin based application

Xamarin supports three protocols for HTTP Client implementation namely:

  1. Managed
  2. CFNetwork
  3. NSURLSession.

Managed stack is Microsoft's native implementation using BSD sockets and is not compliant with per-app VPN framework as it uses low level DNS APIs and cannot trigger on-demand VPN. Please make sure to choose either CFNetwork or NSURLSession to make sure that the application works with per-app VPN. 

This stack can be changed in Xamarin IDE under Project options>Build>iOS Build>HttpClient Implementation.

 

Generic best practices for iOS networking

Numerous best practices have been outlined in Apple’s article on Avoid Common Networking Mistakes. Developers should make sure to follow them while doing networking in their iOS Application.

Have more questions? Submit a request

0 Comments

Article is closed for comments.