Gdoi rekey sequence failure

[katerina.dardoufa]

Dear community,

I am not very familiar with isakmp, ipsec etc, but I have the following problem. My company has recently deployed GETVPN and we seem to encounter the following issue (it does not create -yet- a business impact, I mainly want to understand why it happens and what I can do to prevent it).

On some (not all of the routers) I get messages of the form:

Jan 19 14:40:20 EET: %GDOI-5-GM_RECV_REKEY: Received Rekey for group group_getvpn from 10.130.201.11 to 10.255.197.122 with seq # 4
Jan 19 14:40:21 EET: %GDOI-3-GDOI_REKEY_SEQ_FAILURE: Failed to process rekey seq # 4 in seq payload for group group_getvpn, last seq # 4
Jan 19 14:40:21 EET: %GDOI-3-GDOI_REKEY_FAILURE: Processing of REKEY payloads failed on GM 10.255.197.122 in the group group_getvpn, with peer at 10.130.201.11
Jan 19 14:40:21 EET: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of GDOI mode failed with peer at 10.130.201.11

I also see that the device has 3 isakmp peers, when it should have just 1!!!

sh crypto isakmp peers
Peer: 10.130.201.11 Port: 848 Local: 10.255.197.122
Phase1 id: 10.130.201.11
Peer: 10.150.201.14 Port: 848 Local: 10.255.197.122
Phase1 id: 10.150.201.14
Peer: 10.150.201.14 Port: 848 Local: 192.168.20.53
Phase1 id: 10.150.201.14

To clarify things, the interface with ip 10.255.197.122 is the only one with crypto map configured. On interface with IP 192.168.20.53 I have removed the crypto map, but all the KS have a preshared key for both 10.255.197.122 and 192.168.20.53 (on some situations I have removed the 192.168.x.x entry from the KS, but the behaviour remains the same).

crypto isakmp key preshared_key address 192.168.20.53

crypto isakmp key preshared_key address 10.255.197.122

I have the suspicion that I get the failure messages due to the 3 different peers ( I also noticed that on routers with no problems I have one isakmp peer and no failure messages). How can I "remove" the excess peers???  How can I be sure that the rekeying is done correctly? I suppose that if the rekeying failed completely I would loose connectivity with the routers!

Any input would be highly appreciated!

Thank you in advance,

Katerina

[wzhang]

Hi,

Is it possible that you are running different IOS versions on these Group Members? We implemented a control plane replay protection mechanism last year, which caused some backward compatibility issues, one of which is sequence check failure for KEK rekeys. Take a look at this for details:

http://www.cisco.com/en/US/partner/docs/ios/sec_secure_connectivity/configuration/guide/sec_encrypt_trns_vpn_ps10591_TSD_Products_Configuration_Guide_Chapter.html#wp1049430

So the GM in question is running one of these newer versions of IOS, then that could be the reason for the error message. As far as the different peer issue, it's hard to say without looking at the complete GM/KS config and isakmp/gdoi debugs.

Hope this helps,

Wen

[katerina.dardoufa]

Hello Wen and thank you for your reply!

All our KS and GMs are running c2801-adventerprisek9-mz.124-24.T3.bin. I will have a look at the isakmp/gdoi debugs and the link you provided and try to figure what the problem is.

Thanks,

Katerina

[wzhang]

Hi, Katerina:

If your are running 12.4(24)T3, then it should support the control plane replay check. Basically, the error messages is telling you that the sequence number in the rekey messages is something we have received already (sequence # =4), thus it's treated as a replayed rekey packet and therefore dropped. I would recommend you open a TAC case to have it looked at as troubleshooting this sort of problems may get fairly involved.

Hope this helps,

Wen