[strongSwan] Same config for strongSwan, different outcome between Android and iOS
Laurens Vets
laurens at daemon.be
Fri Jul 15 05:57:18 CEST 2016
Hello Tobias,
>>>>>> I've added 'fragmentation=yes' to the server, same issue.
>>>>>
>>>>> Please have a look at the client log. Does it send an IKE_AUTH
>>>>> message?
>>>>> Is it fragmented? If so, check with Wireshark/tcpdump on the
>>>>> server
>>>>> whether any packets arrive.
>>>>
>>>> I can send log files from working & non working sessions.
>>>
>>> If you have server and client logs of a working and a non-working
>>> session that might help. The server log of a working session with
>>> the
>>> iPhone might be useful too.
>>
>> See attached files.
>
> Thanks. The Android client splits the IKE_AUTH message (3628 bytes)
> into 4 fragments. In the unsuccessful case some of these don't reach
> the server and the client gives up after 3 retransmits. On the server
> this looks like this:
>
>> Jul 7 00:09:38 irkalla charon: 10[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:09:38 irkalla charon: 10[ENC] received fragment #1 of 4,
>> waiting for complete IKE message
>> Jul 7 00:09:38 irkalla charon: 06[NET] received packet: from
>> 1.1.1.1[52708] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:09:38 irkalla charon: 06[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:09:38 irkalla charon: 06[ENC] received fragment #2 of 4,
>> waiting for complete IKE message
>> Jul 7 00:09:38 irkalla charon: 16[JOB] deleting half open IKE_SA
>> after timeout
>> Jul 7 00:09:40 irkalla charon: 08[NET] received packet: from
>> 1.1.1.1[52708] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:09:40 irkalla charon: 08[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:09:40 irkalla charon: 08[ENC] received duplicate fragment #1
>> Jul 7 00:09:40 irkalla charon: 10[NET] received packet: from
>> 1.1.1.1[52708] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:09:40 irkalla charon: 10[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:09:40 irkalla charon: 10[ENC] received duplicate fragment #2
>> Jul 7 00:09:43 irkalla charon: 08[NET] received packet: from
>> 1.1.1.1[52708] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:09:43 irkalla charon: 08[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:09:43 irkalla charon: 08[ENC] received duplicate fragment #1
>> Jul 7 00:09:47 irkalla charon: 12[NET] received packet: from
>> 1.1.1.1[52708] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:09:47 irkalla charon: 12[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:09:47 irkalla charon: 12[ENC] received duplicate fragment #1
>
> We see that only fragment 1 and occasionally 2 of the four are
> received.
> And even in the successful case (behind the WiFi) do all fragments
> only
> get through after sending a third retransmit:
>
>> Jul 7 00:26:23 irkalla charon: 05[NET] received packet: from
>> 1.1.1.1[56080] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:26:23 irkalla charon: 05[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:26:23 irkalla charon: 05[ENC] received fragment #1 of 4,
>> waiting for complete IKE message
>> Jul 7 00:26:23 irkalla charon: 08[NET] received packet: from
>> 1.1.1.1[56080] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:26:23 irkalla charon: 08[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:26:23 irkalla charon: 08[ENC] received fragment #2 of 4,
>> waiting for complete IKE message
>> Jul 7 00:26:25 irkalla charon: 10[NET] received packet: from
>> 1.1.1.1[56080] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:26:25 irkalla charon: 10[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:26:25 irkalla charon: 10[ENC] received duplicate fragment #1
>> Jul 7 00:26:25 irkalla charon: 11[NET] received packet: from
>> 1.1.1.1[56080] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:26:25 irkalla charon: 11[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:26:25 irkalla charon: 11[ENC] received duplicate fragment #2
>> Jul 7 00:26:27 irkalla charon: 08[NET] received packet: from
>> 1.1.1.1[56080] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:26:27 irkalla charon: 08[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:26:27 irkalla charon: 08[ENC] received duplicate fragment #1
>> Jul 7 00:26:31 irkalla charon: 12[NET] received packet: from
>> 1.1.1.1[56080] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:26:31 irkalla charon: 12[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:26:31 irkalla charon: 12[ENC] received duplicate fragment #1
>> Jul 7 00:26:31 irkalla charon: 06[NET] received packet: from
>> 1.1.1.1[56080] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:26:31 irkalla charon: 06[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:26:31 irkalla charon: 06[ENC] received duplicate fragment #2
>> Jul 7 00:26:31 irkalla charon: 06[NET] received packet: from
>> 1.1.1.1[56080] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:26:31 irkalla charon: 06[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:26:31 irkalla charon: 06[ENC] received fragment #3 of 4,
>> waiting for complete IKE message
>> Jul 7 00:26:31 irkalla charon: 13[NET] received packet: from
>> 1.1.1.1[56080] to 2.2.2.2[4500] (80 bytes)
>> Jul 7 00:26:31 irkalla charon: 13[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:26:31 irkalla charon: 13[ENC] received fragment #4 of 4,
>> reassembling fragmented IKE message
>> Jul 7 00:26:31 irkalla charon: 13[ENC] parsed IKE_AUTH request 1 [
>> IDi N(INIT_CONTACT) CERTREQ CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N)
>> SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
>
> So there seems to be some massive packet loss here (even the small
> fourth message is often dropped). No idea why it would specifically
> affect the IKE_AUTH packets as the rest of them seem to get through
> fine
> (as do the IKE_AUTH fragments sent by the server). Would be
> interesting
> to know where exactly they are dropped. Does your NAT router have an
> IPsec passthrough functionality? If so, try dis- or enabling it to see
> if it makes a difference.
Cannot find anything related to IPSEC, IKE or UDP 500 or 4500. It's a
crappy cable modem. Maybe it's time to change it to something decent. It
has IP Passthrough, so using it as a bridge should be possible.
> In the 4G case all fragments are received on the first try:
>
>> Jul 7 00:17:46 irkalla charon: 10[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:17:46 irkalla charon: 10[ENC] received fragment #1 of 4,
>> waiting for complete IKE message
>> Jul 7 00:17:46 irkalla charon: 16[NET] received packet: from
>> 209.52.88.67[3165] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:17:46 irkalla charon: 16[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:17:46 irkalla charon: 16[ENC] received fragment #2 of 4,
>> waiting for complete IKE message
>> Jul 7 00:17:46 irkalla charon: 05[NET] received packet: from
>> 209.52.88.67[3165] to 2.2.2.2[4500] (1248 bytes)
>> Jul 7 00:17:46 irkalla charon: 05[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:17:46 irkalla charon: 05[ENC] received fragment #3 of 4,
>> waiting for complete IKE message
>> Jul 7 00:17:46 irkalla charon: 09[NET] received packet: from
>> 209.52.88.67[3165] to 2.2.2.2[4500] (80 bytes)
>> Jul 7 00:17:46 irkalla charon: 09[ENC] parsed IKE_AUTH request 1 [ EF
>> ]
>> Jul 7 00:17:46 irkalla charon: 09[ENC] received fragment #4 of 4,
>> reassembling fragmented IKE message
>> Jul 7 00:17:46 irkalla charon: 09[ENC] parsed IKE_AUTH request 1 [
>> IDi N(INIT_CONTACT) CERTREQ CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N)
>> SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
>
> And the iPhone sends a massively smaller IKE_AUTH message (496 bytes),
> which does not require fragmentation.
>
> The latter is of course because it does not send any certificate
> requests, whereas 156 of them are sent by the Android app (each a 20
> byte SHA-1 hash). As I mentioned before, you can avoid that by
> selecting your CA certificate in the VPN profile in the app. This
> should avoid having to fragment the IKE_AUTH message and might improve
> the success rate significantly.
This last bit brings me to my next problem. From the file
OnePlusOne_20160607_Wifi_Working1_ClientLog, I get this:
Jul 6 17:26:31 06[IKE] received end entity cert "CN=us.npu.io"
Jul 6 17:26:31 06[CFG] using certificate "CN=us.npu.io"
Jul 6 17:26:31 06[CFG] using trusted intermediate ca certificate
"C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
Jul 6 17:26:31 06[CFG] using trusted ca certificate "O=Digital
Signature Trust Co., CN=DST Root CA X3"
Jul 6 17:26:31 06[CFG] reached self-signed root ca with a path length
of 1
Jul 6 17:26:31 06[IKE] authentication of 'us.npu.io' with RSA signature
successful
If I select the certificate "Digital Signature Trust Co., DST Root CA
X3". I get a new error message:
Jul 14 19:47:22 13[IKE] received end entity cert "CN=us.npu.io"
Jul 14 19:47:22 13[CFG] using certificate "CN=us.npu.io"
Jul 14 19:47:22 13[CFG] no issuer certificate found for "CN=us.npu.io"
Jul 14 19:47:22 13[IKE] no trusted RSA public key found for 'us.npu.io'
Jul 14 19:47:22 13[ENC] generating INFORMATIONAL request 2 [
N(AUTH_FAILED) ]
Any idea what I'm missing now?
Thank you for your help so far!
Regards,
Laurens
More information about the Users
mailing list