cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3676
Views
9
Helpful
15
Replies

GETVPN Question

Hello community,

We are using GETVPN in our environment and I have the following problem. At first we had configured "crypto map map_getvpn local-address Loopback0" and this loopback0 IP address was configured on our key servers. We then decided to use loopback1 for the crypto map ip_address, so this was configured on the KS while removing the old Loopback0.

The weird thing is that on the two routers where we made the change, when issuing "show crypto isakmp sa" we get the following:

#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst                  src                  state               conn-id      status
loopback_0     KS             GDOI_REKEY       13042      ACTIVE
KS             loopback_1     GDOI_IDLE            1018       ACTIVE

and log messages:

Apr 25 03:05:43 EET2: %GDOI-5-GM_RECV_REKEY: Received Rekey for group group_getvpn from KS to loopback1 with seq # 44
Apr 25 03:05:49 EET2: %GDOI-3-GDOI_REKEY_SEQ_FAILURE: Failed to process rekey seq # 44 in seq payload for group group_getvpn, last seq # 44
Apr 25 03:05:49 EET2: %GDOI-3-GDOI_REKEY_FAILURE: Processing of REKEY payloads failed on GM loopback1 in the group group_getvpn, with peer at KS
Apr 25 03:05:49 EET2: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of GDOI mode failed with peer at KS

When comparing with other getvpn GM I see that they all have:

#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst                  src             state             conn-id      status
loopback        KS       GDOI_REKEY       13147    ACTIVE
loopback        KS       GDOI_REKEY       13148    ACTIVE

Encryption seems to work fine for all routers, but I don't know how to interpret the messages and the show command output of the routers where the change was made.The rekey should be done with Loopback_1!!!!

Any help and insight will be highly appreciated.

15 Replies 15

A case was opened and it seems that the problem we were facing was because the GMs couldn't get deleted from the KS. As theory states, in order for a GM to be considered dead 3 unsuccessful rekeyings must occur. TAC proposed to shut lo0, but since this is used for specific purposes that was not an option. Our councling partner proposed to create an access-list that denies lo0 - KS isakmp messages (udp 848). This actually worked.

Bellow I attach a sample config for those who may someday need it!

access-list 199 deny   udp host ip_address eq 848 any
access-list 199 deny   udp any eq 848 host ip_address
access-list 199 permit ip any any

This was applied inbound on the interface from which the router learnt about the KS.

Thank you all for your assistance and ideas.

Katerina