iOS (Apple iPhone/iPad...) and macOS Interoperability » History » Version 63

« Previous - Version 63/67 (diff) - Next » - Current version
Noel Kuntze, 24.01.2019 19:24
replace ` with @

iOS (Apple iPhone, iPad...) and Mac OS X

IKEv2 on iOS 9 & OS X 10.11 and newer

With the release of iOS 9 and OS X 10.11 ("El Capitan"), IKEv2 is now supported by three different methods:

  • Manually through the Settings app on iOS or System Preferences on OS X
  • With a custom configuration profile
  • Through an app that has the NetworkExtension entitlement

The Windows IKEv2 configurations can be used with some small changes.

  • For manual configurations, specify only DH group 2 (modp1024) in the ike configuration. Although the iOS client claims to support modp1536, an unfixed bug prevents these connections from succeeding. An appropriate configuration for Windows and iOS might look like:
    ike=aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024! # Win7 is aes256, sha-1, modp1024; iOS is aes256, sha-256, modp1024; OS X is 3DES, sha-1, modp1024
    esp=aes256-sha256,aes256-sha1,3des-sha1! # Win 7 is aes256-sha1, iOS is aes256-sha256, OS X is 3des-shal1
  • The client does not send a certificate request (CERTREQ) unless ServerCertificateIssuerCommonName is configured in a configuration profile, and strongSwan does not send certificates without it with the default value of leftsendcert=ifasked. Therefore, set leftsendcert=always (assuming your responder is left).
  • At least Mac OSX clients require that the ID of the server is authenticated by the CN field of the server certificate's DN, as well as a SAN value. Additionally, the TLS Server Authentication flag has to be set in its certificate (--flag serverAuth in ipsec pki).
  • If a rightsourceip IPv6 pool is specified, leftsubnet must include a default IPv6 route (::/0) or no routes will be correctly added.
  • Under certain hibernation-related conditions, OSX clients may forget a child SA without closing it. Setting a short dpd delay can clear these SAs before the waking client builds another child SA and thus aid in retaining the same virtual IP address.
  • Split-DNS can be implemented for iOS 10.3.1 and newer with the INTERNAL_DNS_DOMAIN attribute and the INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attributes.
    Support for MAC OSX isn't known at the moment.
    For older versions, all traffic has to be tunneled (full-tunnel).
    However, the latter doesn't work for any application, because none honor scoped DNS servers. A magic number for the INTERNAL_DNS_DOMAIN has been assigned by IANA and is supported by iOS 10.3.1 and newer.
    Alternatively, the the DNS domains can be supplied in the client configuration.
  • Assigning DNS servers without full-tunnel can only be achieved by sending an INTERNAL_DNS_DOMAIN to the responder (for iOS 10.3.1 and nwer) or
    by supplying it in the client configuration.

IKEv2 on iOS 9 and iOS 10

When MOBIKE and DPD are enabled, charon piggybacks NAT-D notifications onto the DPD messages (empty informationals). iOS 9 and 10 do not respond to such messages.
This causes charon to regard the peer as unreachable and trigger the dpdaction. This can cause charon to delete the IKE_SA and associated CHILD_SA,
therefore closing the tunnel.

Available workarounds are to disable either DPD or MOBIKE by using mobike=no or dpdaction=none.
If dpd is disabled, an unreachable peer is not detected as such until it reconnects and the uniqueness policy (uniqueids in ipsec.conf, connections.<conn>.unique in swanctl.conf)
is set to replace the old connection of an identity with the new connection.
If an unreachable peer is not detected and a roadwarrior connection with a virtual IP pool i used, the pool will inadvertently fill up.
If mobike is disabled, the roaming experience of a peer can suffer.

This problem is fixed in the 2126-mobike-dpd branch in the git repository and in version 5.5.1 and later.

IKEv2 on iOS 8

Since iOS 8 (but not OS X 10.10) IKEv2 is natively supported on Apple clients. For such devices the roadwarrior responder IKEv2 configurations from the sane examples page or the Windows IKEv2 configurations we provide can be used.

Unfortunately, Apple has not yet updated the GUI, so IKEv2 connections have to be installed with a custom configuration profile.


iOS 4 and newer, and Mac OS X 10.7 and newer support native IPsec VPN via IKEv1 (otherwise referred to as Cisco IPSec in these clients) and are able to interoperate with strongSwan.

For StrongSwan version 4.6 and below: Despite the Cisco reference, the configure option --enable-cisco-quirks is not required as the client is not provided by Cisco but is actually a modified version of Racoon.

Authentication uses XAuth and certificates. Authentication without certificates may fail due to an attempt on the iOS side to use aggressive mode (which is possible to configure since 5.0.0 but is discouraged).

IKEv1 client and server configuration from the sane examples page
IKEv1 client and server configuration example

Behaviour with several subnets

Recent versions of iOS and Mac OS X will only establish SAs for the first subnet. The SAs for the other subnets are created on demand with separate Quick Mode exchanges, when the traffic matches the traffic selector.

Certificate requirements for interoperability

The domain name or IP address of the server (strongSwan VPN gateway) MUST be contained either in the subject Distinguished Name (DN) of the server certificate

C=CH, O=strongSwan,

or in a subjectAltName extension that can be added with the OpenSSL option

subjectAltName =

where in the above cases must exactly match the value entered in the Server field of the iOS client configuration.
If the certificate contains any subjectAltNames at all, one of them must match that value (a matching DN is not enough in this case).

Mac OS X appears to require the hostname/address in subjectAltName. To support versions before 10.7.4 the certificate must contain the iKEIntermediate extended key usage flag.

Refer to the simple CA how-to for example commands to create certificates using the pki utility.

It is not necessary to keep the client certificate(s) on the server, but it can be useful to use it as an ID (rightcert=clientCert.pem).

Client configuration

When using IKEv2 with EAP authentication (username/password) the CA certificate is required on the clients to verify the server certificate. If a certificate issued by CA that the clients already trust is used (e.g. one by Let's Encrypt) nothing has to be installed on the clients.

When using certificates to authenticate the clients, with either IKE version, they will need their certificate and private key, packaged into a PKCS#12 container, in addition to the CA certificate.

These files can either be placed on a web server for download to a client device using Safari or sent to it via email. Although the PKCS#12 file may also include the CA certificate, not all Apple clients will use it so it must usually be installed separately. On iOS devices the installed certificates will reside under Settings > General > Profiles.

For Mac OS X, open and import the PKCS#12 (or CA certificate) file into the System keychain (not login), then mark as "Always Trusted". If you're running into trouble with the negotiation, make sure that in the Access Control tab of the private key, all applications are allowed to access it.

IKEv1/ISAKMP reauthentication issues

Note: At least on Mac OS X 10.10 this seems not to be a problem anymore.

Both iOS and OS X trigger a ISAKMP reauthentication after a tunnel is up for ~45 minutes. When using XAuth, strongSwan re-requests username/password during ISAKMP reauthentication. The native client in some versions of OS X / iOS does not expect that and deletes the ISAKMP SA upon that request. In some versions it was caused by the client's inability to access the password originally used for XAuth authentication when reauthenticating the SA.

strongSwan insists on redoing XAuth during ISAKMP reauth. There is no cryptographic binding between the old and the new ISAKMP SA, so an attacker can take over a tunnel easily without knowledge of the XAuth password. One could argue that the client RSA private key is sufficient to validate the client, but it then makes no sense to use an additional username/password to authenticate the client in the first place. Additionally, some scenarios consider the client private key as public knowledge, and rely solely on the XAuth exchange, which is encrypted under a session securely authenticated by the server certificate.

As reauthentication can not be disabled on the client, there is no simple work-around for this issue. But at least on Mac OS X 10.10 this issue seems to have been fixed by Apple.

One feasible solution is to use xauth-noauth. It uses a fake XAuth exchange by sending just a success message, which the client also accepts during ISAKMP reauthentication. This implies that no password is required during the initial setup, but only the client RSA private key is used for authentication. The preferred solution is to use IKEv2.

Troubleshooting IKEv1 on Mac OS

sudo vi /etc/racoon/racoon.conf

Add in the top section:

log debug;
path logfile "/var/log/racoon.log";

Then, follow the logs:

tail -f /var/log/racoon.log