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

« Previous - Version 44/67 (diff) - Next » - Current version
Mirek Svoboda, 22.04.2015 12:23
Clarification of --enable-cisco-quirks

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

IKEv2 on iOS 8 and newer

Since iOS 8 (but not OS X 10.10) IKEv2 is natively supported on Apple clients. For such devices 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 supports native IPsec VPN via IKEv1 (otherwise referred to as Cisco IPSec in iOS) and is 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 iOS client is not provided by Cisco but is actually a modified version of Racoon.

Authentication uses XAuth and certificates (authby=xauthrsasig). Authentication without certificates may fail due to an attempt on the iOS side to use aggressive mode. The described setup has been tested and confirmed working on an iPad 2 with iOS 4.3.1, but is expected to work on all other iOS devices (iPhone, iPad, iPod Touch) running an up to date iOS version.

Mac OS X

The configuration here also works well with Mac OS X (tested with 10.7.3 and 10.7.4). Anything special is mentioned below where appropriate.

Certificate requirements for iOS 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 VPN 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.

Certificate examples using strongSwan PKI tool

This example uses the strongSwan PKI tool to set up a certificate authority (CA), server, and client certificates. The openssl utility is used to package the CA certificate, client certificate, and client key in a PKCS#12 file.

CA certificate

ipsec pki --gen --outform pem > caKey.pem
ipsec pki --self --in caKey.pem --dn "C=CH, O=strongSwan, CN=strongSwan CA" --ca --outform pem > caCert.pem

Server (strongSwan VPN gateway) certificate

ipsec pki --gen --outform pem > serverKey.pem
ipsec pki --pub --in serverKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem \
          --dn "C=CH, O=strongSwan," --san="" \
          --flag serverAuth --flag ikeIntermediate --outform pem > serverCert.pem

Note: the serverAuth and iKEIntermediate extended key usage flags are not required for authentication with an iOS client, but will allow Windows 7 and (older) Mac OS X clients to authenticate using the same server certificate.

Client (iOS) certificate

ipsec pki --gen --outform pem > clientKey.pem
ipsec pki --pub --in clientKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem \
          --dn "C=CH, O=strongSwan, CN=client" --outform pem > clientCert.pem

PKCS#12 file

openssl pkcs12 -export -inkey clientKey.pem -in clientCert.pem -name "client" \
               -certfile caCert.pem -caname "strongSwan CA" -out clientCert.p12

Install certificates

The certificates and keys should be placed in the appropriate directories under /etc/ipsec.d/

cp caCert.pem /etc/ipsec.d/cacerts/
cp serverCert.pem /etc/ipsec.d/certs/
cp serverKey.pem /etc/ipsec.d/private/

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

cp clientCert.pem /etc/ipsec.d/certs/
cp clientKey.pem /etc/ipsec.d/private/

The clientCert.p12 and caCert.pem files can either be placed on a web server for download to an iOS device using Safari or sent to an iOS device via email. Although the PKCS#12 file also includes the CA certificate, iOS does not use this CA certificate so it must be installed separately. The installed certificates will reside under Settings > General > Profiles on the iOS device.

For Mac OS X, open and import the clientCert.p12 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.

The caKey.pem file should be moved somewhere safe.

Final notes

The names server and client may be changed as desired. The Distinguished Name (DN) should be changed to relevant values for country (C), organization (O), and common name (CN) while keeping in mind the iOS requirements for the server certificate.

strongSwan configuration for a single iOS client

Connection definitions

# /etc/ipsec.conf - strongSwan IPsec configuration file

config setup

conn ios

With the new strongswan 5.x branch the pfs parameter has been removed and the PFS default set to disabled.

Authentication with RSA and XAuth

# /etc/ipsec.secrets - strongSwan IPsec secrets file

: RSA serverKey.pem
somexauthaccountname : XAUTH "somexauthpassword" 

Assignment of internal DNS servers

# /etc/strongswan.conf - strongSwan configuration file

# for strongSwan 5.0.0+
charon {
  dns1 =

# for strongSwan < 5.0.0
pluto {
  dns1 =

strongSwan configuration for multiple clients

For multiple clients you can either generate a private key/certificate pair for every client or you use a single private key/certificate pair for all clients. The client authentication will then only be based on XAuth. And even though the private key/certificate pair is "public" this still ensures proper authentication of the gateway, but might simplify deployment to clients.

If each client has its own certificate simply remove the rightcert line from the config above, any client providing a valid certificate will then be accepted. You could also specify a wildcard value for rightid to accept specific clients (e.g. if you have multiple configs), for instance:

        rightid="C=CH, O=strongSwan, CN=*" 

To assign each client its own virtual IP use a subnet for rightsourceip like:


iOS client configuration

The root certificate (CA), client certificate, and client key should all be present on the iOS device. A PKCS#12 file should provide both the client certificate and key. A separate file will need to be used to install the CA certificate since iOS does not use the one included with the client PKCS#12. These certificate files can be transferred via email or downloaded from a web server using Safari. An alternative option is to use the Apple Configurator utility which can package the VPN configuration, certificates, and key into a single file.

Here is a description for configuring the VPN connection from the device itself once the certificates have been installed:

  • Launch Settings then select General > Network > VPN > Add VPN Configuration
  • Toggle VPN type to IPSec
  • Fields:
    Description      strongSwan
    Account          somexauthaccountname
    Password         somexauthpassword
    Use Certificate  ON
    Certificate      client

A VPN connection should now be possible by toggling VPN to ON under Settings > VPN.

Mac OS X client configuration

Open System Preferences > Network > click the + sign to add the connection > Choose Interface "VPN" and VPN Type "Cisco IPSec".

Then enter the information

Server Address
Account Name     somexauthaccountname
Password         somexauthpassword

and select the installed system certificate under Authentication Settings.

Troubleshooting 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

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. Another alternative is to use IKEv2, but OS X currently does not have a native client.

External references