2.4.3 Breaks Mobile Client
-
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 -
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) -
Mobile Clients are not working for me either - and it had previously been working.
-
I've opened bug 8426 for this problem.
https://redmine.pfsense.org/issues/8426
-
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?
-
With IKEv2 it is working here as before BTW, at least with Windows and Android clients. Maybe only the Apple clients are affected?
-
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.
-
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
-
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. ::)
-
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.
-
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.
-
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
-
I can confirm, that patch does fix the vpn connection
Great!
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.
-
Ahh OK, lack of understanding on my side
Thanks again
-
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…
-
Use the System Patches package and apply the commit ID I mentioned above. See https://doc.pfsense.org/index.php/System_Patches
-
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 -
Patch application fixed the issue! Thanks!