VPN L to L tunnel errors

[forman102]

Hello,

I ran into an issue with one of my VPN L to L tunnels on ASA 5510. This tunnel was build for vendor company and their support reported that the tunnel drops sometimes. I looked into ASA log files and found the following errors:

2010-11-03 09:07:50    Local4.Error    x.x.x.x    :Nov 03 09:07:50 EDT: %ASA-vpn-3-713061: Group = 68.x.x.x, IP = 68.x.x.x, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 4.2.2.1/255.255.255.255/0/0 local proxy 192.168.20.0/255.255.255.248/0/0 on interface outside
2010-11-03 09:07:50    Local4.Error    x.x.x.x    :Nov 03 09:07:50 EDT: %ASA-vpn-3-713902: Group = 68.x.x.x, IP = 68.x.x.x, QM FSM error (P2 struct &0xad763d50, mess id 0xe382746a)!
2010-11-03 09:07:50    Local4.Error    x.x.x.x    :Nov 03 09:07:50 EDT: %ASA-vpn-3-713902: Group = 68.x.x.x, IP = 68.x.x.x, Removing peer from correlator table failed, no match!

I had to NAT 2 servers on my side to get this tunnel to work. Here's my config:

NAT:

access-list policy_NAT_C1 extended permit ip host 10.1.1.1 host  4.2.2.1
access-list policy_NAT_C2 extended permit ip host 10.1.26.1 host 4.2.2.1

static (inside,outside) 192.168.20.2  access-list policy_NAT_C1
static (inside,outside) 192.168.20.3  access-list policy_NAT_C2

Crypto Map ACL:

access-list outside_C_cryptomap extended permit ip host 192.168.20.2 host 4.2.2.1
access-list outside_C_cryptomap extended permit ip host 192.168.20.3 host 4.2.2.1

crypto map M 8 match address outside_C_cryptomap
crypto map M 8 set peer 68.x.x.x
crypto map M 8 set transform-set C
crypto map M 8 set security-association lifetime seconds 28800
crypto map M 8 set security-association lifetime kilobytes 4608000c

How could I troubleshoot this?

thank you

forman

[Federico Coto Fajardo]

Here's the explanation for the error:

1. %ASA-3-713061: Tunnel rejected: Crypto Map Policy not found for Src:source_address, Dst: dest_address!

The adaptive security appliance was not able to find security policy information for the private networks or hosts indicated in the message. These networks or hosts were sent by the initiator and do not match any crypto ACLs at the adaptive security appliance. This is most likely a misconfiguration.

Recommended Action: Check the protected network configuration in the crypto ACLs on both sides and make sure that the local net on the initiator is the remote net on the responder and vice-versa. Pay special attention to wildcard masks, and host addresses versus network addresses. Non-Cisco implementations may have the private addresses labeled as proxy addresses or red networks.

Don't you have other IPsec peers that might be conflicting with the interesting traffic?

Federico.

[Yudong Wu]

On your side, you only permit two host addresses 192.168.20.2 and 192.168.20.3. But the remote side has a subnet 192.168.20.0/255.255.255.248.

You'd better to make them as a mirror.

Tunnel might come up when it is initiated from your site. But it could not if it is initiated from the remote.

[forman102]

Yudong,

This tunnel was originally configured on VPN concetrator, using subnet of 192.168.20.0/255.255.255.248. Once it was moved to ASA, I limited it to 192.168.20.2 and 192.168.20.3 only. I've just verified with vendor's network tech that ACL on his side matches mine. Not sure how the firewall got this:

local proxy 192.168.20.0/255.255.255.248/0/0 on interface outside   

Any other thoughts?

thanks

[Yudong Wu · Accepted solution]

I think the issue might be on the other side since it was the remote side to ask for setup the tunnel for 192.168.20.0/255.255.255.248.

What kind of device is at the other side?

If it is Cisco device, could he provide the config and debug output of "deb cry isa" and "deb cry ipsec" during the time when the issue happens?

[forman102]

You are right. Thank you for your help. On vendor's PIX there was config mismatch in memory, so it was requesting wrong subnet (actually this was the one used with "old" tunnel). Vendor's tech cleared isakmp sa and it all is well now. Again new configuration was done fine, but still there was something in memory (speculation), which was causing problem.