You sure can do that.
Your routers or ASA's (more specifically your crypto devices, or the devices responsible for terminating your site to site ipsec vpn tunnels) will just be configured to have a s2s connection as follows:
A <=> B
A <=> C
Now site A is attempting to send traffic to site B -- the server receives some type of SYN timeout or basically whatever the SaAB tcp flag means (been a while). Something on that server (excuse me, I'm not a server person) -- kicks in and basically says "can't communicate with Site B -- let me send my *interesting traffic* to the remote device located at Site C instead.
The crypto device receives the traffic for Site C -- Interesting traffic is flagged, Security Association negotiations take place, and the communication begins to occur.
This would typically indicate a TCP session that is in the midst of taking place, and will probably not be interupted, should site B's connectivity to the internet restore.
Once this communication is complete, there is probably some type of setting on the server (at Site A) that will (after x amount of time) attempt to send whatever next piece of information over to site B.
Or Maybe the server at Site B sends some signal to Site A's server that it's back up and resets whatever flag was triggered to send its information to Site C.
If it's a 24x7 operation, of course, and people are constantly monitoring, you could always have a person set where to send that data manually on the server side of things.
Basically, this is a server issue. Not a fw or routing issue.
--
Does that make sense?
From a FW or routing perspective, you're just setting up S2S tunnels between each location. That is it. The servers handle the rest. It would make sense, also, that the people in charge of the servers are the ones with visibility to see when some type of failover occurred so they know where their data ended up anyway.
Hope that helps.
