Technical Tip: IPsec tunnel negotiation failing because of not expected message ID

[nalexiou]

Description	The article describes the message ID in IKE messages during the IPsec negotiation.
Scope	FortiOS.
Solution	The message ID is a 32-bit quantity that is included in every IKE message as part of its fixed header. The first message has the value of zero, for the IKE_SA_INIT messages (including retries of the message due to responses such as COOKIE and INVALID_KE_PAYLOAD), and it increments for each subsequent exchange. For the first AUTH message the message ID will be 1, for the second if EAP is used it will be 2 and so on. The Message ID is reset to zero in the new IKE SA after the IKE SA is rekeyed. The message ID can be verified in Wireshark: The filter 'isakmp.messageid == <ID>' can be used to filter the packets based on the message ID, for example for ID 0. In case a message is received with not the expected message ID then the IPsec negotiation will fail. This can be verified when running an IKE debug 'diagnose debug application ike -1'. Below is an example of an AUTH message received with message ID causing the negotiation to fail. ike 0: comes x.x.x.x:4500->y.y.y.y:4500,ifindex=6,vrf=0....     <--  Message received by the remote peer. ... ike 0:vpn-rath:4843: initiator received AUTH msg ike 0:vpn-rath:4843: response message_id 0, expected 1   <-- The ID is not the expected one, as it is the 1st AUTH message it should be 1. ike 0:vpn-rath:4843: malformed message ike 0:vpn-rath:4843: schedule delete of IKE SA <SA> In such cases, the remote peer should be checked as to why the correct message ID was not used. More details regarding the message ID can be found in the RFC: https://www.rfc-editor.org/rfc/rfc5996.