Two Crypto Maps, One Flow: The Later Entry Is Not a Backup

Add a second crypto map entry for the same address pair, point it at a different peer, and you have written a failover plan. That is the myth, and it survives because it looks like every other ordered list you have configured. Sequence in a crypto map decides which entry claims a new flow, not which entry takes over when a peer stops answering. Nothing in that list monitors the far end, so the second entry sits there claiming nothing at all.

The myth: order means fallback

An ordered list with two entries and one shared definition feels like primary and secondary. The resemblance ends at the syntax. Cisco's ASA documentation describes the crypto map as the policy model that matches protected traffic and names the peer arrangement for it, and matching happens against the entry that claims the flow first. Availability of a remote peer is not part of that evaluation.

What you have built is a policy that will never be consulted for that flow, plus a comment in a change record claiming redundancy.

Sequence claims the flow, and only once

Each entry holds an access control list or a protected-flow definition, and a new outbound packet is compared against those definitions in sequence order. The first entry whose definition matches owns the flow and its peer. A second entry with an identical definition never gets a turn, because the first one already matched; a second entry with a narrower definition only serves flows the first one did not claim.

That behaviour is useful when you are deliberately carving exceptions out of a broad policy, and it is useless as a failover mechanism. Check what actually happened with show crypto map and show crypto ipsec sa peer, then trace a synthetic packet through the path you believe it takes. The trace will name the entry that claimed it, which is the only answer that matters.

Route selection and policy ownership are separate decisions

A routing table answers where the packet is forwarded. The crypto policy answers which protection and which peer apply to the selected traffic. Duplicating a source and destination pair under another peer changes the second decision and leaves the first untouched, so replies may still follow the old gateway while the outbound packet takes the new peer. That asymmetry produces a tunnel that reports up and passes nothing.

Keep the remote contract reciprocal as well: accepted identity, protected address ranges, a return route for the interesting prefixes and permission for the service. An alternate outbound choice that the other side does not expect is not an alternate path, it is half of one.

What a real alternate path needs

Choose a mechanism that is designed for the job: a supported group of peer candidates, a routed tunnel with a floating static or a dynamic routing adjacency across it, or whatever redundancy design your platform documents for that service. Then write down which component detects the failure and which component selects the alternate, because those are two different functions and often two different teams.

Address translation can also give a site a second presented address, but it changes selectors, logging and source-based access rules at the same time. Treat that as an explicit requirement rather than as a workaround for two ambiguous entries.

Test three states, not one

The configuration is only finished when it has a defensible answer for normal operation, for the failed-primary state, and for the return to primary. Test all three and record which policy entry and which peer served each one. A test that stops after the first state proves that the design works when nothing is wrong, which is the state you did not need to check.

Also distinguish configured overlap from the legitimate coexistence of old and new associations during a rekey. Several active SAs are normal and temporary; two entries fighting over one flow are permanent and invisible.