VPN Tunnel slow to 'sync' - Failed the cookie negotiation

[Stephen Carter]

OK, so I have 2 firepower 1200's running the same s/w, the same configuration, everything is the same (apart from the specific vpn config).

I have a customer with a single end point and from each firepower I have a VPN IKEv2 point to point link.

On testing, when link 'A' is reset the tunnel 're-auths' in about 10 seconds, however link 'B' takes an extra 25 seconds to 're-auth'.

On checking the logging I can see that there is a 'Failed the cookie negotiation' message.

Now I've searched everywhere and googled until the cows have come home but I can't find anything that points to the reasons why this is happening.

Any one out there with any insight as to what's happening and why (with a solution) - then this info will be gratefully received.

Two screenshots of each connection - apols for the black everywhere as had to sanitize the data.

Actions are from the bottom to the top.

This screenshot shows the error message (light blue is the reset and reconnect).

This screenshot shows the quick reset - light blue the reset and reconnect.

 

 

[tvotna]

Hmm... Check "show run | i crypto ikev2 cookie". The CLI is "crypto ikev2 cookie-challenge <value>". If is configured, remove it. By default ASA should not send cookie-challenge, unless it has 50% of max supported IKEv2 tunnels under negotiation. This is used to limit impact of DoS attacks.

[Stephen Carter]

Thanks for the reply, and I did find that information, but as normal it turned out to be something completely different which was 'generating' the error message. So the remote end (Draytek) had an option to put an 'ID' in the network field, and initially this was left blank, thus this may have been used as an 'identifier' so when the tunnel was reset it looked for this value, as no value was there the rekey when into a loop and then eventually connected. Once the host end WAN IP was added to this option the rekey and reconnection then happened in seconds.