marcony96

Q: ikev2 with certificates: bug or not?

Hi,

 

I am tryting to test IKEv2 VPN connection, that is using certificates for authentication. Client should be on MAC or iPhone/iPad. As I encountered some issues, I looked over community and found some posts that describe the problem just the same as I encountered.

 

So, before making any programming, I wanted to be sure that IKEv2 VPN can be established, using "clean" OS (without anything but the clean installation). Furthermore, I tried to configure VPN connection through OS built-in dialogs, and/or through Apple-Configurator created VPN profiles. Unfortunatelly, neither of these methods was successful.

 

On MAC, when trying to establish VPN connection, I am getting errors like:

 

...

Feb  5 10:26:59 132 nesessionmanager[9447]: Failed to find the VPN app for plugin type com.apple.neplugin.IKEv2\

Feb  5 10:26:59 132 neagent[9824]: IKEv2 Plugin: ikev2_dns_callback: Error -65554\

...

 

On iOS, a little bit different:

 

...

Feb  6 10:48:49 Gorans-iPhone nesessionmanager[3427] <Notice>: NESMIKEv2VPNSession[srxapple:B853702D-A36D-4D70-A780-5A28FDE4C449]: Received a start command from Preferences[3681]

Feb  6 10:48:49 Gorans-iPhone nesessionmanager[3427] <Notice>: NESMIKEv2VPNSession[srxapple:B853702D-A36D-4D70-A780-5A28FDE4C449]: status changed to connecting

Feb  6 10:48:49 Gorans-iPhone nesessionmanager[3427] <Error>: Plugin com.apple.neplugin.IKEv2 does not have a bundle URL

Feb  6 10:48:49 Gorans-iPhone neagent[4003] <Error>: IKEv2 Plugin: ikev2_dns_callback: Error -65554

...

 

Within the community, same errors are already reported, but it seems that nobody found solution for that. If I understand well, this is not programming issue, but OS bug, or installation bug, whatever.

 

The question is: Why the system cannot find VPN app for the plugint, which seems to be within OS. Looking through out the MAC filesystem, I am able to find /System/Library/Frameworks/NetworkExtension.framework/Versions/A/Resources/Plug inIKEv2.vpnplugin/Contents/Info.plist and relating files, so it seems that plugin is there, but the question is: is it at the right place, or is something missing?

 

On iOS, error is a little bit different, and reports that plugin does not have bundle URL. I do not understand meaning of that error.

 

Anyone can help with this? Any workaround that might help? Is there anyone that could open support request (feature request, whatever it is called), as I am not able to do that? I would appreciate any help with this issue?

 

BTW, I am reporting this issue on El Capitano (latest release), as well as on iOS 9.2.1

iPad, iOS 9.2.1

Posted on Feb 7, 2016 9:30 AM

Close

Q: ikev2 with certificates: bug or not?

  • All replies
  • Helpful answers

