Hi Hussaina, Any particular reason you are using IKEv1? You should just switch to IKEv2 to avoid any such issues.
> With IKEv1, when strongSwan(as responder) sends INVALID-ID-INFORMATION > for IDii/IDir mismatch, it does not send SPI value of IKE SA. However, > it sends 0 SPI in the quickmode negotiation along with HASH payload and > N(INVALID-ID-INFORMATION). If you are referring to a mismatch in traffic selectors during Quick Mode, then I can't confirm that. The INFORMATIONAL sent by strongSwan contains both SPIs (or "Cookies") in the IKE header in my tests, and it is processed accordingly by the IKE_SA of the initiator. What strongSwan version are you using? > Can someone clarify, whether strongSwan should send valid SPI with the > N(INVALID-ID-INFORMATION) or not ? Hm, are you referring to the column captioned "SPI" in the table in section 2.4 of RFC 2408? If so, then definitely not. That refers to the SPI field in the Proposal payload (section 3.5 in the RFC). Since there is no such Payload in the INFORMATIONAL error response, there is also no SPI field to set. Regards, Tobias
