GDOI IPsec SA Failures

[kst.amand]

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?

[irisrios]

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.

[kst.amand]

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.

[gjstem]

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.

[paitken]

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.

[Malik Osman Rasheed]

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.