Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

GDOI IPsec SA Failures

Need help understanding IPSEC Packet errors running in a GDOI environment.

Everything runs fine for hours (random # of hours) and then we receive the following errors;

(ip) vrf/dest_addr= /1.1.1.1, src_addr= 2.2.2.2, prot= 50 Dec 21 05:34:09 EST: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC pa

cket.

Each time this happened, it took a CLEAR CRYPTO GDOI to get traffic going again.

It doesn't appear to be anything related to Rekeying and it's confusing because the Prot reported in the message is 50 (ESP) - so it appears that traffic is still being sent encrypted.

We are using VPN Hardware accelaration ( AIM-VPN/SSL-3) and I don't see any errors there.

I'm not certain where to look next - any help out there?

5 REPLIES
Silver

Re: GDOI IPsec SA Failures

Message conveys that unencrypted packets are recieved. This happens mostly due to mismatched crypto access list . Make sure crypto access list is same on both the ends. Avoid usage of any any statement in the access list. Also ensure that Make sure that the same access list is not applied to many crypto map entries.

New Member

Re: GDOI IPsec SA Failures

What we found is that the return reply, from what appears to be because of Netflow payload being fragmented, is the cause of the IPSEC error.

If we open the "do not encrypt" acl to include not just the initial UDP + Port for the NetFlow send, but also include all IP, we are able to get Netflow traffic across and eliminate the IPSEC error.

Although this is working, it is not ideal.

Are there any options to avoid Netflow payload fragmentation?

Initially, MTU size had to be set to 1400 for GETVPN traffic to flow successfully in both directions. This looks to be impacting Netflow.

Thanks.

New Member

Re: GDOI IPsec SA Failures

How about you leave your MTU on the interface at 1500 and apply tcp adjust 1360 to the physical interfaces. That should account for a majority of your transit traffic with large packets since they usually are TCP based and also allow the Netflow to flow unfragmented.

New Member

Re: GDOI IPsec SA Failures

Keith,

Unfortunately there aren't any options to avoid NetFlow fragmentation, since NetFlow tries to stuff as much data as it can into each export packet.

GDOI IPsec SA Failures

Hi All,

I was having the same issue with my Lab topology (on KS and two members).

I got the same error when i sent a ping accros one of the members to the KS. Most guides skipped that member to KS traffic is not in the scope of GDOI so the KS doesn't have a ipsec tunnel in place.

Spoke to Spoke traffic was successfully getting across and with encryption/decryption. Hope this helps.

799
Views
0
Helpful
5
Replies
CreatePlease to create content