MacOs 10.12, Ikev2 - Disconnects after 8 minutes

gpit2286 · Sep 24, 2016, 10:47 PM

Hello -

I recently updated my computer to MacOS 10.12 and I'm having some issues. Originally, my problems came from the OS upgrade nuking my Cert. After fixing that, I can get connected but get kicked off every 8 minutes. The disconnect logs are below.

pfSense


Sep 24 15:30:35	charon		07[MGR] checkin and destroy of IKE_SA successful
Sep 24 15:30:35	charon		07[CFG] <con1|734>lease 192.0.2.1 by 'user@domain.com' went offline
Sep 24 15:30:35	charon		07[IKE] <con1|734>IKE_SA con1[734] state change: DELETING => DESTROYING
Sep 24 15:30:35	charon		07[MGR] <con1|734>checkin and destroy IKE_SA con1[734]
Sep 24 15:30:35	charon		07[NET] <con1|734>sending packet: from <pfsense ip="">[4500] to <my ip="">[32792] (60 bytes)
Sep 24 15:30:35	charon		07[ENC] <con1|734>generating INFORMATIONAL response 7 [ ]
Sep 24 15:30:35	charon		07[IKE] <con1|734>IKE_SA deleted
Sep 24 15:30:35	charon		07[IKE] <con1|734>IKE_SA con1[734] state change: ESTABLISHED => DELETING
Sep 24 15:30:35	charon		07[IKE] <con1|734>deleting IKE_SA con1[734] between <pfsense ip="">[invoice.onlyomega.com]...<my ip="">[172.16.27.254]
Sep 24 15:30:35	charon		07[IKE] <con1|734>received DELETE for IKE_SA con1[734]
Sep 24 15:30:35	charon		07[ENC] <con1|734>parsed INFORMATIONAL request 7 [ D ]
Sep 24 15:30:35	charon		07[NET] <con1|734>received packet: from <my ip="">[32792] to <pfsense ip="">[4500] (68 bytes)
Sep 24 15:30:35	charon		07[MGR] IKE_SA con1[734] successfully checked out
Sep 24 15:30:35	charon		07[MGR] checkout IKEv2 SA by message with SPIs 1cceb16bafdcce98_i 1b7908c27d0f2c56_r
Sep 24 15:30:35	charon		07[MGR] <con1|734>checkin of IKE_SA successful
Sep 24 15:30:35	charon		07[MGR] <con1|734>checkin IKE_SA con1[734]
Sep 24 15:30:35	charon		07[NET] <con1|734>sending packet: from <pfsense ip="">[4500] to <my ip="">[32792] (68 bytes)
Sep 24 15:30:35	charon		07[ENC] <con1|734>generating CREATE_CHILD_SA response 6 [ N(NO_PROP) ]
Sep 24 15:30:35	charon		07[IKE] <con1|735>IKE_SA con1[735] state change: CONNECTING => DESTROYING
Sep 24 15:30:35	charon		07[IKE] <con1|734>applying DH public value failed
Sep 24 15:30:35	charon		07[ENC] <con1|734>invalid DH public value size (256 bytes) for MODP_1024
Sep 24 15:30:35	charon		07[LIB] <con1|734>size of DH secret exponent: 1023 bits
Sep 24 15:30:35	charon		07[CFG] <con1|734>selected proposal: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Sep 24 15:30:35	charon		07[CFG] <con1|734>configured proposals: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Sep 24 15:30:35	charon		07[CFG] <con1|734>received proposals: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Sep 24 15:30:35	charon		07[CFG] <con1|734>proposal matches
Sep 24 15:30:35	charon		07[CFG] <con1|734>selecting proposal:
Sep 24 15:30:35	charon		07[IKE] <con1|734>IKE_SA con1[735] state change: CREATED => CONNECTING
Sep 24 15:30:35	charon		07[IKE] <con1|734><my ip="">is initiating an IKE_SA
Sep 24 15:30:35	charon		07[MGR] <con1|734>created IKE_SA (unnamed)[735]
Sep 24 15:30:35	charon		07[ENC] <con1|734>parsed CREATE_CHILD_SA request 6 [ SA No KE ]
Sep 24 15:30:35	charon		07[NET] <con1|734>received packet: from <my ip="">[32792] to <pfsense ip="">[4500] (396 bytes)
Sep 24 15:30:35	charon		07[MGR] IKE_SA con1[734] successfully checked out
Sep 24 15:30:35	charon		07[MGR] checkout IKEv2 SA by message with SPIs 1cceb16bafdcce98_i 1b7908c27d0f2c56_r</pfsense></my></con1|734></con1|734></con1|734></my></con1|734></con1|734></con1|734></con1|734></con1|734></con1|734></con1|734></con1|734></con1|734></con1|734></con1|735></con1|734></my></pfsense></con1|734></con1|734></con1|734></pfsense></my></con1|734></con1|734></con1|734></my></pfsense></con1|734></con1|734></con1|734></con1|734></my></pfsense></con1|734></con1|734></con1|734></con1|734>

