[strongSwan] Same config for strongSwan, different outcome between Android and iOS

[Tobias Brunner]

Hi Laurens,
>>>>> 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.

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.

Regards,
Tobias