pfSense 2.5 breaks Android VPN client

jimp

Need a lot more information here. What type of config? IKEv2 (and what type)? Xauth? Something else?

untermensch

@jimp I used this guide to set up my clients.

https://pfsense-docs.readthedocs.io/en/latest/vpn/ipsec/configuring-an-ipsec-remote-access-mobile-vpn-using-ikev2-with-eap-mschapv2.html

jimp

That doc site is not official, it's an outdated copy. Compare your setup against the current one at https://docs.pfsense.org/

Also, are you using the strongSwan client on Android or something built-in?

If you are using SHA256 in P1 or P2, you might change it. Someone else reported that their Android clients wouldn't work until they changed away from SHA256 -- it's not clear yet if something changed on FreeBSD/strongSwan or in Android that might affect it.

untermensch

@jimp The VPN client is built into the phones firmware and hasn't been updated in a few years. when the "network list" option is checked the router thinks the client is connected, but it isn't routing traffic.

When I uncheck the "network list" option the client connects normally.

client log:

coINFO: 13:06:47 Routing instance global initialized with id 0 mapped to inode 18446744073709551615

INFO: 13:06:47 Routing instance global activated.

INFO: 13:06:47 Added new interface: 2

INFO: 13:06:47  2: \`dummy0' [Routing instance=0:global MTU=1500]

INFO: 13:06:47     fe80::9482:8dff:fe97:a6db/64

INFO: 13:06:47 Added new interface: 5

INFO: 13:06:47  5: \`rmnet_ipa0' [Routing instance=0:global MTU=2000]

INFO: 13:06:47 Added new interface: 6

INFO: 13:06:47  6: \`wlan0' [Routing instance=0:global MTU=1500]

INFO: 13:06:47     fe80::de0b:34ff:fec1:a4d5/64

INFO: 13:06:47     192.168.1.139/24

INFO: 13:06:47 Added new interface: 11

INFO: 13:06:47 11: \`rmnet_data1' [Routing instance=0:global MTU=1440]

INFO: 13:06:47     fe80::9489:800d:a4d5:5c4a/64

INFO: 13:06:47     2607:fc20:3277:cf2a:9489:800d:a4d5:5c4a/64

INFO: 13:06:47 IKEv2 packet S(192.168.1.139:41419 -> 67.189.4.80:500): len= 1104, mID=0, HDR, SA, KE, Nonce, N(NAT*DETECTION*SOURCE*IP), N(NAT*DETECTION*DESTINATION*IP), N(FRAGMENTATION_SUPPORTED), Vid

INFO: 13:06:47 IKEv2 packet R(192.168.1.139:41419 <- 67.189.4.80:500): len=   38, mID=0, HDR, N(INVALID*KE*PAYLOAD)

INFO: 13:06:47 IKEv2 packet S(192.168.1.139:41419 -> 67.189.4.80:500): len= 1872, mID=0, HDR, SA, KE, Nonce, N(NAT*DETECTION*SOURCE*IP), N(NAT*DETECTION*DESTINATION*IP), N(FRAGMENTATION_SUPPORTED), Vid

INFO: 13:06:48 IKEv2 packet S(192.168.1.139:41419 -> 67.189.4.80:500): mID=0 (retransmit count=1)

INFO: 13:06:49 IKEv2 packet R(192.168.1.139:41419 <- 67.189.4.80:500): len= 1249, mID=0, HDR, SA, KE, Nonce, N(NAT*DETECTION*SOURCE*IP), N(NAT*DETECTION*DESTINATION*IP), CERTREQ, N(FRAGMENTATION*SUPPORTED), unknown, N(MULTIPLE*AUTH_SUPPORTED)

INFO: 13:06:49 IKEv2 packet S(192.168.1.139:41419 -> 67.189.4.80:500): len=  752, mID=1, HDR, IDi, CERTREQ, CP, SA, TSi, TSr, N(HTTP*CERT*LOOKUP*SUPPORTED), N(INITIAL*CONTACT), N(SET*WINDOW*SIZE), N(ESP*TFC*PADDING*NOT*SUPPORTED), N(NON*FIRST*FRAGMENTS_ALSO)

INFO: 13:06:49 IKEv2 fragment #1/2 R(192.168.1.139:41419 <- 67.189.4.80:500): len= 1219, mID=1

INFO: 13:06:49 IKEv2 fragment #2/2 R(192.168.1.139:41419 <- 67.189.4.80:500): len=  475, mID=1

INFO: 13:06:49 IKEv2 payloads received: mID=1, HDR, IDr, CERT, AUTH, EAP

INFO: 13:06:49 EAP exchange started

INFO: 13:06:49 Remote certificate validation started

INFO: 13:06:49 Remote certificate validation successful

INFO: 13:06:49 IKEv2 packet S(192.168.1.139:41419 -> 67.189.4.80:500): len=  112, mID=2, HDR, EAP

INFO: 13:06:49 IKEv2 packet R(192.168.1.139:41419 <- 67.189.4.80:500): len=   88, mID=2, HDR, EAP

INFO: 13:06:49 IKEv2 packet S(192.168.1.139:41419 -> 67.189.4.80:500): len=  176, mID=3, HDR, EAP

INFO: 13:06:49 IKEv2 packet R(192.168.1.139:41419 <- 67.189.4.80:500): len=  125, mID=3, HDR, EAP

INFO: 13:06:49 IKEv2 packet S(192.168.1.139:41419 -> 67.189.4.80:500): len=   96, mID=4, HDR, EAP

INFO: 13:06:49 IKEv2 packet R(192.168.1.139:41419 <- 67.189.4.80:500): len=   56, mID=4, HDR, EAP

INFO: 13:06:49 EAP exchange successful

INFO: 13:06:49 IKEv2 packet S(192.168.1.139:41419 -> 67.189.4.80:500): len=  160, mID=5, HDR, AUTH

INFO: 13:06:49 IKEv2 packet R(192.168.1.139:41419 <- 67.189.4.80:500): len=  260, mID=5, HDR, AUTH, CP, N(ESP*TFC*PADDING*NOT*SUPPORTED), SA, TSi, TSr

INFO: 13:06:49 

INFO: 13:06:49 IKEv2 SA [Initiator] negotiation failed:

INFO: 13:06:49 

INFO: 13:06:49   Routing instance 0:global

INFO: 13:06:49   Local IKE peer  192.168.1.139:41419 ID (null)

INFO: 13:06:49   Remote IKE peer 67.189.4.80:500 ID (null)

INFO: 13:06:49 

INFO: 13:06:49   Message: SA unusable (65553)

INFO: 13:06:49 IKE SA negotiations: 3 done, 1 successful, 2 failed

INFO: 13:06:49 

INFO: 13:06:49 IPsec SA [Initiator] negotiation failed:

INFO: 13:06:49 

INFO: 13:06:49   Routing instance 0:global

INFO: 13:06:49   Local IKE peer  192.168.1.139:41419 ID (null)

INFO: 13:06:49   Remote IKE peer 67.189.4.80:500 ID (null)

INFO: 13:06:49 

INFO: 13:06:49   Message: SA unusable (65553)

INFO: 13:06:49 IPsec SA negotiations: 3 done, 1 successful, 2 failed

INFO: 13:06:49 Phase-I negotiation failed

INFO: 13:06:49   Message: SA unusable (65553)

ERROR: 13:06:49 connection failure ike error 65535 backoff_timer -1.de_text

jimp

Compare the contents of /var/etc/ipsec/swanctl.conf with that option enabled and disabled. What are the differences for you?

There must be something in that field which the client has deemed invalid.

untermensch

@jimp here is the diff for /var/etc/ipsec/swanctl.conf

--- good.conf	2021-02-25 00:18:46.186276000 +0000
+++ bad.conf	2021-02-25 00:20:21.584571000 +0000
@@ -60,6 +60,8 @@
pools {
	mobile-pool-v4 : mobile-pool {
		addrs = 172.16.10.0/24
+		subnet = 0.0.0.0/0
+		split_include = 0.0.0.0/0
	}
}
secrets {

jimp

Did that actually work before?

Seems to me that would be invalid since it's not split tunneling, it's tunneling all, which is usually a separate option in a client (or its default behavior).

If you don't mind some debugging, can you try editing the code so it either uses only subnet or only split_include and see which one the client is actually rejecting?

https://github.com/pfsense/pfsense/blob/RELENG_2_5_0/src/etc/inc/ipsec.inc#L1560

untermensch

@jimp
Yep, it worked for years...

When I comment out only split_include the android client connects succesfully, when I comment out only subnet the client fails to connect.

jimp

Hmm, ok.

I can't find a lot of good info on the strongSwan docs about the specific intent of both since things get muddied between the IKEv1+Unity and IKEv2 uses.

At the very least we could skip adding split_include entries for 0.0.0.0/0 and ::/0 though since they wouldn't be necessary.

I'll keep looking through the strongSwan docs as time allows. I started https://redmine.pfsense.org/issues/11539 to track it.

jimp

Apparently I don't have a good way to test this. I checked several of my Android devices and the only one that has an IKEv2 option in the built-in client is a Pixel on Android 11 and there is apparently a bug preventing it from working there at all (unrelated to this option). The strongSwan app connects with and without the split_include line having 0.0.0.0/0.

You can install the System Patches package and then create an entry for the attached patch to try the fix to see if it helps. After applying, you'll need to edit/save/apply on the IPsec settings.

11539-split-fix.diff

untermensch

@jimp I applied the patch, verified that split_include was no longer in included in /var/etc/ipsec/swanctl.conf and connected the android VPN client. The Android IPSec client now connects successfully regardless of the Network List setting. Thanks.