[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