ikev2 with certificates: bug or not?

I have now managed to upgrade my StrongSwan setup to add IKEv2 support and done some initial testing with an iPhone running iOS 9.2.1. I initially tried manually configuring a profile on the iPhone and hit what I believe a bug which I am in the middle of working with Apple regarding, I then tried a profile generated using Apple Configurator and hit a different problem and was able to find a solution to. This second issue might be what you can others are experiencing in El Capitan.

First some background, I have my StrongSwan setup to force all traffic to be sent via the VPN connection, this is done using

sysctl net.ipv4.ip_forward=1

and adding the following to ipsec.conf

leftsubnet=0.0.0.0/0

Note: The above works fine with IKEv1 aka. IPSec and the same iPhone, although the profile I used for IPSec was generated using the old iPhone Configuration Utility.

The profile generated by Apple Configurator however adds the following XML to the mobileconfig file.

<key>IPv4</key>
<dict>
    <key>OverridePrimary</key>
    <integer>1</integer>
</dict>

As far as I can tell from the Apple documentation, the above is supposed to tell the Mac/iOS client to send all traffic via the VPN connection. One might hope that at best this would simple duplicate the rules on the StrongSwan server however with this in the mobileconfig file I am finding that the iPhone immediately disconnects when I attempt a connection which sounds the same as your problem in El Capitan.

When I manually edited the mobileconfig and removed the above and then resent it to the iPhone and tried again it was then successful in making an IKEv2 connection.

I therefore suggest you try doing the same thing and report back here.

I tried what you suggested above, removing the lines from my profile.mobileconfig and reinstalled it again. Sadly, that didn't work either.

What does work is a IKEv2 connection with Pre-Shared Keys. I tested this on OS X El Capitan and iOS 9, no issues at all. So i think that the problem is related to the Certificates and/or Keychain Access. It might be a problem with the profile import or the access rights on the certificate/private key in Keychain. This is something i need to debug a little more.

For what it's worth, below the ipsec.conf server config:

##### strongSwan 5.2.1 #####

config setup

uniqueids = yes

conn server

keyexchange=ikev2

ikelifetime=60m

keylife=20m

rekeymargin=3m

keyingtries=1

ike = aes256-sha256-modp1024!

esp = aes256-sha256-modp1024!

left=<external ip server>

leftid=<external ip server>

leftsubnet=0.0.0.0/0

leftfirewall=yes

leftcert=/etc/ipsec.d/certs/vpn.crt

leftauth = pubkey

conn clients

rightauth = pubkey

rightsourceip = 10.10.10.0/24

rightdns=8.8.8.8

right=%any

auto=add

I had a look at your ipsec.conf and compared it to mine and have the following comments.

It is recommended to use uniqueids=never especially with regards to iOS clients

I found that for clients connecting over the O2 mobile phone network I needed to include fragmentation=yes

It is recommended to include leftsendcert=always however this does not apply to PSK setups

By the way, your posted config seems to me to be for a cert based auth setup not a PSK setup.

Based on your posted config I presume you have configured your VPN clients to use a Remote ID of <external ip server> i.e. the IP address of your VPN server. It would also probably be a good idea to include that either in the CN of the server certificate or the SAN (Subject Alternate Name) of the certificate. I use the hostname of the server.

@John Lockwood: the config i posted was indeed for the certificate authentication, not for the pre-shared keys. I only explained that PSK authentication does work, which was for me a way to narrow down the problems. It confirms at least that IKEv2 does work on OS X, without certificate authentication.

I also changed/added the suggestions you posted to the server config, but that didn't help. I will keep these lines in the config for now.

uniqueids = never

rightauth = pubkey

fragmentation=yes

The Remote ID is indeed the external IP address from the VPN server. The IP is also included as a SAN on the VPN certificate. See me PKI setup at the end of this reply.

@marcony96: i was aware of the the issues. I'm using the SAN email address as Local ID: client@domain.tld. I also changed the LogLevel preferences, which actually gave me some new information:

Mar 10 12:29:19.000 imac kernel[0] <Notice>: ipsec_ctl_connect: creating interface ipsec0

