11-03-2009 07:52 AM - edited 02-21-2020 04:22 PM
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
11-03-2009 08:56 AM
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.
11-03-2009 09:17 AM
Thanks Patrick. I appreciate the input, but that didn't work for me. Any other ideas??
11-03-2009 02:40 PM
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.
Regards
Mike
11-03-2009 02:50 PM
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...
"CSCsy53387
crypto map does not hole match message pops up during conditon debug"
Regards
Mike
11-03-2009 06:15 PM
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.
11-04-2009 04:55 AM
Hi Mike,
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??
11-04-2009 05:13 AM
Hi,
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?
Regards
Mike
11-04-2009 05:26 AM
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?
11-04-2009 07:36 AM
OK here is my side of the config
access-list megacorp1 extended permit ip host 1.1.1.1 host 95.95.95.95
access-list megacorp2 extended permit ip host 1.1.1.1 host 96.96.96.96
access-list megacorp3 extended permit ip host 1.1.1.1 host 97.97.97.97
access-list megacorp4 extended permit ip host 1.1.1.1 host 98.98.98.98
access-list megacorp_vpn_nat extended permit ip host 10.1.7.36 host 95.95.95.95
access-list megacorp_vpn_nat extended permit ip host 10.1.7.36 host 96.96.96.96
access-list megacorp_vpn_nat extended permit ip host 10.1.7.36 host 97.97.97.97
access-list megacorp_vpn_nat extended permit ip host 10.1.7.36 host 98.98.98.98
access-list outside extended permit ip any host 10.10.10.10
static (inside,outside) 1.1.1.1 access-list megacorp_vpn_nat
crypto map megacorpmap 60 match address megacorp1
crypto map megacorpmap 60 set peer 95.95.95.95
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 96.96.96.96
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 97.97.97.97
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 98.98.98.98
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 201.201.201.201 type ipsec-l2l
tunnel-group 201.201.201.201 general-attributes
tunnel-group 201.201.201.201 ipsec-attributes
pre-shared-key *
tunnel-group 202.202.202.202 type ipsec-l2l
tunnel-group 202.202.202.202 general-attributes
tunnel-group 202.202.202.202 ipsec-attributes
pre-shared-key *
tunnel-group 203.203.203.203 type ipsec-l2l
tunnel-group 203.203.203.203 general-attributes
tunnel-group 203.203.203.203 ipsec-attributes
pre-shared-key *
tunnel-group 204.204.204.204 type ipsec-l2l
tunnel-group 204.204.204.204 general-attributes
tunnel-group 204.204.204.204 ipsec-attributes
pre-shared-key *
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 1800
crypto isakmp policy 20
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
10.10.10.10 is the host that is on our side of the protected network.
1.1.1.1 is the NAT address we are using for the protected host.
Thanks
11-05-2009 07:06 AM
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...
08-23-2012 11:30 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide