ASA Failback: What Actually Moves When the Route Returns
A route returning to primary does not mean old flows moved. Watch the uplink, the tunnel, the connection table and the app result together.
On an ASA with two uplinks, failback is not the reverse of failover. The route to the peer changes, and the platform then has to reconcile three separate state machines: the route table, the IKE and IPsec security associations, and the connection table. Each can lag the others, and that lag is what most people describe as a tunnel that will not come back.
What failback actually changes
The route lookup is the visible part. When the tracked object recovers, the monitored route to the peer's outer address returns, and the next packet the ASA sends follows the primary link again. Everything after that depends on whether the existing state agrees with the new path.
ARP and NAT are the quiet dependencies. A new next hop needs a resolvable gateway and a translation that still matches the far end, or the first packets after failback go nowhere and the route looks fine while nothing works.
Four views on one timeline
Record the same four things before, during and after the transition, because a single snapshot cannot tell you which layer moved.
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
A route that never changed and a route that changed while an older connection kept its forwarding state produce the same complaint and completely different evidence.
Why old connections stay on the backup path
The ASA does not tear down a flow because a route changed. Established connections keep the forwarding decision they were created with, and the platform exposes separate controls for how long that is allowed: floating-connection timeout and connection holddown. Cisco's ASA 9.24 connection-settings guide treats them as distinct questions, which is exactly how they behave. One governs the survival of an existing flow; the other governs when new flows may use the preferred path.
Read the effective values for your release before you change either. Lowering them closes sessions people are still using. Raising them makes failback look like it never happened, because new connections keep taking the old path for the duration.
A tunnel does not rekey because a route returned
IPsec security associations carry their own negotiated lifetime, and they survive the route change that carried them. A tunnel can therefore stay up across a failback while its outer addressing no longer matches the path in use, which is the argument for DPD and for designs that pin the peer address instead of floating it.
Crypto-map and VTI designs behave differently here, and Cisco's 9.24 VTI documentation describes the route-based option. The old blanket claim that an ASA cannot run route-based VPNs does not hold for supported releases.
Read the evidence in this order
Start with the control plane: show route for the selected path, show interface for link state, and the SLA monitor counters for the tracked object. Then read show crypto ikev2 sa, or the IKEv1 equivalent, to see which peer is live, followed by show crypto ipsec sa for the protected flows. Then narrow the connection table with show conn address <host> and compare the interface column across old and new entries. Write the outputs down with timestamps, because their order is the diagnosis.
Finish with an application test: one flow that already existed, one created after the route returned. If the old flow fails and the new one works, you have a connection-state story. If both fail, the tunnel or the policy is wrong and the connection table is a distraction.
Keep that record in the same shape across all three phases, and note the exact release. When the timeline keeps pointing at a single transition, send the record to support rather than guessing at a bug ID.