Previous Page 2
  • by twrx,

    twrx twrx Mar 8, 2016 2:01 PM in response to marcony96
    Level 1 (0 points)
    Mar 8, 2016 2:01 PM in response to marcony96

    I'm running into similar issues with IKEv2 and Certificate Authentication on OS X El Capitan 10.11.3. The VPN server runs strongSwan 5.2.1. To confirm that this is not a server-side problem: the Windows and Linux clients are connecting fine.

     

    I used the Apple Configurator 2 tool to create a profile. After importing the profile and trying to connect, OS X establish the VPN connection but immediately deletes it.


    It seems that OS X is unable to create the actual interface/tunnel. Below the related logs from /var/log/system.log:

     

    Mar  8 22:03:42 macbook kernel[0]: ipsec_ctl_connect: creating interface ipsec0

    Mar  8 22:03:42 macbook configd[54]: network changed

    Mar  8 22:03:42 macbook neagent[5781]: BUG in libdispatch client: kevent[EVFILT_READ] delete: "Bad file descriptor" - 0x9

    Mar  8 22:03:42 macbook kernel[0]: SIOCPROTODETACH_IN6: ipsec0 error=6

    Mar  8 22:03:42 macbook configd[54]: network changed

    Mar  8 22:03:42 macbook symptomsd[226]: nw_interface_create_with_name netutil_ifname_to_ifindex(ipsec0) failed, dumping backtrace:

                [x86_64] libnetcore-583.20.10

            0   libsystem_network.dylib             0x00007fff988b5ba5 __nw_create_backtrace_string + 123

            1   libsystem_network.dylib             0x00007fff988d6acb nw_interface_create_with_name + 179

            2   Network                             0x00007fff8b25602c -[NWInterface initWithInterfaceName:] + 120

            3   SymptomEvaluator                    0x00007fff97c9e918 config_callback + 874

            4   SystemConfiguration                 0x00007fff9bc60fbf rlsPerform + 184

            5   SystemConfiguration                 0x00007fff9bc743bb __SCDynamicStoreSetDispatchQueue_block_invoke_2 + 52

            6   libdispatch.dylib                   0x00007fff8b574871 _dispatch_call_block_and_release + 12

            7   libdispatch.dylib                   0x00007fff8b56933f _dispatch_client_callout + 8

            8   libdispatch.dylib                   0x00007fff8b56df6f _dispatch_queue_drain + 754

            9   libdispatch.dylib                   0x00007fff8b57463b _dispatch_queue_invoke + 549

            10  libdispatch.dylib                   0x00007fff8b56cc87 _dispatch_root_queue_drain + 538

            11  libdispatch.dylib                   0x00007fff8b56ca34 _dispatch_worker_thread3 + 91

            12  libsystem_pthread.dylib             0x00007fff92ee468f _pthread_wqthread + 1129

            13  libsystem_pthread.dylib             0x00007fff92ee2365 start_wqthread + 13

    Mar  8 22:03:42 macbook symptomsd[226]: -[NWInterface initWithInterfaceName:] nw_interface_create_with_name(ipsec0) failed, dumping backtrace:

                [x86_64] libnetcore-583.20.10

            0   libsystem_network.dylib             0x00007fff988b5ba5 __nw_create_backtrace_string + 123

            1   Network                             0x00007fff8b256096 -[NWInterface initWithInterfaceName:] + 226

            2   SymptomEvaluator                    0x00007fff97c9e918 config_callback + 874

            3   SystemConfiguration                 0x00007fff9bc60fbf rlsPerform + 184

            4   SystemConfiguration                 0x00007fff9bc743bb __SCDynamicStoreSetDispatchQueue_block_invoke_2 + 52

            5   libdispatch.dylib                   0x00007fff8b574871 _dispatch_call_block_and_release + 12

            6   libdispatch.dylib                   0x00007fff8b56933f _dispatch_client_callout + 8

            7   libdispatch.dylib                   0x00007fff8b56df6f _dispatch_queue_drain + 754

            8   libdispatch.dylib                   0x00007fff8b57463b _dispatch_queue_invoke + 549

            9   libdispatch.dylib                   0x00007fff8b56cc87 _dispatch_root_queue_drain + 538

            10  libdispatch.dylib                   0x00007fff8b56ca34 _dispatch_worker_thread3 + 91

            11  libsystem_pthread.dylib             0x00007fff92ee468f _pthread_wqthread + 1129

            12  libsystem_pthread.dylib             0x00007fff92ee2365 start_wqthread + 13

  • by John Lockwood,

    John Lockwood John Lockwood Mar 8, 2016 2:17 PM in response to twrx
    Level 6 (9,394 points)
    Servers Enterprise
    Mar 8, 2016 2:17 PM in response to twrx

    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.

  • by twrx,

    twrx twrx Mar 9, 2016 1:52 PM in response to John Lockwood
    Level 1 (0 points)
    Mar 9, 2016 1:52 PM in response to John Lockwood

    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

  • by John Lockwood,

    John Lockwood John Lockwood Mar 10, 2016 2:19 AM in response to twrx
    Level 6 (9,394 points)
    Servers Enterprise
    Mar 10, 2016 2:19 AM in response to twrx

    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.

  • by marcony96,

    marcony96 marcony96 Mar 10, 2016 2:31 AM in response to twrx
    Level 1 (0 points)
    Mar 10, 2016 2:31 AM in response to twrx

    I would suggest, that you increase log level on iOS / OS X, and take a look in (possible) errors before the error that you mentioned in some of previous messages (inability to create sec tunnel). On link https://forums.developer.apple.com/message/104213#104213 you can find details how to increase log level (considering networking). I was using Log profile sent by Apple support, that works the same way as described on link above.

     

    Furthermore, I'll repeat what I got from Apple Support (maybe helps):

     

    • iOS / OS X IKEv2 does not support using ASN1DN format for localIdentifier, yet!
    • the localIdentifier (client side) must match the CN or SAN of the client cert!
    • the remoteIdentifier (or ServerCertificateCommonName) must match the CN or SAN of the VPN server cert

     

    Marcony

  • by twrx,

    twrx twrx Mar 10, 2016 3:56 AM in response to marcony96
    Level 1 (0 points)
    Mar 10, 2016 3:56 AM in response to marcony96

    @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

  • by John Lockwood,

    John Lockwood John Lockwood Mar 10, 2016 4:02 AM in response to twrx
    Level 6 (9,394 points)
    Servers Enterprise
    Mar 10, 2016 4:02 AM in response to twrx

    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.

  • by twrx,

    twrx twrx Mar 10, 2016 5:31 AM in response to John Lockwood
    Level 1 (0 points)
    Mar 10, 2016 5:31 AM in response to John Lockwood

    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

  • by twrx,

    twrx twrx Mar 10, 2016 2:10 PM in response to twrx
    Level 1 (0 points)
    Mar 10, 2016 2:10 PM in response to twrx

    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

  • by alleus,

    alleus alleus Jun 1, 2016 12:27 AM in response to marcony96
    Level 1 (4 points)
    Jun 1, 2016 12:27 AM in response to marcony96

    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).

Previous Page 2