A peer address change looks like one line, and it behaves like a migration. What actually moves is a set of objects: the candidate peer list on the crypto map, the profile or authentication mapping that identifies the far end, the underlay that reaches it, and the live associations built from the old values. Treat the configuration edit as the last step of that set rather than the first.

1. Record the current state before you touch anything

Start with the whole candidate list for the relevant crypto-map entry, in order, not just the address you think is in use. Order matters because it is what the device actually tries.

Capture it with show run crypto map and read the effective entry with show crypto map, then save both outputs beside the intended new value. Note which peer each existing association selected, while you are in there.

Do the same for the session layer, using show vpn-sessiondb l2l and show crypto ipsec sa peer <old-address>. Those two outputs are your before-picture when someone asks why a tunnel dropped at 02:10.

2. Prove the new peer is reachable under the same policy

Prove reachability before you schedule the cut. A packet-tracer run from the inside interface toward the new peer's protected network shows whether routing, NAT exemption and the access policy agree. Then confirm the transport path, because IKE and IPsec need UDP 500 and 4500 to pass any filter between the gateways. A ping that succeeds proves none of that on its own.

If the underlay needs a route or a translation change, that is a second change with its own risk. Bundle it into the same window or schedule it separately, but decide which rather than discovering it mid-cut.

3. Move the profile mapping, not just the address

Peer selection and profile selection are different lookups. A LAN-to-LAN connection profile holds general attributes and may match on an address, a certificate identity or a group name. Changing the IP does not change which profile matches when the profile keys off a certificate subject.

ObjectWhat it is keyed onWhat a new peer address touches
Crypto-map candidate listConfigured peer entries and their orderWhere the ASA sends its initial packets
Connection profileAddress, certificate identity or groupOnly the address-keyed profiles
Protected prefixesLocal and remote network objectsNothing, unless you change them too

Keep the credential contract intact. An address change is not a reason to relax identity checks, and it is not a reason to paste a sample pre-shared key into a ticket.

4. Watch live sessions while both candidates exist

While both addresses sit in the candidate list, decide in writing whether the old one is a fallback or debris. A configuration containing both is valid, and it proves nothing about which peer carried the last session.

Clear stale security associations only with the peer-scoped form for your release, clear crypto ipsec sa peer <address>, and expect the affected tunnels to renegotiate. A global reset drops every session on the appliance and will not be forgiven during business hours.

Then pass one real application flow from a protected host and confirm the reply returns through the intended endpoint. show vpn-sessiondb l2l should name the new peer for that session, and the byte counters should move.

5. Close it out or roll back

Write the rollback before the change: the old candidate list, the old profile mapping and the old underlay entry. Keep an independent management path to the ASA, because a peer-address edit that also costs you access is a long evening. Remove the obsolete peer and credentials only after acceptance and after the fallback decision is recorded. Confirm, too, that the access policy on the protected networks did not drift.

The migration is done when the intended peer authenticates and carries the required service under the preserved policy. A new address in the running configuration is evidence of typing, not of success.

Skyldar greinar