IOS 11.3 Clients Broken But MacOS Clients Work
-
None of the iOS 11.3 clients can connect although they used to before 11.3
The pfSense code was also updated about the same time - sorry, not sure which came first. I'll keep better records now.
MacOS clients continue to connect with same user.iOS log shows: nesessionmanager ne_sm_bridge_logv:1139 IPSec Controller: IKE FAILED. phase 2, assert 0
Phase 2 settings are:
<phase2><ikeid>1</ikeid> <uniqid>5a59023669c88</uniqid> <mode>tunnel</mode> <reqid>1</reqid> <localid><type>network</type> <address>0.0.0.0</address> <netbits>0</netbits></localid> <protocol>esp</protocol> <encryption-algorithm-option><name>aes</name> <keylen>128</keylen></encryption-algorithm-option> <hash-algorithm-option>hmac_sha1</hash-algorithm-option> <pfsgroup>0</pfsgroup> <lifetime>288000</lifetime></phase2>
pfSense Version:
2.4.3-RELEASE (amd64) built on Mon Mar 26 18:02:04 CDT 2018 FreeBSD 11.1-RELEASE-p7
-
Needs a lot more detail to say for sure.
Is this with IKEv1 (xauth+psk?) or IKEv2? What logs show on pfSense?
The only issue I'm aware of that affects iOS with IPsec on 2.4.3 is for IKEv1 xauth+psk clients, and that fails in Phase 1, not Phase 2. If you are using xauth you might still give the fix a try:
https://redmine.pfsense.org/issues/8426
-
Thank you for your assistance.
I applied the fad13c4142bba5c24e2a1d4739d46a5ff9c7ed19 patch prior to this call for help but it didn't help with my issue.
I attached a file of the transactions until the iPhone responded with "Negotiation with the VPN server failed."
I changed IP address to 00.00.00.00 and user to VPN_USER for anonymity.
(Note: I was attempting this time from inside the network but we first found it stopped working while away from LAN.)It is IKEv (psk+xauth) aggressive.
-
I'm not sure how that would have worked before, the client and server do not have a matching config:
pfSense wants:
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024Client wants:
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"If you add AES-256, SHA1, DH Group 14 to your config on pfSense it should allow that through
-
I'm totally stumped. I added a second proposal of AES/256/SHA1/DH14(2048) but it still failed.
So, I started fresh and created new pfSense config according to https://doc.pfsense.org/index.php/IPsec_Road_Warrior/Mobile_Client_How-To (except I also added a second proposal of AES/256/SHA1/DH14).
I deleted the iOS profile and created a new one on the device by hand using user/password/sharedkey ipsec.
I connected the iOS device to MacOS console and got these notable error log entries on iOS:error 13:31:10.857375 -0400 nesessionmanager ne_sm_bridge_logv:1139 racoon_trigger_phase2 sent ping, wrote -1 [my comment - the above was repeated many times] error 13:35:41.450207 -0400 racoon failed to send vpn_control message: Broken pipe
I attached the pfsense log.
Again, I tried VPN connect with same hand-entered profile from a local MacOS and it worked perfectly.
Thanks for your patience. -
Sometimes it has worked (not keeping score but I'd say 1/5 and it will continue to work if I disconnect/reconnect).
When it doesn't work, after about 5 seconds I'll get an auth password request for user but filling it in doesn't help and it disconnects. The ogs look like below. You'll notice everything is proceeding normally and user is authenticated then it says "reinitiating already active tasks" which is when it trys to auth again.11[IKE] <con1|84>remote host is behind NAT 11[IKE] <con1|84>activating new tasks 11[IKE] <con1|84>activating XAUTH task 11[ENC] <con1|84>generating TRANSACTION request 3165109699 [ HASH CPRQ(X_USER X_PWD) ] 11[NET] <con1|84>sending packet: from LOCAL_IP[4500] to REMOTE_IP[3150] (76 bytes) 11[NET] <con1|84>received packet: from REMOTE_IP[3150] to LOCAL_IP[4500] (92 bytes) 11[ENC] <con1|84>parsed INFORMATIONAL_V1 request 456924019 [ HASH N(INITIAL_CONTACT) ] 11[IKE] <con1|84>sending retransmit 1 of request message ID 3165109699, seq 1 11[NET] <con1|84>sending packet: from LOCAL_IP[4500] to REMOTE_IP[3150] (76 bytes) 06[NET] <con1|84>received packet: from REMOTE_IP[3150] to LOCAL_IP[4500] (92 bytes) 06[ENC] <con1|84>parsed TRANSACTION response 3165109699 [ HASH CPRP(X_USER X_PWD) ] user 'VPN_USER' authenticated 06[IKE] <con1|84>XAuth-SCRIPT succeeded for user 'VPN_USER'. 06[IKE] <con1|84>XAuth authentication of 'VPN_USER' successful 06[IKE] <con1|84>reinitiating already active tasks 06[IKE] <con1|84>XAUTH task</con1|84></con1|84></con1|84></con1|84></con1|84></con1|84></con1|84></con1|84></con1|84></con1|84></con1|84></con1|84></con1|84></con1|84></con1|84>
-
Found a work-around and started new post:
https://forum.pfsense.org/index.php?topic=146804.0 -
iOS 11.3 only presents the following as acceptable encryption
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 [group 14 - minimum] IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256 [group 19 - acceptable] IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536 [group 5 - avoid] IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
In order to get iOS 11.3 clients to work, I needed to add a phase 1 proposal possibility:
AES 256bits SHA256 DH-Group-19
The other encryption algorithms I had for Windows (AES 256 SHA384 20) didn't work.For completeness, my Phase 2 is AES-256bit and SHA256/SHA384/SHA512 and PFS group 20.
DH group 5 and group 14 was tested as well but is not recommended.
Commentary on the DH groups is provided by:
https://supportforums.cisco.com/t5/security-documents/diffie-hellman-groups/ta-p/3147010 -
DH group 5 and group 14 was tested as well but is not recommended.
Commentary on the DH groups is provided by:
https://supportforums.cisco.com/t5/security-documents/diffie-hellman-groups/ta-p/3147010This chart from strongSwan is a bit more informative and has better info than that post:
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites#Diffie-Hellman-Groups