cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
187
Views
0
Helpful
1
Replies

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

John Blakley
VIP Alumni
VIP Alumni

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.

Problem:

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

The vendor had NINE networks listed and could see ALL of them. When I had them hit the 192.168.1.0 router, the counter would increment. They could hit a 192.168.4.0 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.

Solution:

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.

Thanks,

John

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

Ivan Martinon
Level 7
Level 7

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.

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: