Ruta predeterminada tunelizada en Cisco ASA: cuándo se aplica realmente

Un usuario de acceso remoto no alcanza nada más allá del ASA mientras el mismo servidor responde a los ping desde la LAN interna. El túnel se levanta, el cliente recibe una dirección del pool y el paquete sigue saliendo por la ruta predeterminada de internet o desaparece. Ese patrón suele significar que el tráfico descifrado no encontró una ruta propia y cayó a la ruta predeterminada ordinaria. La solución no es otra regla NAT; es la ruta predeterminada tunelizada.

Empiece por el síntoma, no por la configuración

Observe adónde va el paquete en lugar de adónde esperaba que fuera. Una captura en la interfaz exterior durante una sesión fallida muestra el paquete descifrado dirigiéndose a la puerta de enlace del ISP con la dirección del pool aún intacta, o no muestra nada porque la búsqueda falló. En ambos casos el túnel no es el problema.

El túnel se ve sano en show vpn-sessiondb, y por eso mismo la gente sigue depurando IKE.

Lo que separa esto de una caída de ACL es la dirección. Una caída de ACL se registra y se cuenta, mientras que una ruta ausente produce un fallo de búsqueda sin ninguna entrada coincidente. Ejecute show route para el destino del cliente y lea qué seleccionó realmente el ASA, incluido si se eligió una ruta predeterminada y cuál.

En qué se diferencia la búsqueda tunelizada

La guía de Cisco de enrutamiento estático en el ASA 9.23 documenta una ruta predeterminada aparte para el tráfico VPN descifrado que no tiene ruta estática ni aprendida. La palabra clave tunneled marca esa ruta, de modo que un paquete descifrado puede recaer en un siguiente salto distinto del que el ASA usa para su propio transporte. Las rutas más específicas siguen ganando, y por eso un cliente puede llegar a 10.0.0.0/8 a través de la puerta de enlace interna y perder todo lo demás.

Un diseño mínimo mantiene dos rutas predeterminadas con siguientes saltos distintos. Una lleva el tráfico propio del ASA y la otra lleva el tráfico descifrado que no tiene una ruta mejor. Ambos siguientes saltos deben seguir siendo alcanzables desde la interfaz a la que los conecta.

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

Si ambas rutas predeterminadas apuntan al mismo siguiente salto, la palabra clave no cambia nada y el síntoma no se moverá.

Las restricciones que deciden si funciona

La misma guía permite solo una ruta predeterminada tunelizada y afirma que ECMP no está soportado para ella, así que no puede repartir la carga por ese camino. También enumera restricciones relacionadas con el seguimiento de rutas, la verificación de ruta inversa y algunos flujos de inspección y gestión. Léalas frente a la versión que tiene instalada antes de diseñar alrededor de la función. Un diseño que las ignora suele fallar en un punto concreto y no en todas partes, y por eso el síntoma parece intermitente.

La verificación de ruta inversa es la que muerde en diseños asimétricos. Si la respuesta llegara por una interfaz distinta de la que el ASA espera, el paquete se descarta antes de que el enrutamiento importe. Corrija la topología o el camino de vuelta en lugar de desactivar la verificación para forzar un siguiente salto.

El seguimiento de rutas es una trampa aparte: el objeto seguido suele proteger la ruta predeterminada ordinaria, no la tunelizada.

Qué no hace la palabra clave

No elige la dirección de origen que el ASA usa para construir IKE. El extremo exterior del túnel sigue la propia selección de interfaz y origen de la plataforma, y la ruta predeterminada tunelizada no tiene parte en esa decisión. Cambiarla no reparará una phase 1 que sale de la dirección equivocada.

Tampoco convierte el siguiente salto en un proxy. Si el destino espera un intercambio HTTP CONNECT, enviar paquetes IP sin procesar a un host proxy solo le da un host que no los enruta. Configure en su lugar el mecanismo de proxy que admite el cliente.

Y no crea reenvío aguas abajo. La puerta de enlace a la que apunta sigue necesitando una ruta de vuelta al pool VPN, además de traducción de origen donde el diseño lo requiera.

Verifique el camino de extremo a extremo

Una vez que la ruta está en su sitio, compruebe cuatro cosas en orden: show route para un destino que el pool necesite, una captura en la interfaz hacia el nuevo siguiente salto, una captura en la propia puerta de enlace y un camino de vuelta desde esa puerta de enlace a la dirección del pool. Las dos primeras demuestran que el ASA eligió el camino, y las dos últimas que alguien responde en él.

Si la puerta de enlace responde pero el cliente nunca ve una respuesta, mire la traducción de origen y la ruta de respuesta antes de tocar de nuevo la tabla de enrutamiento.

Anote la versión con la que validó, porque la lista de restricciones es específica de cada versión y un diseño que funciona en una rama puede necesitar un camino distinto en otra. Esa nota sobrevive al fragmento de configuración.