strongSwan

We are finding that very occasionally during a Quick Mode exchange the responder receives the final packet very early, before it has finished processing the previous packet, and it generates a log entry like "ignoring request with ID 3584557445, already processing".

Yes, makes sense. This is a race condition between the thread that sent the second QM message and is cleaning up and the thread that processes the third QM message. Since resetting the IKE_SA entry's processing member to 0 is pretty much the last step for the first thread, it's possible that the second thread finds that value still set to the QM's message ID.

The fix that worked for us was to modify get_message_id_or_hash() to make it return message hash, rather than message ID, for Quick Mode exchange messages - see attached patch.

I guess we could change that generally for IKEv1 and just use hashes there. Only for INFORMATIONAL exchanges we don't expect more than one message with the same MID, or even retransmits, so we could still use MIDs there. I pushed such a change to the 1198-ikev1-mid-hash branch. Let me know if that works for you.

Thanks for testing. The patch I now merged is actually more like the one you posted because for TRANSACTION exchanges the MID is also still usable (and probably slightly quicker).