Cisco IPSEC VPN - ISAKMP Connection-id

[jonathanaxford]

Hi Experts,

We have a site to site IPSEC VPN between a Cisco 1801 router and a fortigate 800F firewall.

The VPN works, but one quesiton i have is that the Isakmp Conn-id changes extremely frequently, and i just wanted to make sure i understood why.

When i run the show crypto isakmp sa command, i get the following:

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
1.2.3.4   5.6.7.8    QM_IDLE           2455 ACTIVE
1.2.3.4   5.6.7.8   MM_NO_STATE       2454 ACTIVE (deleted)

In the time it has taken me to write this, it has changed to:

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
1.2.3.4   5.6.7.8    QM_IDLE           2457 ACTIVE
1.2.3.4   5.6.7.8    MM_NO_STATE       2456 ACTIVE (deleted)
1.2.3.4   5.6.7.8    MM_NO_STATE       2455 ACTIVE (deleted)

So, to me it looks like the ISKAMP phase 1 is re-initiating its SA extremely frequently. I have set the ISAKMP policy as follows:

Global IKE policy
Protection suite of priority 10
        encryption algorithm:   Three key triple DES
        hash algorithm:         Message Digest 5
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #5 (1536 bit)
        lifetime:               86400 seconds, no volume limit

So, should this mean that the Phase 1 SA should only re-iniate after 86400 seconds?

Any information would be much appreciated,

Many thanks

Jonathan

[Jennifer Halim]

Yes, you are absolutely correct. The connectionID should stay for approximately 86400 seconds (24 hours) before the rekey and new connectionID.

You might want to run "debug cry isa" and check why it's reinitializing every second or two.

What version of IOS are you currently running?

[jonathanaxford]

Hi,

I am running C180X-ADVIPSERVICESK9-M), Version 12.4(22)T on the Cisco 1800.

The debugs show the following:

*Jul  2 12:48:06.372: ISAKMP (2645): incrementing error counter on sa, attempt 2 of 5: IKMP_BAD_DOI_NOTIFY

I found the following on a forum:

"The error %CRYPTO-6-IKMP_BAD_DOI_NOTIFY: DOI of 0 in notify message from  1.2.3.4 occurs when you have a vpn between a fortigate and a cisco  firewall. It has something to do with DPD packets from the fortigate.  The cisco replies on them but gives a warning that he isn't familiar  with a DOI of 0."

We are connecting to a Fortigate firewall, so I guess it could be possible that the DPD packets from the Fortigate are not being understood correctly and are causing the phase1 to re initiate? We also get the following:

(2645):deleting SA reason "Death by retransmission throw" state (R) QM_IDLE

I have attached the output of the debug, didn't want to put in the post as it makes it a bit messy,

Many thanks

Jonathan

[Jason Gervia · Accepted solution]

Hello,

It looks like you have DPD (crypto isakmp keepalives) configured on your router.  This determines the reachability of the other VPN endpoint, and the we're not understanding the acknowledgements to the 'R U THERE' packets  (due to the DOI issue) that we send them, so the ISAKMP process marks the tunnel as dead and tears them down.

Traffic over the tunnel then appears to bring the tunnels back up, and then DPD times them out again.

Look through your configuration for the 'keepalive' command, and if it's set for periodic, set the keepalives for 'on-demand' (which should be the default) so that we're only sending DPDs when we are unable to determine if the tunnel is alive because no traffic is coming over it.

This doc link is old, but it describes the feature pretty well:

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtdpmo.html

--Jason

[jonathanaxford]

Hi Jason,

That sounds spot on. I just checked the Fortigate box and that is set to use the DPD On-demand mode by default, whereas our Cisco box is currently set to use periodic mode.

I'll change the cisco to use on-demand and see what happens,

Many thanks

Jonathan

[jonathanaxford]

Hi,

That has worked a treat. The Cisco device is now running in DPD on-demand mode. The Fortigate also defaults to on-demand mode and we are no longer seeing the constant re initialisation of the Phase 1.

Many thanks for all your useful replies and information,

Jonathan