I think adding a "local-address" parameter to the crypto map on my remote router will solve the issue described below. I tried setting it to my loopback1 interface but that just resulted in packets with a source address of my privately addressed (192.168.x.x) loopback1 heading to certain death on the Internet. I kind of expected this but I tried it anyway as this little detail wasn't mentioned in any of the docs that I've found so far.
Is this parameter only useful in a private network where you have full control of routing tables, or is there some way to get the response packets from the ASA across the Internet, to the loopback address of the remote router via the correct interface (the one that is "up") of the remote router?
Here's the setup:
I have a remote router doing an IPSEC VPN to an ASA5510. Normally the remote router connects via Fa0/0 which is connected to a telco supplied DSL modem. Fa0/0 has a static IP. If the DSL link fails the router uses an internal analog modem to dial a local ISP, and then sets up an IPSEC VPN to the same ASA5510. DDR is triggered by an IP SLA monitor that pings the ASA. The IPSEC tunnel carries a GRE tunnel to support dynamic routing (OSPF). The remote router terminates the GRE tunnel on Loopback1 and the other end of the GRE tunnel terminates on a router behind the ASA at the central site.
Failover to dial backup works great. It takes 30-45 seconds to get traffic flowing. Not bad for analog dialup.
My problem is with failback. When the DSL line comes back up the IP SLA monitor detects it and re-installs the tracked routes correctly. The router pushes the GRE packets out the correct interface so the idle-timer on the async interface times out as it should. The bad part is that as soon as the IP SLA monitor sees that the DSL line is up, production traffic stops working for about 105-120 seconds.
During this "outage" the router sees the GRE tunnel interface as "up" and it has two VPN tunnels to the ASA established. Killing the async connection manually does not end the "outage" any sooner.
I suspect that the ASA is either not forwarding the GRE packets back to the remote router because it has two tunnels and doesn't know which to use, or it's doing round-robin distribution between the tunnels and the packets are getting to the remote router too far out of sequence to be useful. If either of these is true it should be solved by the "crypto map mymap local-address" config on the remote router which would prevent the duplicate IPSEC tunnels.