macOS


2016-09-24 15:22:35.824533-0700 0x55a872   Default     0x0                  2296   nesessionmanager: (NetworkExtension) [com.apple.networkextension.] NESMIKEv2VPNSession[Omega:5C0F3984-1C49-48E4-9331-4E7676F5FD90]: status changed to connected
2016-09-24 15:30:35.875694-0700 0x5620f8   Error       0x0                  5784   neagent: (NetworkExtension) [com.apple.networkextension.] Received error: Error (No Proposal Chosen)
2016-09-24 15:30:35.875729-0700 0x5620f8   Error       0x0                  5784   neagent: (NetworkExtension) [com.apple.networkextension.] Failed to receive Create Child SA packet
2016-09-24 15:30:35.875745-0700 0x5620f8   Error       0x0                  5784   neagent: (NetworkExtension) [com.apple.networkextension.] Failed to process Create Child SA packet
2016-09-24 15:30:35.875944-0700 0x562108   Default     0x0                  2296   nesessionmanager: (NetworkExtension) [com.apple.networkextension.] NESMIKEv2VPNSession[Omega:5C0F3984-1C49-48E4-9331-4E7676F5FD90]: status changed to disconnecting

Any ideas would be greatly appreciated.

Derelict · Sep 24, 2016, 11:00 PM

Yup. Looks like a bug in Apple's implementation. Interestingly, it does not occur if you use a profile to configure the IPsec connection. The factory versions of pfSense have a profile exporter package or you can use the Profile Manager in OS X Server (macOS Server).

There is a bug open with Apple. No feedback on it in a few weeks.

This also occurred 10.11.X. Sorry to hear it is still present in 10.12.X. I haven't had time to test it yet.

gpit2286 · Sep 25, 2016, 12:52 AM

Bizarre -

I saw this bug on 10.11 but couldn't figure out if it was related.

If anyone else is looking for more information, a discussion about it can be found here: https://discussions.apple.com/thread/7453073?start=15&tstart=0

And I can verify that if the VPN was created through a profile, it works fine.

Thank you!!

seanmcb · Feb 9, 2017, 8:48 PM

I've just setup my VPN and "discovered" this issue. I reproduce on several machines with the newest patched versions of both 10.11 and 10.12. :(

Derelict, you mentioned a bug being opened with Apple… could you share the radar number please?

Derelict · Feb 9, 2017, 10:01 PM

I think you mean this: 27541228

Apple responded to my initial report with this:

We have determined that this is an issue for you to resolve.

The device in manual configuration is doing Perfect forward secrecy but the StrongSwan server is not. So, you will either need to disable PFS from the configuration on the device or enable PFS on the StrongSwan server.

StrongSwan Log:
Aug 6 02:32:14 fw-223 charon: 11[ENC] <con1|6>invalid DH public value size (256 bytes) for MODP_1024
Aug 6 02:32:14 fw-223 charon: 11[IKE] <con1|6>applying DH public value failed

To disable PFS on the device, you need to remove the DH group from the Child SA parameters.

We are closing this bug report.

If you have questions about the resolution, or if this is still a critical issue for you, then please update your bug report with that information.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.</con1|6></con1|6>

I responded:

With all due respect, I do not believe that is what these logs are saying at all:

