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`).
  • If a rightsourceip IPv6 pool is specified, leftsubnet must include a default IPv6 route (::/0) or no routes will be correctly added.

IKEv2 on iOS 8

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.

IKEv1

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.

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, when the traffic matches the traffic selector.

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, CN=vpn.strongswan.org

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

subjectAltName = DNS:vpn.strongswan.org

where in the above cases vpn.strongswan.org 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, CN=vpn.strongswan.org" --san="vpn.strongswan.org" \
          --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 Keychain.app 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

conn ios
    keyexchange=ikev1
    leftauth=pubkey
    leftsubnet=0.0.0.0/0
    leftfirewall=yes
    leftcert=serverCert.pem
    right=%any
    rightauth=pubkey
    rightauth2=xauth
    dpdaction=clear

conn client
    also=ios
    rightsourceip=10.0.0.2
    rightcert=clientCert.pem
    auto=add

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 = 192.168.0.1
}

# for strongSwan < 5.0.0
pluto {
  dns1 = 192.168.0.1
}

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:

        rightsourceip=10.0.0.0/24

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
    Server           vpn.strongswan.org
    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   vpn.strongswan.org
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

iOS_VPN_client.jpg (22.4 KB) Lars Hjersted, 16.05.2011 00:33