La VPN entre sedes funciona, pero los registros de la ASA no llegan: revise la dirección de origen

Los equipos internos llegan al colector remoto y sus líneas syslog aparecen. Los mensajes propios de la ASA sobre esas mismas sesiones nunca llegan. No hay nada mal con el colector ni con el túnel, y esa es la parte confusa. El cortafuegos envía sus registros desde un origen para el que el túnel nunca se construyó.

Qué llega y qué no

Empiece separando dos flujos que en un panel parecen idénticos. El tráfico reenviado atraviesa la ASA: un equipo LAN envía al colector, la ASA lo compara con la política del túnel, lo cifra y el colector ve la dirección del equipo. El tráfico generado nace en la propia ASA: el equipo construye un paquete syslog, elige una interfaz de salida y un origen y solo entonces pregunta si encaja alguna política de túnel. El primer flujo demuestra que el túnel funciona y no dice nada del segundo.

Un evento en búfer en el dispositivo tampoco es prueba de entrega remota, porque el registro puede existir localmente y no haberse transmitido nunca. Revise los contadores de recepción del colector antes de culpar al túnel, porque un contador vacío es un hallazgo distinto de uno que crece.

Un mensaje generado no es tráfico reenviado

Cuando la ASA origina un paquete, no actúa como proxy de un equipo LAN. El origen procede de la interfaz de salida o de un ajuste de origen explícito, y el paquete entra en la misma búsqueda de ruta y las mismas comprobaciones de política que cualquier otra cosa que envíe el dispositivo. Eso significa que el selector de VPN debe incluir la dirección que la ASA usa realmente, que con frecuencia es su interfaz exterior y no una subred interna.

Si la política protege 10.20.0.0/24 y la ASA usa su dirección exterior como origen, el paquete de registro o sale en texto claro hacia un colector al que no puede llegar, o se descarta. Ambos resultados se ven idénticos desde el lado del colector. El mismo razonamiento se aplica al tráfico de gestión, por eso management-access es una decisión de diseño aparte.

Qué origen pone la ASA en la red

Encuentre el origen empíricamente, no por suposición. Una captura en la interfaz de salida durante un mensaje de prueba muestra el origen y el destino reales, y cuesta menos tiempo que leer tres secciones de configuración. Compare esa dirección con el selector local del túnel.

Algunas versiones permiten fijar el origen de registro a una interfaz, y la referencia de comandos de su versión es la autoridad sobre si esa opción existe y qué cambia. Un comando source-interface de otra plataforma Cisco no es automáticamente válido en una ASA.

Si cambia el origen, hágalo deliberadamente y anótelo, porque las ACL del colector y cualquier correlación basada en syslog dependen de él.

Ajuste el selector al flujo de registro

Una vez conocido el origen, revise tres cosas en orden: la ACL de criptografía o el selector basado en política que decide qué tráfico es interesante, la ruta que decide adónde va el paquete y cualquier regla NAT que pueda reescribir el origen antes del cifrado. Un paquete que coincide con la ruta pero no con el selector no pasa por el túnel, y un paquete reescrito por NAT puede no coincidir con ninguno de los dos.

El lado del colector tiene requisitos propios: una ACL que permita el origen de la ASA, una ruta de retorno y un servicio a la escucha en el puerto que configuró. El transporte también importa aquí, porque el registro por TCP y TLS se comporta distinto del UDP en una ruta parcialmente bloqueada. Cambie un elemento cada vez, o la próxima captura no le dirá qué cambio importó.

Verifique en el colector y luego anote el origen

Confirme que el mensaje llega y luego anote la dirección de origen que usó la ASA, el selector que lo transportó y la gravedad con la que probó.

Ese registro convierte el próximo cambio de ACL del colector o la edición del selector en una comprobación de dos minutos en lugar de un redescubrimiento. También documenta cuál de los dos flujos se validó alguna vez, que es la parte que omiten casi todos los runbooks. Si el mensaje sigue sin llegar, baje temporalmente el umbral de gravedad y pruebe contra un único destino.

Las preguntas frecuentes de registro de la ASA de Cisco documentan un caso con origen externo que necesita la definición correspondiente de tráfico protegido, y su ejemplo con origen interno incluye tanto un equipo de registro en el interior como management-access en el interior. Trate la combinación documentada y el contexto del software juntos, en lugar de suponer que una línea copiada encaja en cualquier configuración.

Un túnel que transporta tráfico LAN no es un túnel que transporta la voz propia del cortafuegos.