Mar 10 12:29:19.635 imac configd[53] <Notice>: network changed

Mar 10 12:29:19.726 imac neagent[98543] <Error>: Received error: Error (Authentication Failed)

Mar 10 12:29:19.726 imac neagent[98543] <Error>: Failed to process IKE Auth packet

If "authentication failed" is the actual problem, i assume (again) this has something todo with the way the certificates are imported into the Keychain.

I'm not sure in which keychain the certs/key have to be imported:

- Login

- Local items

- System

- System Roots

Also, do i have to "Always Trust" the certificates for all applications. And do i also give "Full Access" to the private key for all applications?

Below you can see how i did setup the PKI. I'm not new to PKI and i know it has to work, because the same certs do work in Windows and Linux.

Note: 11.22.33.44 and vpn.example.com are ofcourse not the real IP/hostname.

# change working dir

cd /etc/ipsec.d

# create root cert/key

ipsec pki --gen --type rsa --size 4096 --outform pem > private/ca.key

ipsec pki --self --ca --lifetime 3650 --in private/ca.key --type rsa --digest sha256 --dn "C=US, O=Example, CN=Root CA" --outform pem > cacerts/ca.crt

# create server cert/key

ipsec pki --gen --type rsa --size 2048 --outform pem > private/vpn.key

ipsec pki --pub --in private/vpn.key --type rsa | ipsec pki --issue --lifetime 3650 --cacert cacerts/ca.crt --cakey private/ca.key --digest sha256 --dn "C=US, O=Example, CN=vpn.example.com" --san vpn.example.com --san 11.22.33.44 --san @11.22.33.44 --flag serverAuth --flag ikeIntermediate --outform pem > certs/vpn.crt

# create client cert/key

ipsec pki --gen --type rsa --size 2048 --outform pem > private/client.key

ipsec pki --pub --in private/client.key --type rsa | ipsec pki --issue --lifetime 3650 --cacert cacerts/ca.crt --cakey private/ca.key --digest sha256 --dn "C=US, O=Example, CN=client@domain.tld" --san client@domain.tld --flag clientAuth --outform pem > certs/client.crt

ipsec pki --pub --in private/client.key --type rsa | ipsec pki --issue --lifetime 3650 --cacert cacerts/ca.crt --cakey private/ca.key --digest sha256 --dn "C=US, O=Example, CN=client@domain.tld" --san client@domain.tld --flag clientAuth --outform pem > certs/client.crt

# export client cert/key + ca cert to PKCS#12 file (password protected)

openssl pkcs12 -export -inkey private/client.key -in certs/client.crt -name "client@domain.tld" -certfile cacerts/ca.crt -caname "Root CA vpn.example.com" -out exports/client.p12

With regards to importing certificates and to which keychain, if you want the certificate to be available to the entire machine (Mac) then it should be in the System keychain, I do use the System keychain myself. If you want a certificate to apply to a single user then it should be in their login keychain and an example here would be an S/MIME certificate which clearly is for an individual user.

If you are using Profile Manager or similar to push profiles containing certificates then if you push the profile via a device group it gets added to the System keychain, if you push it via a User group it gets added to (each individual user) login keychain.

The System Roots keychain should normally never be modified, it is supplied by Apple and updated by Apple.

I'm using Apple Configurator 2 to setup the profiles. Added the PKCS#12 file to the certificates payload. When installing the profile, it does indeed install the certificates and private key in the Login keychain. Below the current Keychain settings:

Client Certificate = Use System Defaults

Client Private Key = Access Control > Confirm before allowing access (and some applications are always allowed to access)

CA Certificate = Always Trust

I finally got IKEv2 with Certificate Authentication working. On OS X El Capitan and iOS 9. The actual fix was what John Lockwood suggested in an earlier post. To add the following setting on the server side:

leftsendcert=always

Also "leftsendcert=yes" does it as well. But i'll stick to "always" for now.

