Are you able to recreate this problem. I did a quick test on a 2821 running 12.4(13d) and do not see the issue that you ran into.
When you experienced this issue, were you able to ping or traceroute to the actual destination IP Address. The only thing that I can think of is, the routing entry or CEF was somehow corrupted and the router was thinking that he was the destination and address and sending the IPSEC Proposals to himself. But, this is very rare because as soon as you shut down the interface, the CEF Entry is cleared from the database. Let us know what you find with your testing.
I received the following response from the Cisco TAC,
more than a bug this is expected behavior if both tunnel interfaces have the same tunnel destination, which is not very common scenario. The problem is that without a unique identifier for each tunnel (such as tunnel key or different source/destination address, etc) the Router gets confused as to how to properly decapsulate the GRE packet.
You can add an identifier on each tunnel interface, such as a tunnel key:
I do get your point. But as I said, you need to have an identifier that makes one tunnel interface different from the other. The GRE is not even taking place yet in this case; is just a configuration issue that causes the Router not to know which one to use. A tunnel interface is not as a physical interface that you can shut and will completely go down, is just a logical interface. I've been looking for similar issues, possible bugs with no luck. Should be expected behavior.
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...