PfSense 2.3.2 fails with macOS 10.11.6 native Cisco-style VPN client (IKE v1)
-
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.
-
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?
-
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.
-
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 checkedIPsec 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 -> 5Phase 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