[strongSwan] deleting half open IKE_SA after timeout

[Denis Zinevich]

Hello,

my previous suggestion was wrong. I've compared tcpdumps on working and non-working hosts again, and found that in broken case client continues to re-send this packed to server:

19:53:09.673551 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 1212)
    93.74.135.165.4500 > 179.179.179.179.4500: [udp sum ok] NONESP-encap: isakmp 1.0 msgid 00000000 cookie 7c7f3d5d2c5f466b->5121f3fa3093c391: phase 1 I ident[E]: [encrypted id]
19:53:09.673935 IP (tos 0x0, ttl 64, id 28340, offset 0, flags [+], proto UDP (17), length 1500)
    179.179.179.179.4500 > 93.74.135.165.4500: NONESP-encap: isakmp 1.0 msgid 00000000 cookie 7c7f3d5d2c5f466b->5121f3fa3093c391: phase 1 R ident[E]: [encrypted id] (len mismatch: isakmp 1660/ip 1468)

server is 179.179.179.179
I've checked network connectivity via netcat (udp, both ports - 500 and 4500)  - no probelms.
Unfortunatelly didn't manage to dump traffic on client side since it's mobile devices.
Reproducable 100% times, tried 2 clients - iOS and Android. both can connect to other servers with same setings.
Asked hoster about firewall/restrictions - they said nothing blocked.
Checked freeradus - it never receives auth request from strongswan, so probably client auth message do not reach server. But since network connectivity looks fine I can't find any reason why Xauth packed should be lost. Is there anything special with Xauth that can be blocked by firewalls ? 
I understand that I can't blame strongswan here, that's still looks like network issue but I need some hints to understand how to further debug it.



27.02.2015, 17:05, "Denis Zinevich" <link at ngc.net.ua>:
> Hello Martin,
>
> same client connects to other servers successfully, with same credentials. After I change server name - connection fails.
> and this happend only with one particular server, so according to your explanation either client didn't get XAuth request or server didn't get reply.
> I've just tried to compare tcpdumps from two machines (good and bad ones) and thet look similar except one string (with  ip-proto-17)
>
>
> Thanks for your help, looks like network issue, will digg in that direction.
>
> 27.02.2015, 16:50, "Martin Willi" <martin at strongswan.org>:
>>  Hi Denis
>>>   07[ENC] generating ID_PROT response 0 [ ID CERT SIG ]
>>>   07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes)
>>>   07[ENC] generating TRANSACTION request 2234314252 [ HASH CPRQ(X_USER X_PWD) ]
>>>   07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (76 bytes)
>>>   10[IKE] sending retransmit 1 of request message ID 2234314252, seq 1
>>  strongSwan requests XAuth authentication from the client, but the client
>>  does not seem to answer. Either it does not get the message, the user is
>>  not entering the credentials in time, or more likely, it does not expect
>>  an XAuth username/password request.
>>
>>  Most likely your client is not configured to do XAuth, or it is one of
>>  those clients that want to skip XAuth authentication during the ISAKMP
>>  reauthentication procedure (iOS, OS X). We strictly require that, as we
>>  think just skipping XAuth is a security issue.
>>
>>  Regards
>>  Martin
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users