In a VPN of eight PIXen (501 and 515E), fully meshed with IPSec tunnels, one of the nodes has been upgraded to an ASA 5510 to increase performance. I have migrated the config according to the book, and everything is running fine, but the new ASA is spamming my central log server with messages like this:
%ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0xxxxxxxxx, sequence number=
0xxxxx) from (user= ) to . The decapsulated inner packet doesn't match the negotiated policy in the SA. The packet specifies its destination as , its source as , and its protocol as 1. The SA specifies its local proxy as //0/0 and its remote_proxy as //0/0.where is either
- an IP address which doesn't match any access-list entry in the sending PIX' config and therefore shouldn't have been encapsulated in the first place, or
- an IP address which does match one of several access-list entries for the crypto map on the receiving ASA, but the log message lists a different, non-matching entry of the same access-list.
Example for the second case because I'm not sure my description is very clear:
%ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0xAB0323B4, sequence number=
0x127) from (user= ) to . The decapsulated inner packet doesn't match the negotiated policy in the SA. The packet specifies its destination as 192.168.1.101, its source as 10.111.1.2, and its protocol as 1. The SA specifies its local proxy as 192.168.1.0/255.255.255.0/0/0 and its remote_proxy as 10.0.0.0/255.255.0.0/0/0.where the relevant access-list is:
access-list pixtoasa extended permit ip 192.168.1.0 255.255.255.0 10.111.1.0
255.255.255.0 access-list pixtoasa extended permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.255.0.0 access-list pixtoasa extended permit ip host 10.0.0.0 255.255.0.0 access-list pixtoasa extended permit ip 192.168.246.0 255.255.255.0 10.111.1.0 255.255.255.0 crypto map vpnmap 40 match address pixtoasaWhat might cause this and, more importantly, how can I get rid of it, short of saying "no logging message 402116"?
aTdHvAaNnKcSe Tilman