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 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.
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.
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...