iOS 9.3.4 device initiates a CREATE_CHILD_SA exactly 8 minutes after connection is established:
Aug 17 06:54:00 pfSense charon: 12[NET] <con1|23>received packet: from 192.0.2.100[14489] to 198.51.100.200[4500] (412 bytes)
Aug 17 06:54:00 pfSense charon: 12[ENC] <con1|23>parsed CREATE_CHILD_SA request 6 [ SA No KE ]
Aug 17 06:54:00 pfSense charon: 12[IKE] <con1|23>192.0.2.100 is initiating an IKE_SA
Aug 17 06:54:00 pfSense charon: 12[IKE] <con1|23>IKE_SA con1[24] state change: CREATED => CONNECTING

iOS device proposal includes PFS Group 2 (MODP_1024)
Aug 17 06:54:00 pfSense charon: 12[CFG] <con1|23>selecting proposal:
Aug 17 06:54:00 pfSense charon: 12[CFG] <con1|23>proposal matches
Aug 17 06:54:00 pfSense charon: 12[CFG] <con1|23>received proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

StrongSwan server has same proposal and agrees:
Aug 17 06:54:00 pfSense charon: 12[CFG] <con1|23>configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Aug 17 06:54:00 pfSense charon: 12[CFG] <con1|23>selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

iOS device sends 256-byte public value, which is appropriate for PFS Group 14 (MODP_2048) not the agreed-upon MODP_1024:
Aug 17 06:54:00 pfSense charon: 12[ENC] <con1|23>invalid DH public value size (256 bytes) for MODP_1024

StrongSwan server properly rejects SA and destroys connection:
Aug 17 06:54:00 pfSense charon: 12[IKE] <con1|23>applying DH public value failed
Aug 17 06:54:00 pfSense charon: 12[IKE] <con1|24>IKE_SA con1[24] state change: CONNECTING => DESTROYING

According to RFC 7296, section 3.4: The length of the Diffie-Hellman public value for MODP groups MUST be equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary.</con1|24></con1|23></con1|23></con1|23></con1|23></con1|23></con1|23></con1|23></con1|23></con1|23></con1|23></con1|23>

Then they reopened the case. That was the last thing I heard. That was in August 2016.

seanmcb · Feb 9, 2017, 10:39 PM

Thanks Derelict! I've only just got my VPN working, but have so far only tried with macOS and iOS clients. I'll soon test with Windows and linux clients and see if the 8 minute problem happens there too. If not, I'll also open a bug with Apple and reference your bug number. Hopefully another report will increase it's priority. Cheers.

seanmcb · Feb 10, 2017, 10:20 PM

I also found this thread on the same topic:

https://forum.pfsense.org/index.php?topic=110790.0

and therein was the solution! The docs here:

https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2

say to configure Phase 1 with:

Set Encryption algorithm to 3DES or, if there are no iOS/OS X devices, AES 256
Set Hash algorithm to SHA1, or, if there are no iOS/OS X devices, SHA256
Set DH key group to 2 (1024 bit)

So that's what I did, and though it works, there is that 8 minute disconnection issue. So I just changed the config to:

AES256 + SHA256 + DH group 14 (2048 bit)

and I can still connect with a macOS 10.12.3 client and stayed connected for 10 minutes. The following also worked:

AES256 + SHA256 + DH group 5 (1536 bit)
AES256 + SHA256 + DH group 19 (NIST ECP 256)

From the pfsense IPSec logs, I believe these are the combos that macOS 10.12.3 works with:

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

According to this:
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

those last two are not really secure, leaving 3 choices really. I'm not sure if the first or second is the best choice. Hopefully one them also works with all other major OSes/clients.

Derelict · Feb 11, 2017, 12:34 AM

Which is great if you don't need interoperability with clients that won't do group 14.

Bug still stands that Apple are sending the wrong size public values despite negotiating a different group when manually configured.

CloudJourneyman · Feb 13, 2017, 11:22 PM

@Derelict:

Yup. Looks like a bug in Apple's implementation. Interestingly, it does not occur if you use a profile to configure the IPsec connection. The factory versions of pfSense have a profile exporter package or you can use the Profile Manager in OS X Server (macOS Server).

Hey Derelict,

Do you have any information on this profile exporter package? What are 'factory versions' of pfSense? I tried searching and all I could find was an OpenVPN Profile Exporter package and this bug report which also mentions the 'ipsec-profile-exporter':

