Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    MacOs 10.12, Ikev2 - Disconnects after 8 minutes

    Scheduled Pinned Locked Moved IPsec
    12 Posts 5 Posters 11.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      gpit2286
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        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.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • G
          gpit2286
          last edited by

          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!!

          1 Reply Last reply Reply Quote 0
          • S
            seanmcb
            last edited by

            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?

            1 Reply Last reply Reply Quote 0
            • DerelictD
              Derelict LAYER 8 Netgate
              last edited by

              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.

              Chattanooga, Tennessee, USA
              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
              Do Not Chat For Help! NO_WAN_EGRESS(TM)

              1 Reply Last reply Reply Quote 0
              • S
                seanmcb
                last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • S
                  seanmcb
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • DerelictD
                    Derelict LAYER 8 Netgate
                    last edited by

                    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.

                    Chattanooga, Tennessee, USA
                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

                    1 Reply Last reply Reply Quote 0
                    • C
                      CloudJourneyman
                      last edited by

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

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by

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

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

                        1 Reply Last reply Reply Quote 0
                        • DerelictD
                          Derelict LAYER 8 Netgate
                          last edited by

                          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.

                          Chattanooga, Tennessee, USA
                          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                          Do Not Chat For Help! NO_WAN_EGRESS(TM)

                          1 Reply Last reply Reply Quote 0
                          • NogBadTheBadN
                            NogBadTheBad
                            last edited by

                            @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>

                            <address>0.0.0.0</address>

                            <netbits>0</netbits></localid>

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

                            Andy

                            1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.