Friday 4 March 2016

IKEv2 with iOS - issues and workarounds


Apple added support for IKEv2 VPN connections in iOS8 but only via mobileconfig profiles and added further support in iOS9 so you could define an IKEv2 profile in the GUI on the iOS device itself. (Apple also added IKEv2 support to OS X in El Capitan.)

Note: IKEv2 is considered much more modern and secure than previous older VPN standards such as IPSec, L2TP, and PPTP. Hence the fact Apple added support for IKEv2 and my using it.

While I have now successfully got an iPhone running iOS 9.2.1 to connect via IKEv2 to a matching IKEv2 VPN server I did come across a bug along the way which I have now reported to Apple. Obviously in getting it working I managed to get round these problems.

A common method for generating mobileconfig profiles for use with iOS devices is Apple Configurator. Apple Configurator 1.7.2 for Yosemite supports defining an IKEv2 profile but only for iOS clients, Apple Configurator 2.1 for El Capitan supports creating an IKEv2 profile for both iOS and Macs.

The issue I hit with Apple Configurator is that both the Yosemite version and the El Capitan version add an entry in the mobileconfig as standard which caused a conflict with my IKEv2 VPN server and prevented the iOS device from successfully connecting. The entry is in the IPv4 section and is a flag called OverridePrimary and AppleConfigurator sets this to be 'true' i.e. 1. This flag apparently tells the VPN client it must send all network traffic via the VPN connection including 'normal' traffic that needs to go to Internet connected sites, e.g. web browsing traffic. There is nothing wrong with wanting this to happen and in fact most corporates using IKEv2 would want that, however at least in my case this setting conflicts with settings in my IKEv2 VPN server which itself is already set to force all VPN clients to send all traffic via the VPN, this conflict causes the connection attempt to fail.

Note: I am using StrongSwan 5.1.2 on a Linux server as the VPN server.

To workaround this problem after identifying it I had to manually edit the mobileconfig file produced by Apple Configurator and delete the following section.

  1.      <key>IPv4</key>  
  2.      <dict>  
  3.           <key>OverridePrimary</key>  
  4.           <integer>1</integer>  
  5.      </dict>  

As my IKEv2 server is set to force all traffic via the VPN connection that still happens but this time with the above deleted from the mobileconfig the connection succeeds.

Unfortunately the Apple Configurator user interface does not list this option and hence does not itself allow disabling it if as in my case this turns out to be needed. Hence the need to manually edit the mobileconfig file. While investigating this issue I discovered that the old iPhone Configuration Utility which I had previously been using for Cisco IPSec configurations (being old it does not support IKEv2 configurations) does add the same OverridePrimary setting but sets it to 0 i.e. off and hence this is why I have not seen this problem before.

Note: Even though iPhone Configuration Utility set the setting to be 0 i.e. off because my StrongSwan5 setup has its own rule to force all traffic to go via the VPN connection this did indeed still as desired successfully force all traffic to go via the VPN connection. It should also be noted that the majority of example StrongSwan5 configurations include the same rule to force all traffic to go via the VPN connection which is to include the following in /etc/ipsec.conf

leftsubnet=0.0.0.0/0

This as should be obvious to anyone who has had to deal with configuring routers for a while means include every single IP address as the destination.


Now that I have got IKEv2 'working' on iOS I will move on to trying this in El Capitan and see how many bugs Apple have managed to include there. 

2 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete