Automating ASA Tunnel Resets: Three Gates Before You Allow It
Before an ASA clears a peer's security associations on its own, settle three gates: the fault is inside the tunnel, the scope is one peer, retries stop.
Think of an automated tunnel reset as a recovery action with a blast radius, not a scheduled mood swing. The decision in front of you is narrower than the tooling suggests: which failure justifies it, which peer it may touch, and what makes it stop. Get those three wrong and you have built a machine for deleting evidence. I have watched one of these fire every fifteen minutes against a healthy peer for most of a week, and nobody noticed because the tunnel came back each time.
Gate one: prove the failure is inside the tunnel
Correlate fresh state before you authorize anything. show crypto ikev2 sa detailed tells you whether the IKEv2 association exists and how far negotiation got, and show vpn-sessiondb detail l2l gives you the session view that matches the same peer. Then show crypto ipsec sa peer 203.0.113.10 shows the child SAs, the encaps and decaps counters and the selectors in use. A rising encaps counter with a flat decaps counter is a very different problem from no association at all.
Next, check what a rebuild cannot repair: a missing return route, an MTU that blackholes large packets, a policy that denies the port after decryption, or asymmetric routing that sends replies around the appliance. Clearing SAs against any of those produces a brief green blip and the same ticket tomorrow. Each one looks like a dead tunnel from the application side, which is why the counters matter more than the alert.
Snapshot before the action. Record the peer, the association identifiers, the counters at the moment of the trigger and the evidence that fired it. A reset that runs ahead of the snapshot destroys the most useful data the incident had.
Gate two: scope the peer, never the world
On the ASA CLI, clear crypto ikev2 sa peer 203.0.113.10 and clear crypto ipsec sa peer 203.0.113.10 are targeted operations. The same commands without a peer argument clear every association in the context, which makes them a variation in spelling and an outage in effect. Cisco's clear command reference separates those forms from the statistics-only variant, which resets counters and repairs nothing. In multi-context mode the command acts only on the current context, so the automation must also be sure which context it is in.
Validate the peer before the command is constructed. An empty or unresolved variable has to fail the job loudly rather than collapsing into a clear-all, and that check belongs in code a reviewer can read.
Map the blast radius honestly. One peer can carry several protected networks, thousands of sessions and a second tunnel used for management, so a peer-scoped clear is still a multi-customer event on a hub. Run the action from a management path that does not depend on the tunnel being reset. Otherwise the automation cannot verify its own result, and the next step is a human driving to the site.
Gate three: retries, cooldown, defined success
Give the job a per-peer lock, a cooldown and a hard attempt limit counted from fresh observations. Without the lock, two monitors that trip at the same moment clear the same peer while renegotiation is in flight, and each concludes the other one failed.
Success means the association is back and the permitted workload passes, not that the command returned without an error. Probe with the same check that detected the fault, then confirm the child SA counters move in both directions. A command that exits zero while the tunnel stays down is a monitoring failure dressed as a recovery.
Keep unknown separate from failed. If telemetry is stale or the management path is unreachable, the honest state is unknown, and a retry budget should not read that as permission to fire again.
When the first approved recovery does not restore service, escalate with the snapshot instead of looping. Scheduled resets are the worst version of the pattern, because they hide a rekey, route or policy defect while cutting healthy sessions on a timer.
Ownership, an off switch, and one rehearsal
Name an owner, document how to disable the applet or schedule in one step, and set a review date. An automation with no disable path becomes permanent infrastructure the day its author changes team.
Rehearse it in a lab or maintenance window with the peer selection deliberately broken, so you find out whether the job fails closed. Then rehearse the success path, because a job that only ever runs while something is wrong teaches you nothing about its normal behaviour.