Hi, thanks a lot for the quick response! Tested the fix and it seems to work. For example here without fix it would have "halted":
2020-10-29T12:14:10.103814+00:00 test-server charon: 04[ENC] generating IKE_AUTH response 7 [ EAP/REQ/TLS ] 2020-10-29T12:14:10.104212+00:00 test-server charon: 04[NET] sending packet: from <anonymized server ip>[4500] to <anonymized client ip>[4500] (67 bytes) 2020-10-29T12:14:10.104608+00:00 test-server charon: 12[NET] received packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500] (540 bytes) 2020-10-29T12:14:10.105021+00:00 test-server charon: 12[ENC] parsed IKE_AUTH request 7 [ EF(2/3) ] 2020-10-29T12:14:10.105418+00:00 test-server charon: 12[ENC] received fragment #2 of 3, waiting for complete IKE message 2020-10-29T12:14:10.105814+00:00 test-server charon: 11[NET] received packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500] (140 bytes) 2020-10-29T12:14:10.106216+00:00 test-server charon: 11[ENC] parsed IKE_AUTH request 7 [ EF(3/3) ] 2020-10-29T12:14:10.106738+00:00 test-server charon: 11[ENC] received fragment #3 of 3, waiting for complete IKE message 2020-10-29T12:14:11.131206+00:00 test-server charon: 10[NET] received packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500] (540 bytes) 2020-10-29T12:14:11.131851+00:00 test-server charon: 10[ENC] parsed IKE_AUTH request 8 [ EF(1/2) ] 2020-10-29T12:14:11.132280+00:00 test-server charon: 10[ENC] received fragment #1 of 2, waiting for complete IKE message 2020-10-29T12:14:11.859189+00:00 test-server charon: 03[KNL] querying SAD entry with SPI c70fd0c1 2020-10-29T12:14:11.859766+00:00 test-server charon: 03[KNL] querying policy 198.18.64.2/32 === 0.0.0.0/0 in 2020-10-29T12:14:11.860201+00:00 test-server charon: 03[KNL] querying policy 198.18.64.2/32 === 0.0.0.0/0 fwd 2020-10-29T12:14:11.861436+00:00 test-server charon: 03[KNL] querying SAD entry with SPI 0edd6ac7 2020-10-29T12:14:11.862045+00:00 test-server charon: 03[KNL] querying policy 0.0.0.0/0 === 198.18.64.2/32 out 2020-10-29T12:14:14.124703+00:00 test-server charon: 06[NET] received packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500] (540 bytes) 2020-10-29T12:14:14.125303+00:00 test-server charon: 06[ENC] parsed IKE_AUTH request 8 [ EF(1/2) ] 2020-10-29T12:14:14.125708+00:00 test-server charon: 06[ENC] received duplicate fragment #1 2020-10-29T12:14:14.615193+00:00 test-server charon: 09[IKE] retransmit 2 of request with message ID 0 2020-10-29T12:14:14.615785+00:00 test-server charon: 09[NET] sending packet: from <anonymized server ip>[4500] to <anonymized client ip>[4500] (57 bytes) 2020-10-29T12:14:26.137108+00:00 test-server charon: 04[NET] received packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500] (308 bytes) 2020-10-29T12:14:26.137733+00:00 test-server charon: 04[ENC] parsed IKE_AUTH request 8 [ EF(2/2) ] 2020-10-29T12:14:26.138252+00:00 test-server charon: 04[ENC] received fragment #2 of 2, reassembling fragmented IKE message 2020-10-29T12:14:26.138723+00:00 test-server charon: 04[ENC] parsed IKE_AUTH request 8 [ EAP/RES/TLS ] 2020-10-29T12:14:26.159290+00:00 test-server charon: 04[CFG] sending RADIUS Access-Request to server 'primary' 2020-10-29T12:14:26.159689+00:00 test-server charon: 04[CFG] received RADIUS Access-Challenge from server 'primary' 2020-10-29T12:14:26.160101+00:00 test-server charon: 04[IKE] EAP_TLS payload => 61 bytes @ 0x7fe924007890 2020-10-29T12:14:26.162082+00:00 test-server charon: 04[ENC] generating IKE_AUTH response 8 [ EAP/REQ/TLS ] BR, Totti On Wed, Oct 28, 2020 at 6:09 PM Tobias Brunner <[email protected]> wrote: > Hi Totti, > > > Particularly it seems to > > occur if the previous request is fragmented and has been already > > responded and then receiving retransmission of already responded request > > only partially. After that Strongswan server is not responding to next > > request coming from client. > > Yes, I can see how this may happen. The current defragmentation state > is only cleared after all fragments of a message have been received. > Until then, fragments of other messages are ignored because the message > ID does not match. I've pushed a fix to the clear-defrag branch [1]. > > Regards, > Tobias > > [1] > > https://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/clear-defrag >
