How to model a VPN flow with ASA packet-tracer

Packet-tracer on an ASA answers a narrow question: would this packet, entering here with this tuple, be permitted, and where would it go. It does not answer whether the far end receives anything. The usual mistake is feeding it an outer IKE tuple when the thing you want to test is the application that rides inside the tunnel. Fix the tuple first, read the phases, then get real evidence for everything the simulator cannot see.

The walkthrough below assumes the ACL, NAT rule and tunnel-group context are in front of you. Without them the output describes a policy you cannot check.

Step 1: write the inner flow in plain words

Describe the application before typing anything. A host on the inside opening SSH to a server behind the far gateway is one inner TCP flow with a specific source port. That is the flow the ACL and the VPN filter evaluate, so that is the flow you type.

Write it as a sentence, then translate it field by field:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Step 2: pick the ingress and the direction

Ingress is the interface the packet arrives on, not the one it leaves by. For a LAN host initiating, that is the inside interface. For the return packet of the same session it is the outside interface, and the tuple reverses. Typing the destination as the source is the second most common way to earn a convincing but irrelevant ALLOW.

Ports are directional too. The service port belongs in the destination field for an initiated request, and the client's ephemeral port belongs in the source field. A model with TCP destination 500 describes a TCP application listening on 500; it does not become an IKE test because the number appears in the command.

Step 3: read the phases in order

Each phase in the output is a decision with an owner: route lookup, ACL, NAT, then VPN or tunnel selection. Read them in the order printed and stop at the first phase that disagrees with the design.

NAT catches people out. If the translated source falls outside the crypto ACL that selects traffic for the tunnel, the flow can be permitted and never encapsulated. The trace prints the translated address, so compare that with the tunnel's interesting traffic rather than with the original address.

Step 4: check which bypasses you selected

The detailed form takes options that skip checks, and Cisco documents a bypass-checks option covering ACL, VPN filter, uRPF and IPsec spoof checks. An ALLOW obtained with those bypassed says the route and NAT would work, not that the policy would admit a real packet. Record the options next to the result.

If you need the policy answer, run it without the bypasses. If you are isolating a routing question, run it with them and label the result as a routing answer.

Step 5: close the gap with the real exchange

A simulated permit stops at the ASA. Whether the far gateway decrypted the packet, whether the server accepted the connection, and whether a reply came back are separate observations. Use endpoint counters or a narrow capture on an approved path.

Some trace and replay options transmit packets or persist state. Follow the documented behaviour for your release and your approved diagnostic procedure instead of treating every variant as a read-only lookup.

What the trace still cannot tell you

Keep four things in one note: the tuple, the matched NAT rule, the tunnel or policy that should carry the flow, and the direction-specific observation. Without them a later engineer cannot separate a local policy decision from an established control plane from a working service. A first failure followed by a success is not proof that the tunnel had to come up in between either; record the phase and the state change.

Start with the inner tuple, stop at the first phase that contradicts the design, and only then reach for endpoint evidence. The trace is a policy oracle, not a delivery receipt.