[strongSwan] deleting half open IKE_SA after timeout

[Denis Zinevich]

Hello Volker,

I tried "fragmentation=yes" before, but in specific connection section, not in %default, and it didn't make any effect. Now in %default section it solved my problem.
Now I have enough evidence and knowledge to troubleshoot network together with hoster tech support.
Thanks a lot !

01.03.2015, 19:17, "Volker Rümelin" <vr_strongswan at t-online.de>:
> Hi Denis,
>>  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)
>
> you have a network problem. As you can see from the flags [+] this is
> the first fragment of a UDP message. The following fragment is missing.
> A router or firewall dropped it on route to your server.
>>  14:44:12.274524 IP 179.179.179.179.4500 > 46.211.137.122.43918: NONESP-encap: isakmp: phase 1 R ident[E]
>>  14:44:12.274536 IP 179.179.179.179 > 46.211.137.122: ip-proto-17
>
> The second packet from your working example is the fragment you are missing.
>
> If fixing your network problem is not an option, you can try if
> fragmentation=yes in the conn %default section in ipsec.conf helps.
>
> Regards,
> Volker