Cisco ASA to Azure VPN: Traffic Selector Prefix Pairs

The tunnel comes up, IKE looks healthy, and nothing crosses it. That is the usual shape of an ASA to Azure selector problem, and it is why I write the contract before touching either console. The contract is four things: the objects that identify each peer, the connection model, the exact prefix pairs, and the verification that proves each pair. Get those wrong and every later command debugs a configuration you should not have built. This runbook is the order I use, with the commands that show which object is actually wrong.

Write down the four objects before you configure

Start with the ASA release and platform, the public endpoint, the Azure VPN gateway type and SKU, and the local network gateway that represents your side. Those four names are the vocabulary for everything that follows, and each one has a different owner when something breaks.

If two of them are still guesses, stop. A wrong local network gateway prefix list is not a tuning problem.

Pick one connection model and stop mixing templates

A crypto-map design and a tunnel-interface design are different configurations, and a template for one does not become valid for the other by editing the peer address. Record which one you are building before you paste anything, because the mismatch later surfaces as a selector problem rather than as a configuration error. Microsoft's ASA interoperability guide covers both patterns and states which Azure gateway model each one assumes. If your notes do not name the model, you do not have a design yet.

A route-based Azure gateway with policy-based traffic selectors is a specific documented option, not the default. If your design depends on it, the design has to say so, because the default route-based selector model behaves differently on the Azure side.

Version limits belong in the contract too. An old field report about a cap on encryption domains is a data point about particular releases, not a permanent property of every ASA.

Enumerate the prefix pairs, not the aggregates

Write the matrix. On-premises A and B to Azure X and Y is four pairs, and each one either needs coverage or an explicit exclusion. Collapsing A and B into one aggregate also includes whatever sits between them, which is how a design quietly grows a hole.

Check what the peers negotiated rather than what you saved. A local and remote network list on the ASA is intent; the CHILD SAs are the result.

When a pair is missing, the fix is usually an access-list line or a selector entry, not a new tunnel.

Verify with commands that name the object

On the ASA, confirm the IKE session, then the IPsec SAs, then the selector pairs. Each command answers a different question, and running only the first is how "the tunnel is up" becomes a false conclusion. Read the output for the peer you actually configured instead of whichever SA happens to be first in the list. The Azure side answers the same three questions from its own point of view.

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

Then ask Azure for the connection state with az network vpn-connection show --name <connection> --query connectionStatus. Connected with zero bytes in the data path is a selector problem, not a routing problem.

Test one permitted flow per pair, inspect the source address seen on the far side, and try one resource that should be denied. That last test is the only one that proves the boundary still exists.

Keep encryption scope separate from access permission

A broad selector is not permission. If the supported layout is wider than the application policy, keep the narrow services in the firewall rules and leave the encryption scope where it has to be.

Azure workload routes and on-premises return routes get reviewed separately. BGP advertisements, static network scope and user-defined routes all have to describe the same path, and none of them may capture the peer transport recursively.

Rollback and the proof that it worked

Keep the previous running configuration before you change selectors, and know the one command that puts it back. On the ASA that means a saved copy and the matching restore path, not a memory of what you edited. Write the restore command into the change ticket while the change is still hypothetical. Then re-run the same three checks: IKE state, IPsec SA pairs, one permitted flow per pair.

If a pair still fails after the restore, the change was not the cause, and you have just saved yourself a second outage.