VPN between two 1841s, logs lots of CRYPTO-4-RECVD_PKT_MSG_LEN_ERR: decapsulate: packet has bad bad ...

jantkowiak2 · ‎05-09-2010

Hi,

I have two 1841's with a vpn between them

One 1841 has a lot of other misc vpns terminated there, and they all work fine. The other 1841, has only this one vpn.

Packets over 300 bytes are getting dropped or something is happening (proven by pings -- just under 300 bytes works fine)

In the logs though (on both 1841s) I'm getting messages like:

May 9 18:46:28.183 EDT: %CRYPTO-4-RECVD_PKT_MSG_LEN_ERR: decapsulate: packet has bad bad pad length for packet: decrypt error? length destadr=<removed>, prot=50, len=14
May 9 18:46:28.183 EDT: %CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: mac verify failed for connection id=3003 local=<removed> remote=<removed> spi=D63B2179 seqno=00005100

route cache is turned off on both sides.

Any ideas??

Cisco IOS Software, 1841 Software (C1841-ADVSECURITYK9-M), Version 12.4(25b), RELEASE SOFTWARE (fc1)

Jennifer Halim · ‎05-09-2010

Potentially could be problem with the onboard crypto accelerator card. Try to disable the hardware encryption, and check if you still get the error messages.

To disable it: no crypto engine accelerator

If after disabling it, you don't get anymore errors, then reenable it and check.

Hope that helps.

jantkowiak2 · ‎05-09-2010

Just tried that, on both 1841s...no luck =(

Jennifer Halim · ‎05-09-2010

Pls open a TAC case to get it further investigated.

Federico Coto Fajardo · ‎05-09-2010

Joe,

I assume that you have applications suffering through the VPN tunnel?

The fact that packets over 300 bytes are not passing on the PING tests are just actual tests, but you have applications generating errors or not working properly through the tunnel?

If this is the case, what kind of applications?

Do you get the same behavior that you're seeing with traffic other than ICMP? (TCP/UDP)?

Federico.

jantkowiak2 · ‎05-09-2010

Yep, several applications reporting nonspecific "network" errors/timeouts, including SQL, SSH, vmware management.....

jantkowiak2 · ‎05-09-2010

Yeah, that's the next step, once we get the contract situation straightened out (TAC says it is on another company's contract)

Any other suggestions? Could it be memory related? Is there any way I can test the memory or move what part of the memory is used for packet buffers?

Jennifer Halim · ‎05-09-2010

No, don't think it's memory related.

It seems to be MTU related. What is the MTU settings on each interfaces?

jantkowiak2 · ‎05-09-2010

MTU is left at default, 1500. Only one interface in use, as a vlan trunk. pre-encryption fragmentation, no df-bit settings

The other site (the other end of the VPN) is the exact same setup -- Cisco 1841 handling VPN, juniper firewall, but the other site has several VPNs and no issues...

After I reboot the router, things start to work for a little while, but after about 5-10 minutes all the same issues creep up again.

jantkowiak2 · ‎05-10-2010

While waiting to get the smartnet situation straightened out, I tried using a GRE tunnel instead, with checksumming enabled...

And everything works! But now my fa0/0 is racking up hundreds of CRC errors

Doesn't IPsec do checksumming? Why does GRE catch this and not IPsec?

VPN between two 1841s, logs lots of CRYPTO-4-RECVD_PKT_MSG_LEN_ERR: decapsulate: packet has bad bad pad length for packet: decrypt error? length destadr=