https://redmine.pfsense.org/issues/6684#note-1

It sounds like there isn't really any work-around at this stage other than creating the VPN connection from a profile. I have tried to take a look at the Apple profile tools but it looked like a bit of a learning curve to work out how to create and deploy them. I was scared that I might be breaking other stuff by deploying a profile when I have no idea what I'm doing. If I can find and use this profile export tool in pfSense that would be great.

Derelict · Feb 14, 2017, 1:02 AM

It is an included feature/package on the factory version of pfSense installed on pfSense hardware at store.pfsense.org.

Derelict · May 7, 2017, 4:55 AM

Can anyone else confirm that this looks to be fixed in iOS 10.3.1?

It is still reauth/rekey every 8 minutes for reasons known only to Apple (My side is 86400/28800) but it succeeds.

NogBadTheBad · May 7, 2017, 10:40 AM

@Derelict:

Yup. Looks like a bug in Apple's implementation. Interestingly, it does not occur if you use a profile to configure the IPsec connection. The factory versions of pfSense have a profile exporter package or you can use the Profile Manager in OS X Server (macOS Server).

There is a bug open with Apple. No feedback on it in a few weeks.

This also occurred 10.11.X. Sorry to hear it is still present in 10.12.X. I haven't had time to test it yet.

I tried the ipsec-profile-wizard and it didn't like the import I'm getting "The 'VPN Service' payload could not be installed. The VPN service could not be created."

If I install my certs by hand and setup the vpn connection IKEv2 works fine, no disconnects on my iPhone or iPad away from home.

My IPsec config :-

<ipsec><client><enable></enable>
<user_source>Local Database</user_source>
<group_source>none</group_source>
<pool_address>172.16.9.0</pool_address>
<pool_netbits>24</pool_netbits>
<dns_domain>XXXX XXXX.net</dns_domain>
<dns_server1>172.16.1.1</dns_server1></client>
<logging><dmn>1</dmn>
<mgr>1</mgr>
<ike>1</ike>
<chd>1</chd>
<job>1</job>
<cfg>1</cfg>
<knl>1</knl>
<net>1</net>
<asn>1</asn>
<enc>1</enc>
<imc>1</imc>
<imv>1</imv>
<pts>1</pts>
<tls>1</tls>
<esp>1</esp>
<lib>1</lib></logging>
<uniqueids>never</uniqueids>
<phase1><ikeid>1</ikeid>
<iketype>ikev2</iketype>
<interface>wan</interface>

<protocol>inet</protocol>
<myid_type>fqdn</myid_type>
<myid_data>vpn.xxxxxxxxxx.net</myid_data>
<peerid_type>any</peerid_type>
<peerid_data></peerid_data>
<encryption-algorithm><name>aes</name>
<keylen>256</keylen></encryption-algorithm>
<hash-algorithm>sha256</hash-algorithm>
<dhgroup>14</dhgroup>
<lifetime>28800</lifetime>
<pre-shared-key></pre-shared-key>
<private-key></private-key>
<certref>590e07927b298</certref>
<caref></caref>
<authentication_method>eap-mschapv2</authentication_method>

<nat_traversal>on</nat_traversal>
<mobike>on</mobike>
<dpd_delay>10</dpd_delay>
<dpd_maxfail>5</dpd_maxfail></phase1>
<phase2><ikeid>1</ikeid>
<uniqid>58ecc9de19c3f</uniqid>
<mode>tunnel</mode>
<reqid>1</reqid>
<localid><type>network</type>

<protocol>esp</protocol>
<encryption-algorithm-option><name>aes</name>
<keylen>auto</keylen></encryption-algorithm-option>
<hash-algorithm-option>hmac_sha256</hash-algorithm-option>
<hash-algorithm-option>hmac_sha384</hash-algorithm-option>
<hash-algorithm-option>hmac_sha512</hash-algorithm-option>
<pfsgroup>0</pfsgroup>
<lifetime>3600</lifetime></phase2>
<mobilekey><ident>xxxxxx</ident>
<type>EAP</type>
<pre-shared-key>xxxxxx</pre-shared-key></mobilekey></ipsec>