Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1721
Views
0
Helpful
2
Replies

GETVPN GM stops forwarding traffic with CRYPTO-4-RECVD_PKT_NOT_IPSEC after rekey, but it's in inbound-only mode

sganpat
Level 1
Level 1

‎11-04-2014 12:56 PM - edited ‎02-21-2020 07:54 PM

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

 

1 person had this problem
Labels:
0 Helpful
2 Replies 2

vishaw jasrotia
Level 1
Level 1

‎11-13-2014 02:41 AM

Hello

 

As per my obervation , when we are using sa receive only then IPsec polices will applied for inbound traffic. So in your case when the traffic is comming from one , it comes out as plane text traffic because the group member installs this IPsec SA only in the inbound direction. So when this traffic reach at other end where the router is expecting the encrypted traffic  in bound direction , Router drops the traffic and u start getting error msg.

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

 

Thanks

Vishaw

0 Helpful

sganpat
Level 1
Level 1
In response to vishaw jasrotia

‎12-14-2015 02:11 AM

Sorry I took so long to answer this.

The SA Receive_Only allows traffic to be received either in encrypted or in plain text. It is used when rolling out GET VPN when all the routers have not been converted to group members. So you have misunderstood what the command does.

I ended up opening a case with Cisco TAC and they couldn't figure out what was happening.

What I eventually did was create a loopback address and have the GDOI configuration register with that address.

!
interface Loopback0
 ip address 10.1.1.10 255.255.255.255
!
crypto map gdoimap local-address Loopback0
!

My theory is that because I had two WAN links, both were trying to register with the key server, but one was failing because the KS would see it as a duplicate registration. This may have been causing some problems with the GM.

Once I used that command, everything worked fine.

0 Helpful
Customers Also Viewed These Support Documents