Por qué las peticiones TACACS+ de la ASA se saltan el túnel VPN de tu sucursal

El túnel de la sucursal está activo, los usuarios se autentican contra el servidor TACACS+ remoto y el inicio de sesión del propio firewall sigue agotando el tiempo de espera. La causa no es un fallo del túnel: un túnel LAN-to-LAN transporta el tráfico que coincide con sus selectores, y el tráfico de gestión que la ASA genera sobre sí misma es un flujo aparte con su propia dirección de origen. La mayoría de los equipos lo descubren durante una ventana de cambios, cuando la única cuenta de administrador es la que falla. Trate la sesión AAA originada por la ASA como un flujo que hay que diseñar, no como un efecto secundario de una conectividad que ya funciona.

La ASA es el cliente, y su propio tráfico necesita su propio camino

Cuando el firewall contacta con un servidor TACACS+, el firewall es un cliente como cualquier otro, salvo que nadie le configuró una ruta a propósito. Sus paquetes se originan en una dirección de interfaz del dispositivo, se generan localmente en lugar de reenviarse, y hay que enrutarlos, traducirlos y protegerlos con políticas igual que el tráfico de usuario. Un túnel de sitio a sitio que protege una subred de usuarios no protege automáticamente ese origen de gestión, porque la selección de tráfico se basa en direcciones y no en intenciones.

Anote la dirección que espera que vea el servidor. Si no puede decirla en una sola línea, todavía no tiene un diseño.

La interfaz de la línea aaa-server no es decorativa

En la ASA, la entrada de host aaa-server toma una asociación de interfaz entre paréntesis, y la referencia de comandos de host AAA de Cisco la describe como la interfaz donde reside el servidor de autenticación. Esa asociación es lo que ata la petición a una interfaz y a la política que esa interfaz aplica. Elegirla por la interfaz que dé a internet, o dejar lo que hubiera de la última migración, produce una dirección de origen para la que nunca se construyeron el servidor remoto ni el túnel.

inside solo es la respuesta correcta cuando la interfaz nombrada tiene la dirección que su diseño pretende usar como origen. En un dispositivo de sucursal suele serlo; en un dispositivo con varios segmentos privados puede que no.

Cambiar la asociación significa recrear la entrada

La misma referencia de comandos documenta una restricción de edición que atrapa a la gente durante las migraciones: cambiar la interfaz de un host existente exige eliminar y recrear la entrada de host. Una configuración que parece editada puede no haber surtido efecto, y el siguiente intento de inicio de sesión seguirá saliendo de la dirección antigua. Planifíquelo como un borrado y alta con una copia de la entrada original delante, no como un retoque in situ.

Si hay varios servidores definidos, cambie uno y pruébelo antes de tocar los demás, para que un error no bloquee todas las rutas administrativas a la vez.

Compruebe selectores, traducción y ruta de retorno a la vez

Tres cosas tienen que coincidir para que la petición llegue. Los selectores de tráfico del túnel, o la protección de la interfaz de túnel si usa una, deben incluir el origen propio de la ASA y la dirección del servidor; una lista de selectores hecha para subredes de usuarios normalmente no lo hará. Cualquier regla NAT en el camino debe traducir ese origen de forma coherente, porque el servidor autoriza una identidad de dispositivo de red que incluye la dirección que ve. Y la ruta de retorno tiene que existir, lo que en un túnel basado en políticas significa que el extremo remoto tiene un selector coincidente en el sentido contrario.

En el lado del servidor, confirme por separado la identidad del dispositivo, el secreto compartido y la política administrativa. TACACS+ mantiene la autenticación, la autorización y la contabilidad como operaciones distintas, así que una denegación que llega tras un intercambio completado es una respuesta de política, no un fallo de transporte. Leerla como un problema de red le lleva a buscar en el sitio equivocado.

Mantenga el secreto fuera de capturas, tickets y transcripciones mientras depura, y recuerde que la dirección de origen que registra el servidor es la que su diseño tiene que explicar.

Haga el cambio sin quedarse fuera

Use una consola o una ruta de gestión independiente mientras cambia la autenticación administrativa remota, y mantenga un plan B local aprobado hasta que la nueva ruta haya cursado un inicio de sesión real. Luego valide de forma estrecha: un servidor, un dispositivo, una autenticación correcta con la dirección de origen observada en ambos extremos.

Registre el flujo en su propia página: interfaz y dirección de origen, servidor remoto, ruta protegida y la persona propietaria de la política de autorización. Así un cambio posterior de interfaz o de túnel puede evaluarse sin adivinar cuál de los dos flujos afecta.