Users cannot reach a cloud subnet through an IOS XE IPsec tunnel. The IPsec SA shows both encrypt and decrypt counters increasing. The cloud router has no route for that subnet. Where is the failure?
Select an answer to reveal the explanation.
Short Explanation
The tunnel is carrying packets in both directions, so you can stop blaming the lock. You look at the cloud router, which has no route for the subnet the users want. Rising decrypt counters mean return traffic is arriving, not that the SA is down.
Full Explanation
Encrypt and decrypt counters that both increase show that the IPsec SA is encapsulating outbound packets and receiving return packets. The failure is past the SA. The cloud router has no route for the destination subnet, so traffic that arrives on the tunnel has nowhere to go, or the return is not the path the users need. Fix the route on that router. IKE is not down. A dead SA would not keep both counters moving. The virtual private gateway is not the device that owns this SA in a router-to-router design, and it does not run OSPF. Anti-replay drops individual reordered packets. It does not describe a subnet that is missing from the routing table while the counters keep rising. Exam caveat: confirm the counters are for this peer and not a different SA on the same router. A busy second tunnel can hide a silent one. Operational check: show ip route on the cloud router for the user subnet should list a next hop, and a new flow should then increment both counters and arrive at the host.