PfSense 2.3.2 fails with macOS 10.11.6 native Cisco-style VPN client (IKE v1)
-
Bug has been created for this issue. Bug ID 6745.
-
Great. I'll track the issue there. I have some verbose logs from the Mac side I'll work through over the weekend and see if there is anything more there - it certainly shows both the 2048 & 1024 modp option but I could see anything that showed where the decision is made to send the wrong value to the server. I'll update the bug if I find anything potentially useful.
Thanks for putting in the work on this.
-
I was able to configure L2TP over IPSec in pfSense 2.3.2 and connect from a macOS 10.11.6 built-in L2TP over IPSec Client.
The transform configured in IKE Phase 1 is as follows:
Authentication Method: Mutual PSK
Negotiation Mode: Main
My Identifier: My IP Address
Encryption Algorithm: AES (256 bits)
Hash Algorithm (SHA256)
DH Group: 14 (2048 bit)
Lifetime (Seconds): 28800–----------
IKE Phase 2 Policy:
Mode: Transport
Protocol: ESP
Encryption Algorithms: AES (128 bits)
Hash Algorithm: SHA1
PFS key group: off
Lifetime: 28800
L2TP over IPSec uses the same concepts of IKE Phase 1 and IKE Phase 2. The difference is that in L2TP over IPSec's IKE Phase 1, the Negotiation Mode used is Main (instead of Aggressive), and in its IKE Phase 2, the Mode used is Transport (instead of Tunnel).
Per the Apple document linked to in one of my posts above, it's apparent that Apple modified the behavior of its Cisco VPN client and L2TP over IPSec VPN client the same way starting with macOS 10.11.6. Therefore, in my opinion, the problem that is reported in this thread (with pfSense 2.3.2 not being able to negotiate IKE Phase 1 with macOS 10.11.6 Cisco VPN client) is on the pfSense end, and not on the macOS end.
-
FWIW I followed the thread using Apple Configurator 2 to generate a config file, and that worked fine for IKEv2 and various DH and cipher settings and RADIUS auth. It'd be good if it worked with the defaults Preferences uses though.
-
FWIW I followed the thread using Apple Configurator 2 to generate a config file, and that worked fine for IKEv2 and various DH and cipher settings and RADIUS auth. It'd be good if it worked with the defaults Preferences uses though.
This thread is about IKEv1 with PSK and X-Auth.
-
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.
-
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.
-
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.
-
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.
-
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|/0Works 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> -
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 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_2048Derelict,
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!
-
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.
-
The logs I posted above say it works just fine. There is something peculiar about your environment it looks like.
-
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.
-
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.
-
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!
-
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?
-
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… :)
-
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.