IKEv1/IKEv2 Route Based IPSec VPN flap during rekey

[Jay47110]

Hi,

So, we have a VPN hosting ASR1001 running on IOS 15.5(3)S10. We have been experiencing flaps on several IKEv1 and 2 Route based (VTI Tunnel Protection) IPSec VPN during the hourly IPSec rekey. I'm not sure when it started and haven't been able to find any bugs related to this issue in the IOS 15.5(3)S10.

There are several articles online about how to fix such rekey flaps in a Cisco ASA using command "sysopt connection preserve-vpn-flows" which retain the state table information at the re-negotiation of the VPN tunnel. But since we are working on an IOS router and not on a stateful firewall, I haven't been able to find any solution for this issue on the Cisco ASR1001.

So far we have tried

1: keeping the VPN constantly active by sending traffic over it as the thought was that perhaps it is the inactivity that is causing the flaps. That didn't help.

2: Making 1 end a responder only, didn't help either.

Is there any suggestions or fixes for this? The issue is occuring on both IKEv1 and 2 Route Based VPNs (VTI).

Kind regards

[parviz]

Hi,

1. Check ikev2 sa lifetime under ikev2 profile configuration on both sides. default is 24 hour if not configured, if yes the value must be the same on both sides.

2. Check lifetime under crypto-map or ipsec profile configuration. both sides must be the same.

3. DPD is disabled by default in Cisco routers if enabled under ikev2 profile, both sides must be same.

4. Check local and remote keys on both sides, config looks like this:

crypto ikev2 keyring yourkeyring

   peer endpeer

      address x.x.x.x

      pre-shared-key local ikev2key

      pre-shared-key remote ikev2key or (different from local key)

crypto ikev2 profile yourprofile

 authentication local pre-share

 authentication remote pre-share

 keyring local yourkeyring (crypto ikev2 keyring yourkeyring)

If all this okay on both sides, browse the config from both side.

waiting for your reply.

[Jay47110]

Thanks Parviz for the reply.
I have just updated the query to include both IKEv1 and v2, as the issue is occurring in both versions but only on VTI IPSec profile VPNs.
All the lifetimes you mentioned to check are set to default on the Cisco ASR. I will confirm with the remote end about the lifetimes. However, as far as I understand, lifetimes are negotiable i.e. the shorter lifetime value between the 2 peers is chosen during VPN negotiation so although a good practice, do not have to match.
PSK is of course matching between the peers otherwise the VPN won't negotiate in the 1st place.

I think this is somehow related to the IPSec Profile or the VTI as only the VTI VPNs are flapping upon Phase2 rekey every hour.

[parviz]

Have you checked ipsec transform-set configurations?

[parviz]

and one more question, what type vti are you using? svti or dvti?

[Jay47110]

Hi Parviz,

Its a Static VTI and the transform set is using Tunnel mode.

[parviz]

Hi Jay,

I have tried to built in my lab environment the situation you described with different ways but no rekey flap occured. Only way to resolve this issue is to analyze both side config and debugging.

As you mentioned rekey flap occurs every hour in phase two. In ikev2 lifetime of ikev2 sa and ipsec sa is not negotiated. whereas in ikev1 the ikev1 sa is negotiated. The ipsec sa under crypto map or ipsec profile config default is 1 hour.

[Cristian Matei]

Hi,

    1. The first thing i would do is to disable the KB lifetime for Phase2, and make use of the time-based lifetime; i would do this on both sides, using the same non-default values (so try not using the default of 1 hour), even though it does not have to match.

crypto ipsec profile TEST

 set security-association lifetime kilobytes disable

 set security-association lifetime seconds 7200

    2. If it's not fixed, i would upgrade both VPN gateway to a recommended (gold star) version.

The rekeying of Phase2 takes place some good seconds (around 30 or so), before the keys actually expire; so as the rekeying takes place, you still use the old SA's, which are about ti expire; upon successful rekeying, the old SA's are deleted and the new ones are used. 

SVTI is a VPN technology which is self-triggered, the tunnel negotiation and renegotiation, so you should have no downtime once it's up and running.

Regards,

Cristian Matei. 

[Jay47110]

Hi Cristian,
Thanks for the reply. I will amend the config based on your mention of lifetime.
And I agree with your rekey process description. The old SA should stay up and pass data until the key is renegotiated and a new SA is formed but seems like the old immediately expires causing 30 sec negotiation downtime.
I will update once the changes are made.
Thanks

[gavin8790]

Did this command "set security-association lifetime kilobytes disable" resolve your issue?