Cisco ASA Tunneled Default Route: When It Actually Applies

A remote-access user can reach nothing past the ASA while the same server answers pings from the inside LAN. The tunnel comes up, the client gets an address from the pool, and the packet still leaves by the internet default or disappears. That pattern usually means the decrypted traffic found no route of its own and fell through to the ordinary default. The fix is not another NAT rule; it is the tunneled default.

Start with the symptom, not the config

Watch where the packet goes rather than where you expected it to go. A capture on the outside interface during a failed session shows the decrypted packet heading for the ISP gateway with the pool address still intact, or shows nothing at all because the lookup failed. Either way the tunnel is not the problem.

The tunnel looks healthy in show vpn-sessiondb, which is exactly why people keep debugging IKE.

What separates this from an ACL drop is direction. An ACL drop is logged and counted, while a missing route produces a lookup failure with no matching entry. Pull show route for the client's destination and read what the ASA actually selected, including whether a default was chosen and which one.

How the tunneled lookup differs

Cisco's ASA 9.23 static-routing guide documents a separate default for decrypted VPN traffic that has no static or learned route. The tunneled keyword marks that route, so a decrypted packet can fall back to a different next hop than the one the ASA uses for its own transport. More specific routes still win, which is why a client can reach 10.0.0.0/8 through the internal gateway and lose everything else.

A minimal layout keeps two defaults with different next hops. One carries the ASA's own traffic, and one carries decrypted traffic that has no better route. Both next hops still have to be reachable from the interface you attach them to.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

If both defaults point at the same next hop, the keyword changes nothing and the symptom will not move.

The restrictions that decide whether it works

The same guide allows only one tunneled default and states that ECMP is unsupported for it, so you cannot load-share that path. It also lists restrictions involving route tracking, reverse-path verification, and some inspection and management flows. Read those against your installed release before you design around the feature. A design that ignores them usually fails in one specific spot rather than everywhere, which is why the symptom looks intermittent.

Reverse-path verification is the one that bites in asymmetric designs. If the reply would arrive through a different interface than the ASA expects, the packet is dropped before routing matters. Fix the topology or the return path instead of disabling verification to force a next hop.

Route tracking is a separate trap: the tracked object usually guards the ordinary default, not the tunneled one.

What the keyword does not do

It does not choose the source address the ASA uses to build IKE. The outer tunnel endpoint follows the platform's own interface and source selection, and the tunneled default has no part in that decision. Changing it will not repair a phase 1 that sources from the wrong address.

It does not turn the next hop into a proxy either. If the destination expects an HTTP CONNECT exchange, sending raw IP packets to a proxy host only gives you a host that is not routing them. Configure the client's supported proxy mechanism instead.

And it does not create downstream forwarding. The gateway you point at still needs a route back to the VPN pool, plus source translation where the design calls for it.

Verify the path end to end

After the route is in place, check four things in order: show route for a destination the pool needs, a capture on the interface toward the new next hop, a capture on the gateway itself, and a return path from that gateway to the pool address. The first two prove the ASA chose the path, and the last two prove somebody answers on it.

If the gateway answers but the client never sees a reply, look at source translation and the reply route before you touch the route table again.

Record the release you validated on, because the restriction list is version-specific and a design that works on one train can need a different path on another. That note outlives the config snippet.