Which VRF reaches the VPN peer and which carries the packet?

Every tunnel inside a customer routing context still has to reach its remote peer, and that lookup can happen in a different table entirely. Getting this wrong produces one of the most confusing failures in VRF-aware IPsec: the tunnel comes up, the routes look present, and traffic dies because one of the two lookups used the wrong context. Run the four steps below in order, and keep the two destinations written down separately.

Two lookups, one tunnel

The outer encapsulated packet is addressed to the peer's transport address, and it is routed before any protection exists. The inner packet is addressed to a customer server and is routed after decapsulation, inside the customer's context. Those are two destinations, two lookups and often two different tables.

Cisco's documentation for VRF-aware IPsec names them the Front Door VRF and the Inside VRF. The front door carries the encrypted transport, and the inside context carries the protected traffic. Nothing about naming a tunnel after a customer makes either route appear.

So list four facts before changing a configuration: the peer's transport address and the context that reaches it, then the server prefix and the context that reaches that. If you cannot fill in all four, you are about to guess. Guessing in this area is expensive, because a route added to the wrong table can make one flow work while quietly breaking another. The four facts take ten minutes to collect and save a day of capture analysis.

Confirm the transport lookup for the peer

Start with the front door, because a tunnel that cannot reach its peer will never pass a single protected packet. On IOS, ask for the route to the peer inside the transport VRF rather than in the global table.

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

The first command answers whether the peer address is reachable in that context, the second lists the VRFs that actually exist, and the third shows whether a security association formed. A peer address that resolves only in the global table is the classic front-door mistake, and it presents as an IKE negotiation that never starts.

Check the interface assignment as well. The documented behaviour requires the tunnel's front door VRF and the WAN interface's VRF to agree; a mismatch can let a packet leave and still prevent the reply from being processed in the right context.

Confirm the inside lookup for the server

With the front door proven, switch to the customer context and ask the same question about the server prefix. This lookup decides whether a decapsulated packet can be forwarded onward.

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

The first command shows the inside route, and the second shows the session state along with the contexts the platform associated with it. If the route exists but the session detail names the wrong inside context, the tunnel is forwarding into a table that does not know the customer's prefix.

A route in the global table is not evidence for either lookup. Global routes are used when a packet is not associated with a VRF, and a tunnel interface assigned to a customer context changes that association. If the inside route is missing, the packet is decapsulated and then dropped for lack of a forwarding entry, which looks like packet loss rather than a routing mistake.

Place the setting where the model expects it

The same documentation distinguishes configuration models, and a setting that belongs to one does not necessarily belong to another. For tunnel interfaces using tunnel protection, the inside VRF is defined on the tunnel interface. For crypto-map based designs, the inside VRF is part of the crypto map entry. Moving a similarly named command between models without checking its role is how a working design becomes an intermittent one.

Routing and identity are separate concerns. Reachability never substitutes for a peer profile the device will accept, and a VRF rename must not alter the credentials offered. Check both after any change, because a tunnel that negotiates with the wrong profile can still form an association and forward nothing.

Finally, record the four facts and the commands that proved them in the change record. The next engineer will inherit the tunnel and not the reasoning, and a short note that names both contexts is worth more than a diagram nobody updates.