iOS and macOS

IKEv2 on iOS 9+ and macOS 10.11+

Since the release of iOS 9 and macOS 10.11 ("El Capitan"), IKEv2 is supported by three different methods:

  • Manually through the Settings app on iOS or System Preferences on macOS

  • With a custom configuration profile

  • Through an app that has the NetworkExtension entitlement

The Windows IKEv2 server configurations can be used with some small changes:

  • When configuring clients manually without profile, strongSwan’s default proposals should work fine with recent iOS/macOS versions. If you like to manually specify proposals (e.g. to use PFS, see below), note that modp2048 and sha2 are supported at least since iOS 14. So the following proposals may be configured (if necessary, combined with further algorithms/proposals for other clients):

    ike=aes256-sha256-modp2048
esp=aes256-sha256

    If you want to use PFS for CHILD_SAs, be aware that only iOS sends a proposal with DH group (and a second one without), by default, macOS only sends one without. So to support PFS with iOS clients without failing to rekey with macOS clients, configure something like this to make the DH group optional (note that such proposals, with optional DH groups, are the default since version 6.0.2):

    ike=aes256-sha256-modp2048
esp=aes256-sha256-modp2048-modpnone

    Also note that only iOS sends a proposal with ecp256, by default. And while it also sends one with modp1536, that might not work due to an unfixed bug, so using modp2048 or ecp256 should be preferred. Refer to the following proposal lists for details.

    Default IKE/ESP proposals sent by iOS/macOS

    iOS (as of 16.5)

    IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ

    When rekeying IPsec SAs (the DH group in the first proposal is presumably the one selected for IKE):

    ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ

    macOS (as of 13.4)

    IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048

ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ

    When rekeying IPsec SAs:

    ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ

  • The client does not send a certificate request (CERTREQ) unless ServerCertificateIssuerCommonName is configured in a configuration profile, whereas strongSwan does not send certificates without it with the default value of connections.<conn>.send_cert = ifasked. Therefore, explicitly set connections.<conn>.send_cert = always.

  • Since iOS 13 and macOS 10.15, a subjectAltName (SAN) is required that matches the server’s IKEv2 identity. The CN field is not relevant anymore in that regard. Additionally, the TLS Server Authentication flag has to be set in the server certificate (use --flag serverAuth with pki --issue).

  • iOS clients configured manually in the UI, i.e. without configuration profile, don’t seem to accept ECDSA server certificates (while macOS clients accept them). So make sure to use an RSA certificate if manually configured iOS clients should be able to connect (e.g. for Certbot and Let’s Encrypt, use --key-type rsa).

  • If an IPv6 pool is specified in connections.<conn>.pools, local_ts must include a default IPv6 route (::/0) or no routes will be correctly added.

  • 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 macOS 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 (25) and is supported by iOS 10.3.1 and newer. Alternatively, 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 newer) or by supplying it in the client configuration.

  • iOS and MacOS support EAP-MSCHAPv2, EAP-TLS, but not EAP-GTC

Certificate Requirements

As noted above, the domain name or IP address of the server (strongSwan VPN gateway) MUST be contained in a subjectAltName extension (SAN) that can be added with the --san option when using pki --issue or 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 e.g. the iOS client configuration.

To support macOS versions before 10.7.4, the certificate must contain the iKEIntermediate Extended Key Usage (EKU) flag.

Refer to the certificate quickstart as a tutorial on how to create certificates using the pki tools.

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, they need a certificate and a private key packaged in 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 macOS, open Keychain.app and import the PKCS#12 (or CA certificate) file into the System keychain (not login), then mark as Always Trusted. If you’re having trouble with the negotiation, check that all applications are allowed to access the private key in the Access Control tab.

Troubleshooting IKEv2 on macOS

To collect IKEv2 logs on macOS, use the process:NEIKEv2Provider search filter in Console.

Logs can also be viewed or followed in Terminal with the following commands:

log show --predicate 'process == "NEIKEv2Provider"'
log stream --predicate 'process == "NEIKEv2Provider"'

Troubleshooting IKEv2 with iOS

To get access to the logs of an iOS device, you need a Mac running macOS 10.12 or newer. After connecting and trusting the device, it can be selected from the Devices list in the Console app. To see more messages, enable Include Info Messages and Include Debug Messages in the Action menu. Accessing iOS logs is also possible via Xcode and Apple Configurator.