As explained in a previous post, i used Apple Configurator 2 to create the profiles. On the certificate tab i used client.p12 (PKCS#12), which contains the client certificate, client private key and the Root CA certificate. On OS X the certificates and the private key are installed correctly. However, on iOS it only installs the client certificate and private key. It DOES NOT install the Root CA certificate, even though it is bundled in the same file.

In Apple Configurator 2, at the certificates tab, you can add mulitple certificate payloads. So to make the profile work on iOS devices, you'll need to include the Root CA certificate as a separate certificate payload. Again, even while there is already a client.p12 file which contains the Root CA certificate as well.

For the sake of completeness, below is my ipsec.conf for IKEv2 with Certificate Authentication:

##### strongSwan 5.2.1 #####

config setup

uniqueids = never

conn %default

keyexchange=ikev2

ikelifetime=60m

keylife=20m

rekeymargin=3m

keyingtries=1

fragmentation=yes

ike = aes256-sha256-modp1024!

esp = aes256-sha256-modp1024!

left=%any

leftid=<external IP address or FQDN from server>

leftsubnet=0.0.0.0/0

leftfirewall=yes

leftcert=/etc/ipsec.d/certs/vpn.crt

leftsendcert=always

leftauth = pubkey

conn clients

rightauth = pubkey

right=%any

rightsourceip = 10.10.10.0/24

rightdns=8.8.8.8

auto=add

We also encountered the problem with "Certificate authentication data could not be verified" message for some of our Mac OS El Capitan clients, but all our iOS and Android (strongSwan) clients connected fine. After troubleshooting, we discovered that Mac OS didn't validate the full certificate chain (intermediate certificates).

We're running the IPsec strongSwan server on pfSense configured with IKEv2 EAP-MSChapv2 (user+password authentication). The server is configured with a Comodo PositiveSSL certificate, with two intermediate certificates between our certificate and the root certificate http://i.imgur.com/rdGzIFW.png One thing we missed during configuration, was that the strongSwan needs the intermediate certificates as well. This was solved by exporting the two certificates (see screenshot above) and placing in /etc/ipsec.d/cacerts/ (or in the case of pfSense, importing both certificates as CA Certificates in the Certificate Manager and simply restarting the IPsec service, since this automatically copies the certs to the proper ipsec.d/cacerts directory).

The problem could also be solved by manually importing the two intermediate certificates to the client Mac OS Login Keychain (no custom trust settings).

On MacOS Sierra the System always try to connect with EAP but i set ikev2/certificate on the client

Nov 21 12:50:31 tor charon[2682]: 10[CFG] selected peer config 'clients'

Nov 21 12:50:31 tor charon[2682]: 10[IKE] peer requested EAP, config inacceptable

Nov 21 12:50:31 tor charon[2682]: 10[CFG] no alternative config found

Nov 21 12:50:31 tor charon[2682]: 10[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding

Nov 21 12:50:31 tor charon[2682]: 10[IKE] peer supports MOBIKE

Nov 21 12:50:31 tor charon[2682]: 10[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]

----------------------------ipsec.conf------------------------------------------ --

config setup
# charondebug="dmn 2,mgr 2,ike 2,chd 2,job 2,cfg 2,knl 2,net 2,asn 2,enc 2,imc 2,imv 2,pts 2,tls 2,esp 2,lib 2"
ca server
cacert=/etc/ipsec.d/cacerts/cacertpublic.pem
auto=add
uniqueids = never

conn %default

keyexchange=ikev2

ikelifetime=60m

keylife=20m

rekeymargin=3m

keyingtries=1

fragmentation=yes

# ike = aes256-sha256-modp2048!

# esp = aes256-sha256-modp2048!

left=%any

leftid=test.server.com

leftsubnet=0.0.0.0/06

leftfirewall=yes

leftcert=/etc/ipsec.d/cert.pem

leftsendcert=always

leftauth = pubkey

conn clients

rightauth = pubkey

rightsourceip = 10.10.10.0/24

rightdns=8.8.8.8

auto=start

You can't set up x509 certificate authentification in the GUI of OSX but via a profile generated with Apple Configurator its possible.