cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4762
Views
0
Helpful
11
Replies

Strange Error on Site to Site IPsec Tunnel

Pete89
Level 2
Level 2

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 Replies 11

Patrick0711
Level 3
Level 3

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.

Thanks Patrick. I appreciate the input, but that didn't work for me. Any other ideas??

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

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

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.

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??

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

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 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

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...

johng231
Level 3
Level 3

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: