Core issue
The decrypting peer displays the HW_VPN-1-HPRXERR: Hardware VPN0/2: Packet Encryption/Decryption error, status=4612 error message when IP Security (IPSec) packets arrive out of order.
Resolution
This is caused by the bug CSCdt40220
Packets can be re-ordered at these three locations:
- The encrypting peer
- The network
- The decrypting peer
Note: The decrypting peer reorders packets very rarely. The only known scenario in which the decrypting peer reorders packets is when a packet is bumped to the process switch while the subsequent packets from the same tunnel are fast-switched or CEF-switched. This can occur for fragmented packets that need re-assembly.
These are some common scenarios in which out-of-order IPSec packets occur. These scenarios are considered normal behaviors:
- Fragmentation: The decrypting peer uses process switching on fragmented packets. To minimize the impact of this problem, enable Look-Ahead-Fragmentation.
- QoS: If the Quality of Service (QoS) scheduling mechanism is triggered after IPSec encryption, packets in the same IPSec Security Associations (SAs) can be transmitted out-of-order.
- Pak_priority: pak_priority is an internal flag that Cisco IOS Software sets to some of the router-generated packets that are considered critical. Critical packets include routing updates and interface keepalives. When the output interface queue is congested, the router honors the pak_priority flags to ensure the transmission of high priority packets first. So in the Generic Routing Encapsulation (GRE) over IPsec and dynamic routing protocol design, the Encapsulating Security Payload (ESP) packets can become out-of-order if the egress interface is congested and the router has to transmit encrypted routing updates first.
As a workaround, perform these steps:
Issue the
ip mtu command to set the Maximum Transmission Unit (MTU) size of inbound streams to less than 1400 bytes.
-
