4. IOS 11.3 Clients Broken But MacOS Clients Work

IOS 11.3 Clients Broken But MacOS Clients Work

  • S

    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
    0
  • Rebel Alliance Developer Netgate

    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

    0
  • S

    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.

    charon_2018-4-16-10_26_52.txt

    0
  • Rebel Alliance Developer Netgate

    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_1024

    Client 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

    0
  • S

    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.

    charon_2018-4-16-13_35.txt

    0
  • S

    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>
    0
  • S

    Found a work-around and started new post:
    https://forum.pfsense.org/index.php?topic=146804.0

    0
  • P

    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

    0
  • Rebel Alliance Developer Netgate

    @PhYrE:

    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

    This 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

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2019 Rubicon Communications, LLC | Privacy Policy