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

    PfSense 2.3.2 fails with macOS 10.11.6 native Cisco-style VPN client (IKE v1)

    Scheduled Pinned Locked Moved IPsec
    31 Posts 6 Posters 8.8k 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.
    • S
      sirozha Banned
      last edited by

      @jimp:

      I'm still not convinced that "Apple changed their client, now it doesn't work" translates to it being a problem on pfSense.

      It may be technically possible to work around their faults, but that does not mean the fault is not on the client side. Raise a case with Apple and tell them to fix their client.

      Wow! The client works with any other vendor, including Cisco and a multitude of other routers and firewalls. You seriously think if I raise a ticket with Apple for their client not working with pfSense, the ticket is going to go anywhere? We are talking about two vendors that had an incompatibility issue. One vendor is a corporation with the highest EVER market capitalization and profits that ANY corporation has ever had, and the other is a small open-source project. And again, the client made by this giant corporation works pretty much with EVERY other vendor's IPSec headend except for the firewall made by a small open-source project.

      Can I pay someone at pfSense to fix this issue because obviously there's a blame game going on here instead of looking into the issue.

      This kind of attitude makes me think twice before considering pfSense as a viable firewall.

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        Just because it works with other vendors does not mean it still isn't a client bug. You changed nothing on pfSense but the client changed, and then it broke, so it won't hurt to ask them to look into what they broke. If they ignore your bug report, it would make me think twice about working with Apple since they broke the client and wouldn't fix it.

        Or just move on to IKEv2 like the rest of the world has (or is going to).

        We don't do paid development, but if you want to put up a bounty and see if someone can come up with a PR, go ahead. If the IPsec GUI allowed selection of multiple options like the P2 does, it would allow you to accommodate this broken client, but that's a lot more work than it would appear to be at a glance. It's something we intend to do, but we haven't allocated resources toward it yet since it has not been a pressing issue.

        Apple has broken other aspects of their clients along the way as well, one example is rekeying IKEv2 when not using the profile configuration utility. We only recent convinced them that their client was, in fact, broken and sending out-of-spec data when rekeying. Use the VPN profile config and it works fine, use defaults and it breaks. The client is sending bad data, nothing we can control in that case either. They need to be doing a better job, and if nobody tells them they aren't, they'll keep half-assing their clients.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • S
          sirozha Banned
          last edited by

          @jimp:

          Just because it works with other vendors does not mean it still isn't a client bug. You changed nothing on pfSense but the client changed, and then it broke, so it won't hurt to ask them to look into what they broke. If they ignore your bug report, it would make me think twice about working with Apple since they broke the client and wouldn't fix it.

          Or just move on to IKEv2 like the rest of the world has (or is going to).

          We don't do paid development, but if you want to put up a bounty and see if someone can come up with a PR, go ahead. If the IPsec GUI allowed selection of multiple options like the P2 does, it would allow you to accommodate this broken client, but that's a lot more work than it would appear to be at a glance. It's something we intend to do, but we haven't allocated resources toward it yet since it has not been a pressing issue.

          Apple has broken other aspects of their clients along the way as well, one example is rekeying IKEv2 when not using the profile configuration utility. We only recent convinced them that their client was, in fact, broken and sending out-of-spec data when rekeying. Use the VPN profile config and it works fine, use defaults and it breaks. The client is sending bad data, nothing we can control in that case either. They need to be doing a better job, and if nobody tells them they aren't, they'll keep half-assing their clients.

          All of this makes sense except the same macOS built-in Cisco VPN client works fine with other vendors' headends. I'm not going to comment on the IKE v2 issue you mentioned as I have no experience with that aspect.

          I know that Apple occasionally introduces bugs in their software upgrades, but this particular issue appears to be a bug on the pfSense end - just logically arriving at this conclusion based on the fact that other vendors have no problem with this new macOS Cisco VPN client behavior without having to fix anything on their end.

          And if you think you should ignore Apple products - for whatever reason - it's your decision. It's obviously a bad business decision for pfSense, but perhaps pfSense is not a business per se but a hobby.

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

            I just built this…again...loosely following this: https://doc.pfsense.org/index.php/IPsec_Road_Warrior/Mobile_Client_How-To

            Worked fine.

            I have been unable to duplicate the behavior you describe.

            Aug 31 00:25:52 pfSense charon: 11[CFG] rereading secrets
            Aug 31 00:25:52 pfSense charon: 11[CFG] loading secrets from '/var/etc/ipsec/ipsec.secrets'
            Aug 31 00:25:52 pfSense charon: 11[CFG]  loaded IKE secret for 203.0.113.17 vpnusers@example.com
            Aug 31 00:25:52 pfSense charon: 11[CFG]  loaded IKE secret for %any
            Aug 31 00:25:52 pfSense charon: 11[CFG]  loaded EAP secret for testuser
            Aug 31 00:25:52 pfSense charon: 11[CFG] rereading ca certificates from '/usr/local/etc/ipsec.d/cacerts'
            Aug 31 00:25:52 pfSense charon: 11[CFG] rereading aa certificates from '/usr/local/etc/ipsec.d/aacerts'
            Aug 31 00:25:52 pfSense charon: 11[CFG] rereading ocsp signer certificates from '/usr/local/etc/ipsec.d/ocspcerts'
            Aug 31 00:25:52 pfSense charon: 11[CFG] rereading attribute certificates from '/usr/local/etc/ipsec.d/acerts'
            Aug 31 00:25:52 pfSense charon: 11[CFG] rereading crls from '/usr/local/etc/ipsec.d/crls'
            Aug 31 00:25:52 pfSense charon: 07[CFG] received stroke: unroute 'bypasslan'
            Aug 31 00:25:52 pfSense charon: 07[CFG] proposing traffic selectors for us:
            Aug 31 00:25:52 pfSense charon: 07[CFG]  192.168.1.0/24|/0
            Aug 31 00:25:52 pfSense charon: 07[CFG] proposing traffic selectors for other:
            Aug 31 00:25:52 pfSense charon: 07[CFG]  192.168.1.0/24|/0
            Aug 31 00:25:52 pfSense ipsec_starter[25095]: shunt policy 'bypasslan' uninstalled
            Aug 31 00:25:52 pfSense ipsec_starter[25095]:
            Aug 31 00:25:52 pfSense charon: 11[CFG] received stroke: delete connection 'bypasslan'
            Aug 31 00:25:52 pfSense charon: 11[CFG] deleted connection 'bypasslan'
            Aug 31 00:25:52 pfSense charon: 08[CFG] received stroke: delete connection 'con1'
            Aug 31 00:25:52 pfSense charon: 08[CFG] deleted connection 'con1'
            Aug 31 00:25:52 pfSense charon: 07[CFG] received stroke: add connection 'bypasslan'
            Aug 31 00:25:52 pfSense charon: 07[CFG] conn bypasslan
            Aug 31 00:25:52 pfSense charon: 07[CFG]  left=%any
            Aug 31 00:25:52 pfSense charon: 07[CFG]  leftsubnet=192.168.1.0/24
            Aug 31 00:25:52 pfSense charon: 07[CFG]  right=%any
            Aug 31 00:25:52 pfSense charon: 07[CFG]  rightsubnet=192.168.1.0/24
            Aug 31 00:25:52 pfSense charon: 07[CFG]  ike=aes128-sha256-modp3072
            Aug 31 00:25:52 pfSense charon: 07[CFG]  esp=aes128-sha256
            Aug 31 00:25:52 pfSense charon: 07[CFG]  dpddelay=30
            Aug 31 00:25:52 pfSense charon: 07[CFG]  dpdtimeout=150
            Aug 31 00:25:52 pfSense charon: 07[CFG]  mediation=no
            Aug 31 00:25:52 pfSense charon: 07[CFG] added configuration 'bypasslan'
            Aug 31 00:25:52 pfSense charon: 08[CFG] received stroke: route 'bypasslan'
            Aug 31 00:25:52 pfSense charon: 08[CFG] proposing traffic selectors for us:
            Aug 31 00:25:52 pfSense charon: 08[CFG]  192.168.1.0/24|/0
            Aug 31 00:25:52 pfSense charon: 08[CFG] proposing traffic selectors for other:
            Aug 31 00:25:52 pfSense charon: 08[CFG]  192.168.1.0/24|/0
            Aug 31 00:25:52 pfSense ipsec_starter[25095]: 'bypasslan' shunt PASS policy installed
            Aug 31 00:25:52 pfSense ipsec_starter[25095]:
            Aug 31 00:25:52 pfSense charon: 07[CFG] received stroke: add connection 'con1'
            Aug 31 00:25:52 pfSense charon: 07[CFG] conn con1
            Aug 31 00:25:52 pfSense charon: 07[CFG]  left=203.0.113.17
            Aug 31 00:25:52 pfSense charon: 07[CFG]  leftsubnet=0.0.0.0/0
            Aug 31 00:25:52 pfSense charon: 07[CFG]  leftauth=psk
            Aug 31 00:25:52 pfSense charon: 07[CFG]  leftid=203.0.113.17
            Aug 31 00:25:52 pfSense charon: 07[CFG]  right=%any
            Aug 31 00:25:52 pfSense charon: 07[CFG]  rightsourceip=172.25.240.0/24
            Aug 31 00:25:52 pfSense charon: 07[CFG]  rightauth=psk
            Aug 31 00:25:52 pfSense charon: 07[CFG]  rightauth2=xauth-generic
            Aug 31 00:25:52 pfSense charon: 07[CFG]  ike=aes128-sha1-modp1024!
            Aug 31 00:25:52 pfSense charon: 07[CFG]  esp=aes256-sha1,aes256-sha256,aes192-sha1,aes192-sha256,aes128-sha1,aes128-sha256,3des-sha1,3des-sha256!
            Aug 31 00:25:52 pfSense charon: 07[CFG]  dpddelay=10
            Aug 31 00:25:52 pfSense charon: 07[CFG]  dpdtimeout=60
            Aug 31 00:25:52 pfSense charon: 07[CFG]  dpdaction=1
            Aug 31 00:25:52 pfSense charon: 07[CFG]  mediation=no
            Aug 31 00:25:52 pfSense charon: 07[CFG]  keyexchange=ikev1
            Aug 31 00:25:52 pfSense charon: 07[CFG] reusing virtual IP address pool 172.25.240.0/24
            Aug 31 00:25:52 pfSense charon: 07[CFG] added configuration 'con1'
            Aug 31 00:26:52 pfSense charon: 07[NET] <11> received packet: from 203.0.113.16[500] to 203.0.113.17[500] (776 bytes)
            Aug 31 00:26:52 pfSense charon: 07[ENC] <11> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V V V V V V V ]
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11> looking for an ike config for 203.0.113.17…203.0.113.16
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  candidate: %any…%any, prio 24
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  candidate: 203.0.113.17…%any, prio 1052
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11> found matching ike config: 203.0.113.17…%any with prio 1052
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received FRAGMENTATION vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received NAT-T (RFC 3947) vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-08 vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-07 vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-06 vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-05 vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-04 vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received XAuth vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received Cisco Unity vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received DPD vendor ID
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> 203.0.113.16 is initiating a Aggressive Mode IKE_SA
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> IKE_SA (unnamed)[11] state change: CREATED => CONNECTING
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11> selecting proposal:
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  no acceptable ENCRYPTION_ALGORITHM found
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11> selecting proposal:
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  no acceptable ENCRYPTION_ALGORITHM found
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11> selecting proposal:
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  no acceptable ENCRYPTION_ALGORITHM found
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11> selecting proposal:
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  no acceptable ENCRYPTION_ALGORITHM found
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
            Aug 31 00:26:52 pfSense charon: 07[CFG] <11> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> no proposal found
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> queueing INFORMATIONAL task
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> activating new tasks
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11>  activating INFORMATIONAL task
            Aug 31 00:26:52 pfSense charon: 07[ENC] <11> generating INFORMATIONAL_V1 request 2759542525 [ N(NO_PROP) ]
            Aug 31 00:26:52 pfSense charon: 07[NET] <11> sending packet: from 203.0.113.17[500] to 203.0.113.16[500] (56 bytes)
            Aug 31 00:26:52 pfSense charon: 07[IKE] <11> IKE_SA (unnamed)[11] state change: CONNECTING => DESTROYING
            Aug 31 00:26:52 pfSense charon: 08[NET] <12> received packet: from 203.0.113.16[500] to 203.0.113.17[500] (776 bytes)
            Aug 31 00:26:52 pfSense charon: 08[ENC] <12> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V V V V V V V ]
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12> looking for an ike config for 203.0.113.17…203.0.113.16
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  candidate: %any…%any, prio 24
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  candidate: 203.0.113.17…%any, prio 1052
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12> found matching ike config: 203.0.113.17…%any with prio 1052
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received FRAGMENTATION vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received NAT-T (RFC 3947) vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-08 vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-07 vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-06 vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-05 vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-04 vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received XAuth vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received Cisco Unity vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received DPD vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> 203.0.113.16 is initiating a Aggressive Mode IKE_SA
            Aug 31 00:26:52 pfSense charon: 08[IKE] <12> IKE_SA (unnamed)[12] state change: CREATED => CONNECTING
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12> selecting proposal:
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  no acceptable ENCRYPTION_ALGORITHM found
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12> selecting proposal:
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  no acceptable ENCRYPTION_ALGORITHM found
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12> selecting proposal:
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  proposal matches
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12> selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12> looking for XAuthInitPSK peer configs matching 203.0.113.17…203.0.113.16[76:70:6e:75:73:65:72:73:40:65:78:61:6d:70:6c:65:2e:63:6f:6d]
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  candidate "bypasslan", match: 1/1/24 (me/other/ike)
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  candidate "con1", match: 1/1/1052 (me/other/ike)
            Aug 31 00:26:52 pfSense charon: 08[CFG] <12> selected peer config "con1"
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>sending XAuth vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>sending DPD vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>sending FRAGMENTATION vendor ID
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>sending NAT-T (RFC 3947) vendor ID
            Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>generating AGGRESSIVE response 0 [ SA KE No ID V V V V NAT-D NAT-D HASH ]
            Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>sending packet: from 203.0.113.17[500] to 203.0.113.16[500] (412 bytes)
            Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (100 bytes)
            Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>parsed AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>queueing XAUTH task
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>remote host is behind NAT
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>activating new tasks
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>activating XAUTH task
            Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>generating TRANSACTION request 1000815079 [ HASH CPRQ(X_USER X_PWD) ]
            Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>sending packet: from 203.0.113.17[4500] to 203.0.113.16[32384] (76 bytes)
            Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (92 bytes)
            Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>parsed INFORMATIONAL_V1 request 3652027594 [ HASH N(INITIAL_CONTACT) ]
            Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (92 bytes)
            Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>parsed TRANSACTION response 1000815079 [ HASH CPRP(X_USER X_PWD) ]
            Aug 31 00:26:52 pfSense charon: user 'testuser' authenticated
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>XAuth-SCRIPT succeeded for user 'testuser'.
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>XAuth authentication of 'testuser' successful
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>reinitiating already active tasks
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>XAUTH task
            Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>generating TRANSACTION request 1423147739 [ HASH CPS(X_STATUS) ]
            Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>sending packet: from 203.0.113.17[4500] to 203.0.113.16[32384] (76 bytes)
            Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (76 bytes)
            Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>parsed TRANSACTION response 1423147739 [ HASH CPA(X_STATUS) ]
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>IKE_SA con1[12] established between 203.0.113.17[203.0.113.17]…203.0.113.16[76:70:6e:75:73:65:72:73:40:65:78:61:6d:70:6c:65:2e:63:6f:6d]
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>IKE_SA con1[12] state change: CONNECTING => ESTABLISHED
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>scheduling reauthentication in 85592s
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>maximum IKE_SA lifetime 86132s
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>activating new tasks
            Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>nothing to initiate
            Aug 31 00:26:52 pfSense charon: 12[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (172 bytes)
            Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>unknown attribute type (28683)
            Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>parsed TRANSACTION request 3279620505 [ HASH CPRQ(ADDR MASK DNS NBNS EXP VER U_BANNER U_DEFDOM U_SPLITDNS U_SPLITINC U_LOCALLAN U_PFS U_SAVEPWD U_FWTYPE U_BKPSRV (28683)) ]
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing INTERNAL_IP4_ADDRESS attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing INTERNAL_IP4_NETMASK attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing INTERNAL_IP4_DNS attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing INTERNAL_IP4_NBNS attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing INTERNAL_ADDRESS_EXPIRY attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing APPLICATION_VERSION attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_BANNER attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_DEF_DOMAIN attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_SPLITDNS_NAME attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_SPLIT_INCLUDE attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_LOCAL_LAN attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_PFS attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_SAVE_PASSWD attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_FW_TYPE attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_BACKUP_SERVERS attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing (28683) attribute
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>peer requested virtual IP %any
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>reassigning offline lease to 'testuser'
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>assigning virtual IP 172.25.240.1 to peer 'testuser'
            Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>generating TRANSACTION response 3279620505 [ HASH CPRP(ADDR DNS) ]
            Aug 31 00:26:52 pfSense charon: 12[NET] <con1|12>sending packet: from 203.0.113.17[4500] to 203.0.113.16[32384] (92 bytes)
            Aug 31 00:26:52 pfSense charon: 12[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (300 bytes)
            Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>parsed QUICK_MODE request 3949526512 [ HASH SA No ID ID ]
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>looking for a child config for 0.0.0.0/0|/0 === 172.25.240.1/32|/0
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>proposing traffic selectors for us:
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>0.0.0.0/0|/0
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>proposing traffic selectors for other:
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>172.25.240.1/32|/0
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>candidate "con1" with prio 5+5
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>found matching child config "con1" with prio 10
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>selecting traffic selectors for other:
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>config: 172.25.240.1/32|/0, received: 172.25.240.1/32|/0 => match: 172.25.240.1/32|/0
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>selecting traffic selectors for us:
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>config: 0.0.0.0/0|/0, received: 0.0.0.0/0|/0 => match: 0.0.0.0/0|/0
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>selecting proposal:
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>proposal matches
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_MD5_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_MD5_96/NO_EXT_SEQ
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ
            Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>received 3600s lifetime, configured 28800s
            Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>generating QUICK_MODE response 3949526512 [ HASH SA No ID ID ]
            Aug 31 00:26:52 pfSense charon: 12[NET] <con1|12>sending packet: from 203.0.113.17[4500] to 203.0.113.16[32384] (172 bytes)
            Aug 31 00:26:52 pfSense charon: 12[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (60 bytes)
            Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>parsed QUICK_MODE request 3949526512 [ HASH ]
            Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>using AES_CBC for encryption
            Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>using HMAC_SHA1_96 for integrity
            Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>adding inbound ESP SA
            Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>SPI 0xc19b6efc, src 203.0.113.16 dst 203.0.113.17
            Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>adding outbound ESP SA
            Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>SPI 0x0e287f59, src 203.0.113.17 dst 203.0.113.16
            Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>CHILD_SA con1{8} established with SPIs c19b6efc_i 0e287f59_o and TS 0.0.0.0/0|/0 === 172.25.240.1/32|/0

            Works with Group 14 in the Phase 1, too:

            Aug 31 00:39:35 pfSense charon: 08[IKE] <15> IKE_SA (unnamed)[15] state change: CREATED => CONNECTING
            Aug 31 00:39:35 pfSense charon: 08[CFG] <15> selecting proposal:
            Aug 31 00:39:35 pfSense charon: 08[CFG] <15>  proposal matches
            Aug 31 00:39:35 pfSense charon: 08[CFG] <15> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
            Aug 31 00:39:35 pfSense charon: 08[CFG] <15> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
            Aug 31 00:39:35 pfSense charon: 08[CFG] <15> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048</con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12>

            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
            • dennypageD
              dennypage
              last edited by

              A little searching reveals that that there are a number of problems with the Mac IPSEC client, and is not just an issue with pfSense:

              https://www.google.com/search?q=site%3Adiscussions.apple.com+10.11+broke+ipsec

              This thread in particular might be of interest to you:

              https://discussions.apple.com/thread/7502488

              I don't believe that it would be appropriate for pfSense (or strongSwan) to attempt an implementation to work around this.

              If you are interested in moving forward, I would recommend using IKEv2.

              1 Reply Last reply Reply Quote 0
              • S
                sirozha Banned
                last edited by

                @Derelict:

                I just built this…again...loosely following this: https://doc.pfsense.org/index.php/IPsec_Road_Warrior/Mobile_Client_How-To

                Worked fine.

                I have been unable to duplicate the behavior you describe.

                .....

                Works with Group 14 in the Phase 1, too:

                Aug 31 00:39:35 pfSense charon: 08[IKE] <15> IKE_SA (unnamed)[15] state change: CREATED => CONNECTING
                Aug 31 00:39:35 pfSense charon: 08[CFG] <15> selecting proposal:
                Aug 31 00:39:35 pfSense charon: 08[CFG] <15>  proposal matches
                Aug 31 00:39:35 pfSense charon: 08[CFG] <15> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
                Aug 31 00:39:35 pfSense charon: 08[CFG] <15> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
                Aug 31 00:39:35 pfSense charon: 08[CFG] <15> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048

                Derelict,

                Thanks for trying to connect via IPSec from macOS. Could you please verify the version of pfSense you are running and the version of macOS from which you were able to connect via the built-in Cisco IPSec Client?

                Perhaps we are about to narrow down which product and which version is causing the issue.

                Thank you!

                1 Reply Last reply Reply Quote 0
                • S
                  sirozha Banned
                  last edited by

                  @dennypage:

                  A little searching reveals that that there are a number of problems with the Mac IPSEC client, and is not just an issue with pfSense:

                  https://www.google.com/search?q=site%3Adiscussions.apple.com+10.11+broke+ipsec

                  This thread in particular might be of interest to you:

                  https://discussions.apple.com/thread/7502488

                  I don't believe that it would be appropriate for pfSense (or strongSwan) to attempt an implementation to work around this.

                  If you are interested in moving forward, I would recommend using IKEv2.

                  I had read this thread which you posted a link to (which is according to you "may be of particular interest" to me), and that is exactly the thread I had referred to when I had said that other vendors' IPSec headends were able to handle the new behavior of the native macOS Cisco IP VPN client starting with macOS 10.11.4.

                  If you read that thread more attentively, you will see that all that the folks had to do was to enable DH Group 14 on a variety of IPSec VPN headends by various vendors. Once DH Group 14 was enabled on the headends, the issue that the folks experienced with IPSec VPN connectivity in macOS 10.11.4 was resolved.

                  In the case of my extensive testing with pfSense, enabling DH Group 14 does not resolve this issue, as it is described at length in my posts above (probably with more verbosity than anyone would care to read). I was hoping that I was posting the detailed reports of my tests for the pfSense developers to try and replicate my issue; hence the amount of detail in may posts.

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

                    The logs I posted above say it works just fine. There is something peculiar about your environment it looks like.

                    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

                      Derelict,

                      Thanks for trying to connect via IPSec from macOS. Could you please verify the version of pfSense you are running and the version of macOS from which you were able to connect via the built-in Cisco IPSec Client?

                      Perhaps we are about to narrow down which product and which version is causing the issue.

                      Thank you!

                      10.11.6

                      2.3.2 CE amd64

                      Just the standard Cisco IPsec in the System Preferences.

                      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
                      • dennypageD
                        dennypage
                        last edited by

                        There are many threads regarding defects introduced by the Mac specific version of Raccoon. Very similar if not the same as your issue. "Used to work fine, broke when I updated MacOS…" Sometimes you can make config changes on the server end to work around the defect, and sometimes you can't. In this case, it seems that you can't. Asking pfSense or strongSwan to implement further work-arounds for those defects isn't going to be productive, they are going to tell you to raise the issue with Apple. If there was no other way to get IPSEC connectivity to the platform it might be a different answer, but that's not the case here.

                        Taking a step back, what is the primary goal? Is it to get a vendor to fix the IKEv1 problem? Or is it to get to a solution that works? If the goal is to get a vendor to fix the IKEv1 issue, then the focus should be with Apple because that is where the defect was introduced. But you have to accept that this will likely take months. And when all is said and done, Apple may simply choose to not fix the defect. Like most everyone else, they are focusing their efforts on IKEv2. On the other hand, if the primary goal is to get something that works, then IKEv2 accomplishes that easily enough.

                        1 Reply Last reply Reply Quote 0
                        • S
                          sirozha Banned
                          last edited by

                          Thank you. This is definitely a setback in my troubleshooting because I am running exactly the same versions of Mac OS and pfSense. What is CE by the way?

                          However, this is not unique to my environment because another user was able to replicate the same exact issue and behavior in the logs, which he reported in this thread.

                          Another variable I can think of is that I installed MacOS 10.11.6 anew instead of upgrading to it from a previous version. I got a new Mac, and I made a fresh install of 10.11.6 before restoring the files, applications, and settings from a Time Machine backup.

                          Is your macOS 10.11.6 an upgrade from
                          A previous version or a fresh install?

                          –----
                          At this point, there are two theories here:
                          1. MacOS IPSec VPN client is broken - raise a bug with Apple.
                          2. MacOS IPSec VPN client is just fine - something is different in my (and the other user having this problem) environment.

                          Thank you!

                          1 Reply Last reply Reply Quote 0
                          • S
                            sirozha Banned
                            last edited by

                            @dennypage:

                            There are many threads regarding defects introduced by the Mac specific version of Raccoon. Very similar if not the same as your issue. "Used to work fine, broke when I updated MacOS…" Sometimes you can make config changes on the server end to work around the defect, and sometimes you can't. In this case, it seems that you can't. Asking pfSense or strongSwan to implement further work-arounds for those defects isn't going to be productive, they are going to tell you to raise the issue with Apple. If there was no other way to get IPSEC connectivity to the platform it might be a different answer, but that's not the case here.

                            Taking a step back, what is the primary goal? Is it to get a vendor to fix the IKEv1 problem? Or is it to get to a solution that works? If the goal is to get a vendor to fix the IKEv1 issue, then the focus should be with Apple because that is where the defect was introduced. But you have to accept that this will likely take months. And when all is said and done, Apple may simply choose to not fix the defect. Like most everyone else, they are focusing their efforts on IKEv2. On the other hand, if the primary goal is to get something that works, then IKEv2 accomplishes that easily enough.

                            Does IKEv2 (as it's implemented in pfSense and in MacOS) support PSK authentication?

                            1 Reply Last reply Reply Quote 0
                            • dennypageD
                              dennypage
                              last edited by

                              @sirozha:

                              Does IKEv2 (as it's implemented in pfSense and in MacOS) support PSK authentication?

                              I can't say first hand if PSK still works in MacOS or not. I would expect so, but I moved to certificate based authentication a couple of years ago and no longer have a PSK config to test with. Of course, I would have expected what you are currently doing to work in MacOS as well… :)

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

                                I have had this Mac user profile going since 2010 or so. Just upgraded along the way. That macbook pro broke so I think this is a fresh install with a time machine restore but that was a while ago. Probably was Yosemite at the time then upgraded. Don't think about it much.

                                CE is community edition. The version you download from www.pfsense.org. As contrasted with factory edition which is tweaked for netgate/pfsense hardware. As far as IPsec/strongswan are concerned they are identical.

                                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
                                  sirozha Banned
                                  last edited by

                                  I downloaded Apple Configurator 2 and tried to configure VPN profiles there.

                                  1. IPSec (IKE v1 Cisco VPN Client). There are no settings available there for crypto parameters of IKE 1. Nonetheless, I tried to configure a profile in the Apple Configurator 2 for IKE v1, but when I installed the profile in macOS 10.11.6, I had the same issue described earlier in this thread; namely, the proposal that macOS is sending to pfSense never contains the DH Group number configured in pfSense Phase 1.

                                  2. IKE v2. IKE v2 profile in Apple Configurator 2 allows one to configure crypto parameters, which I did. Because I don't want to deal with PKI certificates - not just yet, I tried to configure an IKE v2 profile with "Shared Secret" (instead of "Certificate") for Machine Authentication. When I installed this profile in macOS 10.11.6 and tried to connect with IKE v2, the IPSec log in pfSense reported that the Machine Authentication (in IKE v2 Phase 1) with PSK was successful, but it was rejected by pfSense due to a "constraint" to authenticate with a public key. See the IPSec log output below:

                                  
                                  Aug 31 22:02:46	charon		13[NET] <bypasslan|14>sending packet: from 192.168.160.1[4500] to 192.168.160.100[4500] (80 bytes)
                                  Aug 31 22:02:46	charon		13[ENC] <bypasslan|14>generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
                                  Aug 31 22:02:46	charon		13[IKE] <bypasslan|14>peer supports MOBIKE
                                  Aug 31 22:02:46	charon		13[IKE] <bypasslan|14>received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
                                  Aug 31 22:02:46	charon		13[CFG] <bypasslan|14>no alternative config found
                                  Aug 31 22:02:46	charon		13[CFG] <bypasslan|14>selected peer config 'bypasslan' inacceptable: constraint checking failed
                                  Aug 31 22:02:46	charon		13[CFG] <bypasslan|14>constraint requires public key authentication, but pre-shared key was used
                                  Aug 31 22:02:46	charon		13[CFG] <con1|14>switching to peer config 'bypasslan'
                                  Aug 31 22:02:46	charon		13[CFG] <con1|14>selected peer config 'con1' inacceptable: insufficient authentication rounds
                                  Aug 31 22:02:46	charon		13[IKE] <con1|14>authentication of 'client@acme.com' with pre-shared key successful
                                  Aug 31 22:02:46	charon		13[CFG] <con1|14>selected peer config 'con1'
                                  Aug 31 22:02:46	charon		13[CFG] <14> looking for peer configs matching 192.168.160.1[192.168.160.1]...192.168.160.100[client@acme.com]
                                  Aug 31 22:02:46	charon		13[ENC] <14> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) N(MOBIKE_SUP) IDr AUTH CPRQ(ADDR DHCP DNS MASK ADDR6 DHCP6 DNS6) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
                                  Aug 31 22:02:46	charon		13[NET] <14> received packet: from 192.168.160.100[4500] to 192.168.160.1[4500] (384 bytes)
                                  Aug 31 22:02:46	charon		13[NET] <14> sending packet: from 192.168.160.1[500] to 192.168.160.100[500] (448 bytes)
                                  Aug 31 22:02:46	charon		13[ENC] <14> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(MULT_AUTH) ]
                                  Aug 31 22:02:46	charon		13[IKE] <14> 192.168.160.100 is initiating an IKE_SA
                                  Aug 31 22:02:46	charon		13[ENC] <14> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
                                  Aug 31 22:02:46	charon		13[NET] <14> received packet: from 192.168.160.100[500] to 192.168.160.1[500] (432 bytes)</con1|14></con1|14></con1|14></con1|14></bypasslan|14></bypasslan|14></bypasslan|14></bypasslan|14></bypasslan|14></bypasslan|14></bypasslan|14> 
                                  

                                  This brings me back to the question I asked two posts earlier, Does pfSense support PSK authentication in IKE v2? I guess the answer is, it does not, even though Apple supports this method of Machine Authentication in macOS 10.11.6 via a profile created in Apple Configurator 2.

                                  I realize that going with PKI certs is more secure than with PSK; however, for small environments, the headache of managing PKI may not be worth the time. Would it be possible for pfSense to consider supporting "pre-shared key" Machine Authentication method in IKE v2?

                                  1 Reply Last reply Reply Quote 0
                                  • S
                                    sirozha Banned
                                    last edited by

                                    I finally was able to transition pfSense from my lab to production, and once it was connected to the real Internet with its WAN port, I tried to connect to pfSense via the IPSec VPN (IKE v1) from an iPhone. I had no issues whatsoever connecting with an iPhone, using AES (256 bit), SHA256, and DH Group 14. So, it appears that something in my macOS installation is causing this issue rather than this being a problem with pfSense. I won't be able to tell for sure until I try another Mac and connect successfully with a Mac.

                                    If this is an issue with my macOS installation (which is weird because it's a 3-week-old fresh install), I apologize for blaming pfSense for this. It helped when another person posted here saying that with the same settings that I used, this person had no issues connected to pfSense' IPSec (IKE v1) server.

                                    Does anyone know how to default the entire network stack in OS X  so that if something is in fact wrong with it in this Mac, I could default it and clear this erroneous behavior?

                                    Thank you.

                                    I guess I can try to re-install macOS on it as well.

                                    1 Reply Last reply Reply Quote 0
                                    • M
                                      macUnix
                                      last edited by

                                      I also ran into this issue as my macOS 10.12.x machines worked fine and an older pair of machines running 10.11.6 could not connect to the VPN.

                                      I tried IKEv2, but could not get that to work so I started to fiddle with some additional settings and found that in 'IPsec->Advanced Settings' I had enabled 'IP Compression' and 'Enable Cisco Extensions' (Unity plugin). After disabling both and restarting the IPsec service in pfSense my 10.11.6 machines are able to make the IPsec connection.

                                      So maybe the cause of the mentioned Phase 1 chatter and failing exchange is in the 'Unity plugin' as it is related to Cisco extensions and the macOS Client for IPsec is specifically labeled 'Ciso IPsec'.

                                      My configuration settings :

                                      Mobile Clients
                                      Enable IPSsec Mobile Client Support
                                      IKE Extensions -> Enable
                                      Extended Authentication
                                      User Authentication -> Local Database
                                      Group Authentication -> system
                                      Client Configuration
                                      Virtual Address Pool -> checked any private address range
                                      Virtual IPv6 Address Pool -> not checked
                                      Network List -> not checked
                                      Save Auth Password -> checked
                                      DNS Default Domain -> not checked
                                      Split DNS -> not checked
                                      DNS servers -> not checked
                                      WINS Servers -> not checked
                                      Phase2 PFS Group -> not checked
                                      Login Banner -> not checked

                                      IPsec Tunnels -> Mobile Client
                                      General Information
                                      Key Exchange version -> IKEv1
                                      Internet Protocol -> IPv4
                                      Interface -> WAN
                                      Description -> Mobile VPN
                                      Phase 1 Proposal (Authentication)
                                      Authentication Method -> Mutual PSK + Auth
                                      Negotiation mode -> Aggressive (Main does not work)
                                      My Identifier -> My IP address
                                      Peer Identifier -> User distinguished name [@domain]
                                      Pre-Shared Key -> some strong password
                                      Phase 1 Proposal (Algorithms)
                                      Encryption Algorithm -> AES 256 bits
                                      Hash Algorithm -> SHA256
                                      DH Group -> 14
                                      Lifetime (Seconds) -> 86400
                                      Advanced Options
                                      Disable Key -> not checked
                                      Responder Only -> not checked
                                      NAT Traversal -> Force
                                      Dead Peer Detection -> checked
                                      Delay -> 10
                                      Max Failures -> 5

                                      Phase 2
                                      General Information
                                      Mode -> Tunnel IPv4
                                      Local Network -> LAN subnet
                                      NAT/BINAT translation -> None
                                      Description -> Only Internal Traffic Mobile VPN
                                      Phase 2 Proposal
                                      Protocol -> ESP
                                      Encryption Algorithms -> AES 128 bits
                                      Hash Algorithms -> SHA1
                                      PFS key group -> off
                                      Lifetime -> 28800

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