On my ASA5520 I am trying to do a IPSEC tunnel between two sites. When I ping the protected network on the other side I get this when debugging IPSEC:
IPSEC(crypto_map_check): crypto map manmap 20 does not hole match for ACL man1
Not too sure what this means...
A little more information. This from a show crypto isakmp:
Global IKE Statistics
Active Tunnels: 0
Previous Tunnels: 0
In Octets: 216216
In Packets: 1189
In Drop Packets: 991
In Notifys: 0
In P2 Exchanges: 0
In P2 Exchange Invalids: 0
In P2 Exchange Rejects: 0
In P2 Sa Delete Requests: 0
Out Octets: 106032
Out Packets: 1235
Out Drop Packets: 0
Out Notifys: 991
Out P2 Exchanges: 0
Out P2 Exchange Invalids: 0
Out P2 Exchange Rejects: 0
Out P2 Sa Delete Requests: 0
Initiator Tunnels: 37
Initiator Fails: 37
Responder Fails: 97
System Capacity Fails: 0
Auth Fails: 96
Decrypt Fails: 0
Hash Valid Fails: 0
No Sa Fails: 990
I've seen this issue before, it's a known caveat to specific code versions. I would try the following:
Remove and re-apply your crypto map with a different sequence number
If that doesn't work, reboot the firewall.
Are you able to provide configs for both sides (minus any sensitive information) as well as the output of "show crypto isakmp sa" and "show crypto ipsec sa". It may be something obvious in the configuration that we can spot.
Further to this you have not actually said if there is anything not working at all... if it is working it could be cosmetic. As mentioned in the last post there is a known caveat with this error but not sure what the details of it are...
crypto map does not hole match message pops up during conditon debug"
I've seen this issue numerous times, every time the issue prevents the tunnel from establishing. If re-applying the crypto with a different sequence number did not work, a reboot is the only other solution I've found.
I cant post the config for the other side since it is another company.
This seems to be a caveat for version 8.2 and I am running 8.0(4)28.
Does that matter??
I couldn't say. The table the caveat is listed under is "Table 5 Open Caveats from Previous Releases " so it may still be affecting your release. However as I mentioned I do not know the details of the bug and what the problem is, though a patrick has said he has seen it. You still have not actually said if it is causing an issue with the VPN?
CSCsy53387 also affects 8.0 and is fixed in 8.0(5) (just released).
It is not clear though whether this bug is causing the debug message in your case.
Do you only see it with conditional debugging enabled?
And like the other posters suggested, can you post your side of the config, and confirm whether or not it is affecting traffic?
OK here is my side of the config
access-list megacorp1 extended permit ip host 184.108.40.206 host 220.127.116.11
access-list megacorp2 extended permit ip host 18.104.22.168 host 22.214.171.124
access-list megacorp3 extended permit ip host 126.96.36.199 host 188.8.131.52
access-list megacorp4 extended permit ip host 184.108.40.206 host 220.127.116.11
access-list megacorp_vpn_nat extended permit ip host 10.1.7.36 host 18.104.22.168
access-list megacorp_vpn_nat extended permit ip host 10.1.7.36 host 22.214.171.124
access-list megacorp_vpn_nat extended permit ip host 10.1.7.36 host 126.96.36.199
access-list megacorp_vpn_nat extended permit ip host 10.1.7.36 host 188.8.131.52
access-list outside extended permit ip any host 10.10.10.10
static (inside,outside) 184.108.40.206 access-list megacorp_vpn_nat
crypto map megacorpmap 60 match address megacorp1
crypto map megacorpmap 60 set peer 220.127.116.11
crypto map megacorpmap 60 set transform-set megacorpset
crypto map megacorpmap 60 set security-association lifetime seconds 28800
crypto map megacorpmap 61 match address megacorp2
crypto map megacorpmap 61 set peer 18.104.22.168
crypto map megacorpmap 61 set transform-set megacorpset
crypto map megacorpmap 61 set security-association lifetime seconds 28800
crypto map megacorpmap 62 match address megacorp3
crypto map megacorpmap 62 set peer 22.214.171.124
crypto map megacorpmap 62 set transform-set megacorpset
crypto map megacorpmap 62 set security-association lifetime seconds 28800
crypto map megacorpmap 63 match address megacorp4
crypto map megacorpmap 63 set peer 126.96.36.199
crypto map megacorpmap 63 set transform-set megacorpset
crypto map megacorpmap 63 set security-association lifetime seconds 28800
crypto map megacorpmap interface outside
tunnel-group 188.8.131.52 type ipsec-l2l
tunnel-group 184.108.40.206 general-attributes
tunnel-group 220.127.116.11 ipsec-attributes
tunnel-group 18.104.22.168 type ipsec-l2l
tunnel-group 22.214.171.124 general-attributes
tunnel-group 126.96.36.199 ipsec-attributes
tunnel-group 188.8.131.52 type ipsec-l2l
tunnel-group 184.108.40.206 general-attributes
tunnel-group 220.127.116.11 ipsec-attributes
tunnel-group 18.104.22.168 type ipsec-l2l
tunnel-group 22.214.171.124 general-attributes
tunnel-group 126.96.36.199 ipsec-attributes
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 10
crypto isakmp policy 20
10.10.10.10 is the host that is on our side of the protected network.
188.8.131.52 is the NAT address we are using for the protected host.
OK this is working now. There were three problems. The edge router was blocking incoming ESP. That was opened up.
The second problem was the default group for the tunnel group was not set for IPSec
And the third problem was the crypto maps statements had bad addresses from the other side of the tunnel.
So any one of these would have prevented the tunnel from coming up. But we got it to work in the end. Thanks for the help...
I'm seeing this in "debug crypto ipsec" too. The version of code I'm running is 7.2.(5) GD. It doesn't mentioned 7.2.x in bug ID CSCsy53387. Can this be associated with the bug? I have confirmed both sides match for their ACLs. It sounds like it is in this bug just want to confirm with someone what version we should upgrade to avoid it. Its more annoying, not causing any issues though.