Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Should I report a bug with this problem? *URGENT*

I have a l2l tunnel with a vendor that has access to only our 192.x.x.x subnets. They terminate into an ASA 5520 along with remote clients that vpn into the network with Cisco's VPN client.


The l2l tunnel that I had set up had a crypto acl allowing and through the tunnel.

The vendor had NINE networks listed and could see ALL of them. When I had them hit the router, the counter would increment. They could hit a subnet, and the ipsec sa said that it was hitting the dynamic map.

The dynamic map applied is used for the remote users, but the l2l tunnel was "leaking" information over to it when it didn't match the crypto acl.

The l2l tunnel is set up with SHA encryption and the dynamic map was using SHA or MD5.


To "fix" the problem, more of a workaround, I disabled the remote vpn users from using SHA and only use MD5 for the transform set.

My question is why is the ASA allowing the tunnel information to "leak" into another map if it's not allowed? These are, of course, different sequence numbers, and it really doesn't make any sense to me.

Should I report this as a security bug, hole, glitch, and if so, how do I do it? Cisco TAC said that this is the way it should work, but I see a MAJOR security flaw with this. It's allowing a peer to access networks that it doesn't have access to.



HTH, John *** Please rate all useful posts ***

Re: Should I report a bug with this problem? *URGENT*

That is why Cisco always recommend to make sure that the crypto acls and configurations are mirrored so that the correct traffic stays on the correct tunnel, this indeed is expected behavior, when the tunnel does not have a specific match for a static tunnel it will be landing on the dynamic crypto map (if any with proper settings) and this will only happen when the tunnel is initiated from the remote headend. This is the way it is designed. So I would rather have your configuration corrected in order to have the right ACL definition for both ends, then if after the best practices an supported configuration you see this behavior you then can report a problem.