The topology is attached so I'll try and be brief. Basically what happens is when the IP SLA on the core switch at the branch office fails it injects a backup default route to the secondary ISP for the LAN (5.5.5.0/24). When this happens, "interesting" traffic brings up a site to site from that FW to the same HQ FW the primary uses (3.3.3.2). The problem is when the IP SLA recovers, switches the default route back to the primary ISP and the same "interesting" traffic brings that tunnel up - there are now two tunnels to the same VPN head end unit from the branch. Peer IP address are of course different for the branch end but the peer at the HQ is just one IP and the protected traffic that is defined for each doesn't change. When the primary comes back up, it causes issues with us being able to access resources at the Branch office (and vice versa) until we manually clear the SA for the secondary VPN on the HQ side or it simply expires.
I'd really like this to be automated obviously, but I can't figure out how to do it elegantly (SLAs for tunnels would be nice on the ASAs). It's worth mentioning that the two ASAs at the branch are not in any sort of HA configuration - they are separate firewalls, not dependent on each other, and they don't share any state information. It is important that we keep redundancy there though for more than just losing the INET connection b/c of the ISP, we need hardware redundancy for the firewalls. In the short term, I've changed the delays on the track for the IP SLA on branch core switch so they aren't quite so sensitive but this is not optimal in the long term I don't think. I'm open to any suggestions, even a redesign of the topology at the branch end if it's not costly.
If this posts answers your question or is helpful, please consider rating it and/or marking as answered.
