I am implementing GET VPN. I have set my KSs to receive-only mode, so all my GMs are in inbound-only mode. I did this because I want to see if there are problems with registration, I expect that if there are problems it will not affect production traffic.
However, I've encountered an issue where after a rekey, a router will stop forwarding traffic that matches the encryption policy with the error: %CRYPTO-4-RECVD_PKT_NOT_IPSEC
However, the routers are not doing encryption, and they should be accepting unencrypted data either way.
Here are some of the logs:
.Nov 4 08:41:21.053 AST: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GDOI-GROUP1 from 10.0.0.2 to 192.168.248.68 with seq # 19
.Nov 4 08:41:21.169 AST: %GDOI-3-GDOI_REKEY_SEQ_FAILURE: Failed to process rekey seq # 19 in seq payload for group GDOI-GROUP1, last seq # 19
.Nov 4 08:41:21.169 AST: %GDOI-3-GDOI_REKEY_FAILURE: Processing of REKEY payloads failed on GM 192.168.248.68 in the group GDOI-GROUP1, with peer at 10.0.0.2
.Nov 4 08:41:21.169 AST: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of GDOI mode failed with peer at 10.0.0.2
.Nov 4 08:41:31.289 AST: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GDOI-GROUP1 from 10.0.0.2 to 192.168.252.102 with seq # 20
.Nov 4 08:41:41.349 AST: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GDOI-GROUP1 from 10.0.0.2 to 192.168.249.4 with seq # 21
.Nov 4 10:28:56.135 AST: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GDOI-GROUP1 from 10.0.0.2 to 192.168.248.68 with seq # 22
.Nov 4 10:28:56.259 AST: %GDOI-3-GDOI_REKEY_SEQ_FAILURE: Failed to process rekey seq # 22 in seq payload for group GDOI-GROUP1, last seq # 22
.Nov 4 10:28:56.259 AST: %GDOI-3-GDOI_REKEY_FAILURE: Processing of REKEY payloads failed on GM 192.168.248.68 in the group GDOI-GROUP1, with peer at 10.0.0.2
.Nov 4 10:28:56.259 AST: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of GDOI mode failed with peer at 10.0.0.2
.Nov 4 10:29:06.367 AST: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GDOI-GROUP1 from 10.0.0.2 to 192.168.252.102 with seq # 23
.Nov 4 10:29:16.443 AST: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GDOI-GROUP1 from 10.0.0.2 to 192.168.249.4 with seq # 24
.Nov 4 12:16:31.209 AST: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GDOI-GROUP1 from 10.0.0.2 to 192.168.248.68 with seq # 25
.Nov 4 12:16:31.357 AST: %GDOI-3-GDOI_REKEY_SEQ_FAILURE: Failed to process rekey seq # 25 in seq payload for group GDOI-GROUP1, last seq # 25
.Nov 4 12:16:31.361 AST: %GDOI-3-GDOI_REKEY_FAILURE: Processing of REKEY payloads failed on GM 192.168.248.68 in the group GDOI-GROUP1, with peer at 10.0.0.2
.Nov 4 12:16:31.361 AST: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of GDOI mode failed with peer at 10.0.0.2
.Nov 4 12:16:41.437 AST: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GDOI-GROUP1 from 10.0.0.2 to 192.168.252.102 with seq # 26
.Nov 4 12:28:56.546 AST: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /192.168.18.50, src_addr= 10.128.3.13, prot= 6
.Nov 4 12:29:56.583 AST: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /192.168.17.54, src_addr= 10.128.6.72, prot= 6
.Nov 4 12:30:56.647 AST: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /192.168.6.71, src_addr= 10.128.6.72, prot= 6
.Nov 4 12:31:57.320 AST: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /192.168.16.56, src_addr= 181.188.0.59, prot= 6
.Nov 4 12:32:57.525 AST: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /192.168.17.48, src_addr= 10.128.6.72, prot= 6
.Nov 4 12:33:57.714 AST: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /192.168.32.49, src_addr= 10.128.6.72, prot= 6
.Nov 4 12:34:57.758 AST: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /192.168.17.46, src_addr= 10.128.3.20, prot= 6
Notice how the rekeys at 8 and 10 am happens (including the failure) and there is no issue, but somehow at 12 it poses a problem.
Here is the relevant config of my KS:
!
crypto isakmp policy 1
encr aes 256
authentication pre-share
group 2
crypto isakmp key ******** address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set gettransform esp-aes esp-sha-hmac
!
crypto ipsec profile MYPROFILE
set security-association lifetime seconds 7200
set transform-set gettransform
!
crypto gdoi group GDOI-GROUP1
identity number 100
server local
rekey algorithm aes 256
rekey retransmit 10 number 2
rekey authentication mypubkey rsa REKEYRSA
rekey transport unicast
sa receive-only
sa ipsec 1
profile MYPROFILE
match address ipv4 getvpn-acl
replay time window-size 5
address ipv4 10.0.0.2
redundancy
local priority 200
peer address ipv4 10.0.0.3
!
ip access-list extended getvpn-acl
deny udp any eq 848 any eq 848
deny esp any any
deny tcp any any eq 22
deny tcp any eq 22 any
deny udp any any eq 1645
deny udp any any eq 1646
deny udp any any eq 1812
deny udp any any eq 1813
deny tcp any eq 443 any
deny tcp any any eq 443
deny eigrp any any
deny udp any any eq ntp
deny udp any eq ntp any
deny udp any any eq snmp
deny udp any eq snmp any
deny udp any any eq snmptrap
deny udp any eq snmptrap any
deny udp any any eq syslog
deny udp any eq syslog any
permit ip any any
!
Here is the config of the GM:
!
crypto isakmp policy 1
encr aes 256
authentication pre-share
group 2
lifetime 300
crypto isakmp key ******** address 0.0.0.0 0.0.0.0
!
!
crypto gdoi group GDOI-GROUP1
identity number 100
server address ipv4 10.0.0.2
server address ipv4 10.0.0.3
!
!
crypto map gdoimap 1 gdoi
set group GDOI-GROUP1
!
!
interface FastEthernet0/1
description Connected to WAN 1
crypto map gdoimap
interface FastEthernet0/0/0
description Connected to WAN 2
crypto map gdoimap
!
I've looked to see if there are any bugs, but I can't find any.
The version of the KS and the GM is 12.4(24)T5.
*all IPs are sanitised for your protection
