IKEv2 security association continually re-established when using iOS 10, strongSwan 5.3.5

[evanchaney]

OS / Environment

• iPhone SE, iOS 10.3.1 (14E304)
• strongSwan 5.3.5
• Ubuntu server 16.04.2 LTS
• Digital Ocean (droplet created by Algo @ 27e0fd0)

Ansible version

• ansible 2.2.0.0

Version of components from requirements.txt

• setuptools 34.3.2
• ansible 2.2.0.0
• dopy 0.3.5
• boto 2.46.1
• boto3 1.4.4
• azure 2.0.0rc5
• msrest 0.4.1
• apache-libcloud 1.5.0
• six 1.10.0
• pyopenssl 16.2.0
• jinja2 2.8

Summary of the problem

strongSwan 5.3.5 when used with iOS 10 results in continual
re-establishment of the IKEv2 security association between the iOS
device and charon daemon. Re-association happens anywhere from
several times per minute to several times per hour.

When used on an everyday device with many services setup (email,
calendaring, background app refreshing) an apparent effect is
significantly decreased battery life on the iOS device (2x difference
observed between the IKEv2 VPN configuration and a non-IKEv2 VPN
configuration). No effect has been observed on the ability to retrieve
data over the VPN, however.

In one instance 51 re-associations were observed over 18 minutes.

Steps to reproduce the behavior

1. Install strongSwan 5.3.5 on Ubuntu 16.04 LTS using Algo.
2. Enable charon logging to /var/log/charon.log (set append=yes in
   strongswan.conf, adjust AppArmor profile to allow access to
   /var/log/charon.log, reload AppArmor profile and restart
   strongswan).
3. Perform restore of iOS 10.3.1 onto an iOS device. Set up device as
   new device (no restore from backup).
4. Attach device to a Wi-Fi network.
5. Install Algo IKEv2 VPN configuration profile.
6. Let device go to sleep and remain in sleep.
7. Observe the IKEv2 server sends the device dead-peer-detection
   notifications and receives no response. After several retries the
   IKEv2 server terminates the IKE security association requiring the
   iOS device to re-establish it and the child SA. Observe the issue
   repeats continuously.

The way of deployment (cloud or local)

• Droplet on Digital Ocean

Expected behavior

• iOS device responds to dead-peer-detection request from IKEv2
  server. IKEv2 server retains the IKE SA between the server and
  client.

Actual behavior

• iOS device does not respond to dead-peer-detection request. IKEv2
  server re-attempts the DPD check 5 times then deletes the IKE SA
  between iOS device and IKEv2 server.

Possible resolutions

It is not clear if the root cause lies in iOS or strongSwan:

https://wiki.strongswan.org/issues/2126

However, strongSwan states the issue is resolved in strongSwan 5.5.1.
Modifying Algo to install strongSwan from source rather than APT would
allow for installation of a specific (newer) version of strongSwan.

Alternatively, modifying Algo to allow the choice of Ubuntu image
used would make it possible for the installer to get a newer version of
the strongSwan package by using a non-LTS version of Ubuntu (17.04).

It may be possible to work around the issue by configuring the charon
keepalive/DPD rate to occur at a higher rate than iOS so iOS
is always the DPD initiator. This has not yet been explored.

charon.logs

• everyday-device.log
• restored-device.log

[evanchaney]

This issue has also been reported to Apple under Radar 31649808.

[dguido]

Thanks for such a detailed finding! I was under the impression that Ubuntu 16.04 uses strongSwan 5.1.2 and that Ubuntu 17.04 upgraded to 5.5.1. I think this issue only affects Ubuntu 16.10?

[evanchaney]

As best I can tell from Ubuntu’s sometimes-odd package versioning both 16.04 and 16.10 use strongSwan 5.3.5. It wasn’t until 17.04 that the package was upgraded to 5.5.1.

Digital Ocean’s default Ubuntu droplet uses 16.04.

[evanchaney]

Also, it does appear that increasing the dpddelay to 30 minutes is an effective workaround.

[dguido]

Ah yes, Ubuntu 16.04 uses 5.3.5 now.

root@algo:~# dpkg -s strongswan
Package: strongswan
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 168
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: all
Version: 5.3.5-1ubuntu3.1
Depends: strongswan-charon, strongswan-starter
Description: IPsec VPN solution metapackage
 The strongSwan VPN suite uses the native IPsec stack in the standard Linux
 kernel. It supports both the IKEv1 and IKEv2 protocols.
 .
 This metapackage installs the packages required to maintain IKEv1 and IKEv2
 connections via ipsec.conf or ipsec.secrets.
Homepage: http://www.strongswan.org
Original-Maintainer: strongSwan Maintainers <pkg-swan-devel@lists.alioth.debian.org>

It looks like we'll have to test the workaround of modifying the dpddelay. We may investigate changing the base install to Ubuntu 17.04 in the near future.

[jackivanov]

Here is some info

[jackivanov]

The patch above keeps iphone connected in the sleep mode

[dguido]

@evanchaney Is disabling dpd entirely a good solution for you?

[evanchaney]

@evanchaney Is disabling dpd entirely a good solution for you?

That does mitigate some of the re-association churn, yes. However, disabling DPD checks may have other adverse effects.

With the dead-peer-detection delay set above the child security association lifetime my everyday device has delivered longer battery life and IKE security association initializations are down.

However, my phone continues to start new IKE SAs when it doesn’t seem like it should need to. In the first hour of starting a new Algo VPN instance it initiated about 1 new IKE SA per minute even though the server was not terminating the existing SA.

As a result, the server issued 62 of its 255 virtual IPs in the first hour. (I also had 2 other devices associated.)

Without performing dead-peer checks the server might run out of private IPs to assign to clients.

The issue could be further complicated if the user uses the same VPN identity across multiple devices. It appears iOS 10 may send an INITIAL_CONTACT notification in each IKE_INIT_SA request indicating any previous IKE SAs from that identity should be closed.

When using a laptop and a phone concurrently with the same identity each device’s session would continually be reset.

I haven’t yet confirmed or isolated the cause of these new observations, but if they are bugs or behaviors of iOS’ IKEv2 client turning off DPD checks rather than just raising the interval could have adverse effects like IP depletion.

I’ll continue trying to isolate and identify the behaviors I’m seeing.

[jplock]

Would it make sense to enable dead peer detection, but only on zesty?

when: ansible_distribution_release == 'zesty'

I can submit a PR for this if we can do this.

[jackivanov]

We don't support Zesty yet. In progress #449

[davidemyers]

Since this has been re-opened I'll add a few more observations on using strongSwan 5.5.1 with iOS 10.

I spent some time trying many different permutations of uniqueids, dpdaction, and dpddelay and still had issues with iOS devices having trouble reconnecting when more than one device was connected. A single device seems to reconnect successfully.

Also, when a device is struggling to reconnect I see no logging output from charon. It's like IPsec occasionally fails to listen for new connections right after a connection is established, but that's just a guess.