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

    2.4.3 Breaks Mobile Client

    Scheduled Pinned Locked Moved IPsec
    18 Posts 8 Posters 2.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B
      bigjme93
      last edited by

      Hi All,

      I've had a working mobile VPN for around a year now and today i've upgraded to version 2.4.3 and the vpn can no longer connect

      I'm connecting from the default android vpn using IPSec Xauth PSK. I've checked the IPSec logs and i'm getting these:

      Mar 29 20:35:01	charon		08[IKE] <3> ID_PROT request with message ID 0 processing failed
Mar 29 20:35:01	charon		08[NET] <3> sending packet: from xxx.xxx.xxx.xxx[500] to 178.111.153.27[500] (76 bytes)
Mar 29 20:35:01	charon		08[ENC] <3> generating INFORMATIONAL_V1 request 3499638187 [ HASH N(PLD_MAL) ]
Mar 29 20:35:01	charon		08[IKE] <3> message parsing failed
Mar 29 20:35:01	charon		08[ENC] <3> could not decrypt payloads
Mar 29 20:35:01	charon		08[ENC] <3> invalid ID_V1 payload length, decryption failed?
Mar 29 20:35:01	charon		08[NET] <3> received packet: from 178.111.153.27[500] to xxx.xxx.xxx.xxx[500] (92 bytes)
Mar 29 20:35:01	charon		08[NET] <3> sending packet: from xxx.xxx.xxx.xxx[500] to 178.111.153.27[500] (244 bytes)
Mar 29 20:35:01	charon		08[ENC] <3> generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
Mar 29 20:35:01	charon		08[CFG] <3> candidate "con1", match: 1/1/1052 (me/other/ike)
Mar 29 20:35:01	charon		08[CFG] <3> candidate "bypasslan", match: 1/1/24 (me/other/ike)
Mar 29 20:35:01	charon		08[ENC] <3> parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
Mar 29 20:35:01	charon		08[NET] <3> received packet: from 178.111.153.27[500] to xxx.xxx.xxx.xxx[500] (228 bytes)
Mar 29 20:35:01	charon		08[NET] <3> sending packet: from xxx.xxx.xxx.xxx[500] to 178.111.153.27[500] (160 bytes)
Mar 29 20:35:01	charon		08[ENC] <3> generating ID_PROT response 0 [ SA V V V V ]
Mar 29 20:35:01	charon		08[IKE] <3> sending NAT-T (RFC 3947) vendor ID
Mar 29 20:35:01	charon		08[IKE] <3> sending FRAGMENTATION vendor ID
Mar 29 20:35:01	charon		08[IKE] <3> sending DPD vendor ID
Mar 29 20:35:01	charon		08[IKE] <3> sending XAuth vendor ID
Mar 29 20:35:01	charon		08[CFG] <3> selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Mar 29 20:35:01	charon		08[CFG] <3> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Mar 29 20:35:01	charon		08[CFG] <3> received proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024, 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_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/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_SHA2_256_128/PRF_HMAC_SHA2_256/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_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
Mar 29 20:35:01	charon		08[CFG] <3> proposal matches
Mar 29 20:35:01	charon		08[CFG] <3> selecting proposal:
Mar 29 20:35:01	charon		08[CFG] <3> no acceptable PSEUDO_RANDOM_FUNCTION found
Mar 29 20:35:01	charon		08[CFG] <3> selecting proposal:
Mar 29 20:35:01	charon		08[CFG] <3> no acceptable PSEUDO_RANDOM_FUNCTION found
Mar 29 20:35:01	charon		08[CFG] <3> selecting proposal:
Mar 29 20:35:01	charon		08[CFG] <3> no acceptable PSEUDO_RANDOM_FUNCTION found
Mar 29 20:35:01	charon		08[CFG] <3> selecting proposal:
Mar 29 20:35:01	charon		08[IKE] <3> IKE_SA (unnamed)[3] state change: CREATED => CONNECTING
Mar 29 20:35:01	charon		08[IKE] <3> 178.111.153.27 is initiating a Main Mode IKE_SA
Mar 29 20:35:01	charon		08[IKE] <3> received DPD vendor ID
Mar 29 20:35:01	charon		08[IKE] <3> received FRAGMENTATION vendor ID
Mar 29 20:35:01	charon		08[IKE] <3> received Cisco Unity vendor ID
Mar 29 20:35:01	charon		08[IKE] <3> received XAuth vendor ID
Mar 29 20:35:01	charon		08[IKE] <3> received draft-ietf-ipsec-nat-t-ike-00 vendor ID
Mar 29 20:35:01	charon		08[IKE] <3> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Mar 29 20:35:01	charon		08[IKE] <3> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
Mar 29 20:35:01	charon		08[IKE] <3> received NAT-T (RFC 3947) vendor ID
Mar 29 20:35:01	charon		08[CFG] <3> found matching ike config: xxx.xxx.xxx.xxx...%any with prio 1052
Mar 29 20:35:01	charon		08[CFG] <3> candidate: xxx.xxx.xxx.xxx...%any, prio 1052
Mar 29 20:35:01	charon		08[CFG] <3> candidate: %any...%any, prio 24
Mar 29 20:35:01	charon		08[CFG] <3> looking for an ike config for xxx.xxx.xxx.xxx...178.111.153.27
Mar 29 20:35:01	charon		08[ENC] <3> parsed ID_PROT request 0 [ SA V V V V V V V V ]
Mar 29 20:35:01	charon		08[NET] <3> received packet: from 178.111.153.27[500] to xxx.xxx.xxx.xxx[500] (756 bytes)

      Now i know these normally mean a PSK issue on phase one so i changes the PSK on the android client and in pfsense to "test123" and i still get the same error

      I change the pfsense user PSK and the android password to "test123" and that didn't work either

      One oddity i did have was that after upgrading, Suricata disappears from the services menu and my widget vanished. A Re-install fixed this however (in case this is relevant) but the vpn client ip is not getting blocked in their either

      My IPSec site to site vpn's are functioning without issues so its only mobile clients, i'm a little lost where to go from here now?

      Regards,
      Jamie

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

        Yeah I'm getting similar problems as well. OS X replies with a shared secret error after upgrade to 2.4.3. Nothing in the logs to indicate what the problem could be.

        ![Screenshot 2018-04-02 10.43.09.png_thumb](/public/imported_attachments/1/Screenshot 2018-04-02 10.43.09.png_thumb)
        ![Screenshot 2018-04-02 10.43.09.png](/public/imported_attachments/1/Screenshot 2018-04-02 10.43.09.png)

        1 Reply Last reply Reply Quote 0
        • C
          CKuhn84
          last edited by

          Mobile Clients are not working for me either - and it had previously been working.

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

            I've opened bug 8426 for this problem.

            https://redmine.pfsense.org/issues/8426

            1 Reply Last reply Reply Quote 0
            • L
              lst_hoe
              last edited by

              Maybe related to this change :
              "Changed IPsec Phase 1 to allow configuration of multiple IKE encryption algorithms, key lengths, hashes, and DH groups"

              Could you check if your phase 1 algorithms include something useful or simply save the desired settings again?

              1 Reply Last reply Reply Quote 0
              • L
                lst_hoe
                last edited by

                With IKEv2 it is working here as before BTW, at least with Windows and Android clients. Maybe only the Apple clients are affected?

                1 Reply Last reply Reply Quote 0
                • X
                  xpxp2002
                  last edited by

                  @lst_hoe:

                  With IKEv2 it is working here as before BTW, at least with Windows and Android clients. Maybe only the Apple clients are affected?

                  My iPhone and Mac clients are working same as before with IKEv2.

                  1 Reply Last reply Reply Quote 0
                  • B
                    bigjme93
                    last edited by

                    On my side I tried forcing ikve1 and ikve2, and leaving it on auto

                    I have also changed the encryptions used for both phase 1 and phase 2 to various different options with no change

                    Just to note, I am on the android client under android 8.0.0

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

                      @lst_hoe:

                      Maybe related to this change :
                      "Changed IPsec Phase 1 to allow configuration of multiple IKE encryption algorithms, key lengths, hashes, and DH groups"

                      Could you check if your phase 1 algorithms include something useful or simply save the desired settings again?

                      The only change in config.xml after upgrade was from this:

                      
		 <phase1><encryption-algorithm><name>aes</name>
				<keylen>256</keylen></encryption-algorithm> 
			<hash-algorithm>sha1</hash-algorithm>
			<dhgroup>2</dhgroup></phase1>

                      To this:

                      
		 <phase1><encryption><encryption-algorithm><name>aes</name>
						<keylen>256</keylen></encryption-algorithm> 
					<hash-algorithm>sha1</hash-algorithm>
					<dhgroup>2</dhgroup></encryption></phase1>

                      So, just rearranging the parameters to allow for multiple entries, as the release notes say. Re-saving the config made no difference. Tried deleting and recreating the config today, but GUI is throwing nonsensical errors at me.  ::)

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

                        @xpxp2002:

                        @lst_hoe:

                        With IKEv2 it is working here as before BTW, at least with Windows and Android clients. Maybe only the Apple clients are affected?

                        My iPhone and Mac clients are working same as before with IKEv2.

                        Yeah I'm on IKEv1, and Jim P has just updated the ticket indicating that it looks like a problem related to IKEv1 PSK handling in a new version of strongSwan.

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

                          Yep, it isn't anything in our code. I was sure I had botched something in the new dual stack stuff at first but nope, the pfSense side was all good. strongSwan 5.6.2 changed ipsec.secrets logic for IKEv1, I think I've got it sorted out now.

                          Try applying fad13c4142bba5c24e2a1d4739d46a5ff9c7ed19 with the system patches package and then edit/save/apply the mobile tunnel. Let me know if it works or fails, especially if other tunnels (IKEv1 or IKEv2) fail that are working now before adding that patch.

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

                          Need help fast? Netgate Global Support!

                          Do not Chat/PM for help!

                          1 Reply Last reply Reply Quote 0
                          • B
                            bigjme93
                            last edited by

                            Hi jimp

                            I can confirm, that patch does fix the vpn connection

                            I wasn't using StrongSwan on my android though. I am just using the in built vpn system on android 8.0.0, either way, all fixed now

                            Thank you very much

                            Jamie

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

                              @bigjme93:

                              I can confirm, that patch does fix the vpn connection

                              Great!

                              @bigjme93:

                              I wasn't using StrongSwan on my android though. I am just using the in built vpn system on android 8.0.0, either way, all fixed now

                              It's the version of strongSwan on pfSense itself to blame in this instance. It doesn't matter what the clients are running.

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

                              Need help fast? Netgate Global Support!

                              Do not Chat/PM for help!

                              1 Reply Last reply Reply Quote 0
                              • B
                                bigjme93
                                last edited by

                                Ahh OK, lack of understanding on my side

                                Thanks again

                                1 Reply Last reply Reply Quote 0
                                • R
                                  Redmac
                                  last edited by

                                  So how does the average user go about fixing this? :). I was able to get my mobile clients working by removing and re-adding the mobile client config, but split tunneling is no longer working after that…

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

                                    Use the System Patches package and apply the commit ID I mentioned above. See https://doc.pfsense.org/index.php/System_Patches

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

                                    Need help fast? Netgate Global Support!

                                    Do not Chat/PM for help!

                                    1 Reply Last reply Reply Quote 0
                                    • R
                                      Redmac
                                      last edited by

                                      Applied the patch and split tunneling still does NOT work. I may try deleting the mobile profile and recreating it again. If that doesn't do I'll have to fall back to the previous version if I can find a d/l for it.

                                      –--

                                      Update, split tunneling works. When I recreated the mobile client I had the access set to LAN instead of 0.0.0.0. My mistake

                                      Thanks for the help. All is good.
                                      Mike

                                      1 Reply Last reply Reply Quote 0
                                      • P
                                        Pashator
                                        last edited by

                                        Patch application fixed the issue! Thanks!

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