Asignar logs de servicio de Sophos Firewall

En Sophos Firewall hay tres niveles importantes para la solución de problemas: los registros de eventos en el Log viewer, herramientas de diagnóstico en WebAdmin y archivos de servicio o log en el firewall. El Log Viewer es ideal para preguntas rápidas como “¿se permitió o bloqueó la conexión?”. Los archivos en /log son más importantes cuando un servicio no se inicia, un túnel VPN es inestable, los filtros web actúan inesperadamente o el soporte necesita datos detallados.

Este artículo clasifica los servicios y archivos de registro más importantes según problemas típicos de administración. También es útil cuando en el panel de control, en la Advanced Shell o en un caso de soporte aparece un nombre técnico de servicio y no está claro de inmediato qué función del firewall está detrás. Nombres como zebra, warren, awed, garner o strongswan no son autoexplicativos en la vida cotidiana.

Selección de herramienta y requisitos previos

Antes de buscar en archivos de log, debe estar claro qué herramienta ofrece la respuesta más rápida. Muchos casos ya pueden delimitarse con Log Viewer o Packet Capture. La shell solo resulta realmente útil cuando hay que comprobar un servicio en sí o cuando soporte necesita datos de log detallados.

¿Qué herramienta de solución de problemas es adecuada?

No todos los problemas del firewall comienzan con una shell. A menudo, otra herramienta es más rápida al principio:

• ¿Conexión permitida o bloqueada? Probar regla de firewall con Log Viewer, Policy Test y Packet Capture.
• ¿Todo Log Viewer ha dejado de mostrar eventos nuevos? Revisar filtros, logging y el workaround de Garner específico de la build.
• ¿Se ha reiniciado inesperadamente todo el firewall? Primero clasificar el reinicio como reboot del appliance, failover HA o fallo de un servicio y después guardar sysinit.log, syslog.log y el CTR.
• ¿Los paquetes llegan, pero no está claro si continúan? Usar Sophos Firewall Packet Capture en WebAdmin.
• ¿La captura debe durar más, guardarse como PCAP o analizarse en Wireshark? Sophos Firewall tcpdump: capturar paquetes por CLI.
• ¿Se sospecha una modificación de configuración como causa? Revisar Sophos Firewall Audit Trail Logs.
• ¿Una modificación desde Sophos Fusion (antes Sophos Central) está atascada? Revisar Sophos Fusion Firewall Task Queue.
• ¿Se necesitan informes o historial en Sophos Fusion? Activar y operar Sophos Firewall Central Reporting.
• ¿Los logs deben ir a largo plazo a SIEM, SOC o servidor de logs? Enviar Syslog de Sophos Firewall a SIEM.
• ¿El foco son los flujos de tráfico, los picos de ancho de banda o los patrones de comunicación? Configurar la monitorización sFlow en Sophos Firewall.
• ¿Un servicio no funciona o soporte necesita logs? Este artículo.
• ¿Guardar logs locales para Sophos Support o Avanet? Asegurar registros de Sophos Firewall para soporte y análisis.
• ¿Preparar un caso de soporte? Abrir un ticket de soporte de Sophos: Preparación y portal.

El orden es importante. Log Viewer suele mostrar más rápido qué regla o módulo tomó la decisión. Packet Capture demuestra el flujo de paquetes en WebAdmin. tcpdump es útil cuando se necesita una captura más larga, un archivo PCAP o un filtro CLI muy preciso. Los registros de servicio y depuración ayudan cuando un servicio específico es el problema o cuando se deben recopilar datos para Sophos Support.

Para cuestiones exclusivamente de conectividad, Diagnostics > Tools complementa la búsqueda en los logs con Ping, Traceroute y consultas de DNS y rutas. Ping comprueba la conectividad, Traceroute la ruta seguida y una consulta comprueba la resolución de nombres o la ruta correspondiente. Los comandos básicos de diagnóstico ayudan a elegir la herramienta; una prueba satisfactoria desde el firewall no sustituye a una prueba desde el cliente afectado.

Entrada rápida por síntoma

Si no está claro qué log es relevante, ayuda empezar por el síntoma en lugar del nombre del servicio.

• Una conexión individual no funciona: primero revisar Log Viewer con origen, destino, servicio y hora. Después usar Packet Capture, firewall_rule.log y nat_rule.log.
• El túnel VPN está inactivo o inestable: revisar el estado de la VPN, la IP del peer, la hora y Log Viewer. Después consultar strongswan.log, charon.log, sslvpn.log y los datos de diagnóstico de IPsec.
• WebAdmin, User Portal o SSH no son accesibles: revisar Device Access, Local Service ACL y la zona afectada. Después usar apache.log, tomcat.log, sshd.log y Packet Capture sobre el puerto de destino.
• Webfilter, TLS Inspection o IPS bloquean inesperadamente: revisar módulo de Log Viewer y Policy ID. Después comparar ips.log, awarrenhttp.log y Packet Capture.
• Una tarea de Sophos Fusion queda atascada: comparar Central Task Queue y estado local. Después revisar centralmanagement.log, sophos-central.log y fwcm-api-executor.log.
• HA se comporta de forma distinta según el nodo: identificar el nodo activo, el nodo auxiliar y la ruta de tráfico afectada. Después iniciar sesión directamente en el nodo afectado y revisar los registros de HA.
• Faltan informes locales o el almacenamiento se llena: revisar los ajustes de informes, el espacio disponible y Central Reporting. Después usar reportdb.log, garner.log y el análisis de almacenamiento.

Esta vista evita una trampa habitual: buscar en un registro de servicio aunque primero habría que comprobar la coincidencia de reglas, Device Access, NAT o el enrutamiento.

¿Log Viewer o archivo de registro?

El Log viewer se abre en la consola WebAdmin en la parte superior derecha. Se actualiza automáticamente, se puede filtrar por módulo, tiempo, valores de campo y texto libre, y puede exportar registros como CSV.

Para proteger nombres de usuario y direcciones IP, MAC y de correo en la vista diaria de logs se puede utilizar Data Anonymization para logs e informes locales. Su efecto en Log viewer no demuestra automáticamente que los archivos en /log, CTR, Remote Syslog o Central anonimicen las mismas identidades; cada ruta de salida se comprueba por separado.

Los registros de solución de problemas se encuentran en el directorio /log. La ruta documentada oficialmente pasa por la CLI: iniciar sesión, elegir 5 Device Management y después 3 Advanced Shell. SSH suele resultar más cómodo para sesiones largas con tail, grep o less. Su preparación segura se describe en Conectar Sophos Firewall por SSH.

Antes de sesiones largas en la shell, debe estar claro desde qué red de administración se conecta, si se ha verificado la huella digital SSH y si realmente se necesita la Advanced Shell. Para muchas verificaciones iniciales, el Log Viewer o Packet Capture en WebAdmin son suficientes.

Como regla general, esta es la secuencia:

1. Un flujo de tráfico individual está afectado: filtrar en Log Viewer por origen, destino, servicio y hora.
2. Log Viewer no muestra decisión: iniciar Packet Capture con filtro estrecho.
3. Packet Capture muestra Incoming, pero no una decisión clara: revisar Rule ID, NAT ID, Firewall ID 0, ruta de retorno y log adecuado.
4. Un servicio concreto parece inestable: observar el archivo adecuado en /log con tail -f.
5. Un error es esporádico o necesita soporte: preparar ventana temporal, filtro, archivo de logs y, si procede, tcpdump.
6. Los logs normales no bastan: activar Debug solo para el servicio afectado y durante poco tiempo.

Esto mantiene el análisis lo suficientemente pequeño. Primero se recopila la evidencia visible, luego se cambia al flujo de paquetes y solo después a los registros de servicio o depuración. Esto reduce el riesgo de activar registros de depuración amplios demasiado pronto o evaluar un archivo de registro incorrecto.

Leer archivos de registro en la Advanced Shell

Antes de buscar en /log, el caso de prueba debe estar documentado lo más estrechamente posible: hora local, IP de origen afectada, IP de destino, puerto, usuario, módulo y comportamiento esperado. Estos datos marcan la diferencia entre un análisis de registros útil y una búsqueda larga a través de entradas antiguas.

1. Iniciar sesión en la CLI, elegir 5 Device Management y después 3 Advanced Shell.
2. Cambiar al directorio de registros.

cd /log

Comandos útiles:

tail -f firewall_rule.log
tail -f nat_rule.log
grep -i error ips.log
less strongswan.log
service -S | grep ips

Los comandos más importantes de la Advanced Shell:

• Leer en vivo: tail -f /log/<logfilename>.log, por ejemplo tail -f /log/ips.log.
• Leer un archivo estático: less /log/<logfilename>.log, por ejemplo less /log/ips.log.
• Buscar un término: grep <keyword> /log/<logfilename>.log, por ejemplo grep error /log/ips.log.
• Leer el estado de un servicio: usar service -S o limitarlo a un nombre, por ejemplo service -S | grep ips. Esta comprobación no modifica el servicio.

Para aplicar un filtro más preciso en tiempo real, se puede añadir la fecha o la dirección del cliente:

tail -f /log/ips.log | grep 2026-10-10
tail -f /log/ips.log | grep 192.0.2.10
less /log/ips.log | grep error

La fecha y 192.0.2.10 son valores de ejemplo: deben sustituirse por la fecha que aparece en el log o por la IP del cliente afectado. tail -f solo muestra las últimas líneas existentes y las nuevas entradas que se van añadiendo, no todo el historial del día automáticamente. Para las entradas ya guardadas, se utiliza, por ejemplo, grep 2026-10-10 /log/ips.log. Si el filtro no devuelve resultados, primero hay que comprobar el formato de fecha y hora, la zona horaria, la IP y el archivo de log antes de sospechar que faltan registros. En less /log/ips.log, Shift+G salta al final del archivo, Enter avanza una línea y q cierra la visualización; Ctrl+C detiene una captura en curso con tail -f. La canalización con less genera una salida de texto filtrada, no una vista interactiva de less. Estos comandos leen los logs, pero no modifican las reglas ni el estado de Debug.

Para soporte o un análisis posterior, no solo se deben copiar líneas individuales de registro. Es mejor tener un rango de tiempo claro, la prueba reproducida, capturas de pantalla relevantes de Log Viewer o Packet Capture y, si es necesario, un archivo de registro completo. Los registros locales rotan; por lo tanto, los datos importantes deben asegurarse mientras el evento aún está dentro del período afectado. El procedimiento se describe en Asegurar registros de Sophos Firewall para análisis externo.

Descargar troubleshooting logs en WebAdmin

No toda recopilación debe montarse manualmente en Advanced Shell. WebAdmin reúne los archivos en Diagnostics > Tools.

En la práctica hay dos caminos:

• Archivos de log individuales: abrir Diagnostics > Tools > Troubleshooting logs, seleccionar los logs afectados y descargarlos como archivo comprimido.
• Consolidated Troubleshooting Report (CTR): usar Diagnostics > Tools > Consolidated troubleshooting report cuando soporte necesita todos los logs más estado del sistema, procesos y datos de recursos en un solo paquete.

Esto resulta práctico cuando basta un paquete de registros bien delimitado. El CTR es mejor cuando Sophos Support necesita una instantánea amplia del sistema. Debe indicarse un motivo claro, como el número de ticket, el intervalo temporal o el síntoma. El informe se descarga cifrado; su nombre también contiene el número de serie del firewall, por lo que no debe incluirse en adjuntos públicos.

De forma predeterminada, un CTR contiene 10.000 líneas por cada service subsystem log. En Device Console el valor solo puede fijarse entre 250 y 10.000, por lo que únicamente se puede reducir respecto al valor predeterminado. Los default subsystem logs incluyen todas sus líneas. Este límite se aplica solo al CTR; los archivos individuales completos siguen disponibles mediante Troubleshooting logs o Advanced Shell.

Importante: un paquete de logs descargado no sustituye los datos de contexto. Soporte sigue necesitando hora con zona horaria, IPs afectadas, usuario, nombre del túnel, Rule ID, NAT ID y una breve descripción de lo que se reprodujo exactamente.

En clústeres HA hay que tener en cuenta además: los logs e informes no se sincronizan simplemente entre Primary y Auxiliary. Cada nodo contiene los logs del tráfico y de los servicios que ha procesado él mismo. En errores específicos de un nodo, por tanto, debe revisarse el nodo afectado.

Entender la rotación de logs y los datos volátiles

Los Troubleshooting Logs se crean primero en memoria y la firewall los copia al sistema de archivos. Si la firewall deja de responder, pueden perderse entradas que todavía no se hayan copiado. Por tanto, un reinicio inesperado o un bloqueo no justifican retrasar la conservación de evidencias; primero se guardan CTR, logs y cronología disponibles.

Cada subsistema tiene límites propios de tamaño de archivo y almacenamiento según su criticidad y el modelo de appliance. Cuando el archivo activo alcanza el límite, SFOS lo comprime como .gz y sigue escribiendo con el nombre original. Cuando también se alcanza el límite de rotaciones del subsistema, elimina primero el archivo comprimido más antiguo. Por eso, el número de rotaciones y el historial disponible no son iguales en todos los servicios.

Los archivos de log y las rotaciones .gz no se renombran ni eliminan manualmente. Para el análisis de espacio, la exportación y los comandos de purge documentados se aplica el flujo de Gestionar el almacenamiento y los reports de forma segura.

Advanced Shell o Device Console?

En Sophos Firewall hay dos áreas de consola diferentes que a menudo se confunden:

• Device Console: CLI de Sophos para comandos específicos del firewall, por ejemplo prioridad de enrutamiento, rutas IPsec u opciones del sistema.
• Advanced Shell: shell cercana a Linux para el sistema de archivos, los logs y comandos de solo lectura como tail, grep, less y service -S.

No todos los comandos funcionan en ambas áreas. /log, tail -f, grep y service -S corresponden a Advanced Shell. Los comandos documentados system diagnostics ... para límites de CTR, purga de logs y depuración de subsistemas corresponden a Device Console.

Esta distinción es importante porque muchos errores solo ocurren porque un comando correcto se ingresa en el lugar incorrecto.

El registro debe estar activo

No toda la información esperada aparece automáticamente.

• En las reglas de firewall, Log firewall traffic debe estar activo.
• En las reglas de inspección SSL/TLS, el registro debe estar activado.
• En System services > Log settings debe definirse qué tipos de registro se envían localmente, a Sophos Fusion o a Syslog.

Para almacenamiento a largo plazo, un servidor Syslog o Sophos Central Firewall Reporting son útiles. Cómo conectar servidores de registro externos o un SIEM se describe en Enviar Syslog de Sophos Firewall a SIEM. Para Sophos Fusion, Activar Central Firewall Reporting es el procedimiento adecuado.

Activar depuración solo de manera dirigida

El registro de depuración genera muchos más datos, consume espacio y puede capturar contenido confidencial. Por eso no es un primer paso razonable. Primero se fijan el log normal, el intervalo temporal y la prueba reproducible; la depuración se usa solo para el subsistema afectado y durante el tiempo imprescindible.

Sophos documenta dos métodos distintos. La forma de Advanced Shell service <service>:debug -ds nosync conmuta el estado y no admite un argumento separado on u off. Para un subsistema de servicio compatible deben preferirse los comandos explícitos de Device Console documentados por Sophos: system diagnostics subsystems <subsystem> debug on, reproducir el problema y recopilar los datos, y después ejecutar system diagnostics subsystems <subsystem> debug off. Por ejemplo, el nombre de subsistema para la depuración de Packet Capture es Pktcapd. La depuración está desactivada de forma predeterminada, pero antes de cambiarla hay que confirmar que ningún otro administrador ni Sophos Support esté recopilando datos. Registrar el cambio y comprobar al final que la depuración está desactivada.

Tratar la depuración del controlador del sistema CSC como un conmutador independiente

SFOS 22 documenta un comando de Device Console independiente para el controlador del sistema (CSC):

system diagnostics subsystems CSC debug

A diferencia de la sintaxis del subsistema de servicio anterior, este comando no tiene argumento on ni off: cada ejecución conmuta la depuración CSC. Debe tratarse como un cambio controlado, no como una consulta de estado:

1. Comprobación previa: Confirmar con los demás administradores y Sophos Support que la depuración CSC no esté ya activa ni forme parte de una recopilación en curso. Registrar firewall o nodo HA, hora, motivo y ventana de recopilación prevista. Conservar una copia de referencia del log CSC relevante antes del cambio. No ejecutar el conmutador solo para averiguar su estado.
2. Activar y reproducir: Ejecutar el comando exactamente una vez en Device Console. Reproducir únicamente el problema delimitado y anotar la hora de prueba con zona horaria.
3. Conservar las pruebas: Antes del rollback, descargar el log de troubleshooting individual relevante o generar el CTR y descargar el archivo CTR completado. Restringir el acceso al CTR cifrado y a cualquier archivo de logs porque pueden contener datos confidenciales; no purgar ni sobrescribir las pruebas necesarias para el caso.
4. Desactivar / rollback: Volver a Device Console y ejecutar exactamente una vez el mismo comando. Esta segunda ejecución planificada vuelve a desactivar la depuración CSC.
5. Verificar: Realizar una prueba controlada breve y confirmar en las nuevas líneas del log CSC que ha cesado la salida de nivel debug y que el crecimiento del log ha vuelto a su ritmo normal. Registrar la hora y el resultado del rollback. Si el estado inicial o la comprobación posterior son ambiguos, no repetir el conmutador; detenerse y coordinar el estado con Sophos Support.

⚠️ Depuración WAF y reverseproxy.log: Sophos corrigió con SFOS 22.0 MR2 Build 546 el error NC-177457, por el que una contraseña era visible en reverseproxy.log cuando la depuración WAF estaba activada. Sophos no indica ni el inicio del intervalo de versiones afectadas ni el tipo de contraseña. Por eso, los logs de depuración WAF, archivos de troubleshooting y ficheros CTR ya generados en builds anteriores o desconocidos deben tratarse como si pudieran contener credenciales.

Si se encuentra una credencial en texto claro: limitar el acceso, documentar el incidente y rotar la credencial afectada. No eliminar los logs de forma indiscriminada antes de aclarar los requisitos de soporte, análisis forense y conservación.

El tema del registro de depuración y los comandos básicos de CLI se describen con más detalle en el artículo Solución de problemas de CLI de Sophos Firewall: comandos importantes. Para reiniciar servicios individuales, también es útil Reiniciar servicios de Sophos Firewall de manera segura.

Errores típicos en la búsqueda de registros

Muchos análisis de registros no se alargan por falta de datos, sino porque se busca demasiado pronto en la herramienta incorrecta.

• Activar Debug directamente: primero revisar Log Viewer, log adecuado y prueba reproducible.
• Buscar solo mensajes de error: además delimitar Source, Destination, User, Rule ID, NAT Rule ID y hora.
• Ignorar Packet Capture: si no está claro si los paquetes llegan o continúan, usar Packet Capture pronto.
• Entender Central Reporting como depuración en tiempo real: usar Central Reporting para el historial y los informes, y los registros locales para el análisis detallado.
• Asegurar logs de soporte días después: asegurar logs, hora y pasos de reproducción mientras el evento aún es rastreable.
• Dejar Debug activo tras la prueba: desactivar Debug de nuevo y controlar espacio de almacenamiento.

Un buen caso de solución de problemas siempre tiene tres cosas: una prueba estrecha, la fuente de registro adecuada y una hora documentada. Sin esta base, se pueden ver muchas líneas de registro, pero no necesariamente la causa.

Archivos de registro por área funcional

Las siguientes listas sirven como referencia. Lo mejor es seleccionar primero el área funcional afectada y después revisar el log adecuado con una ventana temporal estrecha.

Las asignaciones principales tienen en cuenta SFOS 22.0 y 23.0; los archivos de OAuth SSO difieren entre estas versiones, como se indica más abajo. En instalaciones anteriores o en archivos antiguos de soporte también pueden aparecer los nombres utilizados anteriormente: app-feedback.log, sig_update.log, sessiontbl.log, webproxy.log, fqdndebug.log, ipsec_Test_Connect.log, redis, hotspot.log, awarrenmta_debug.log, smbnetfs.log, snireport.log, confdbstatus.log y crreportdb.log. Sophos no los incluye en las listas de logs de SFOS 22/23 consideradas aquí; por tanto, no debe darse por hecho que existen en una build actual.

Los logs generales del sistema y de configuración se revisan además de los del módulo correspondiente. Un archivo puede servir para varias funciones: lo decisivo es su significado en el contexto del fallo concreto, no solo el nombre del servicio.

Sistema, gestión y servicios básicos

• Inicio del sistema: sysinit.log; revisarlo primero ante problemas de arranque y de Failsafe.
• Mensajes del sistema a nivel de kernel: syslog.log; comprobar también la hora, los reinicios y los eventos de interfaces. Comparar además en Log Viewer los eventos del sistema y los iniciados por administradores.
• Servidor web Apache para WebAdmin y User Portal: apache.log, apache_access.log y error_log.log; comprobar también Device Access y Local Service ACL.
• Aplicación de WebAdmin y User Portal: servidor de aplicaciones web Jetty, archivo de log tomcat.log; comprobar también errores de la GUI, carga elevada y estado del servicio. El nombre del archivo no es el nombre del servidor de aplicaciones web actual.
• SSH: sshd.log; comprobar también Device Access, la red de origen y el inicio de sesión con clave pública.
• Errores de GUI/CLI: error_log.log; comprobar también el cambio reciente, el navegador y la acción del administrador.
• Cambios de configuración: applog.log, csc.log; comprobar también Audit Trail y Config Studio.
• Base de datos de configuración: postgres.log; comprobar también el espacio de almacenamiento, las operaciones de backup/restore y el caso de soporte.
• Canal de comunicación entre determinados componentes y sus servicios: garner.log; para Central Management y Reporting, comprobar también las entradas de los plugins correspondientes.
• API: apiparser.log; comprobar también validation.log, la ACL de la API, el token y Central Task Queue.
• Validación: validation.log, validationError.log; comprobar también objetos o importaciones con errores.
• Licencias: licensing.log; comprobar también el estado de la licencia, Central Sync y el caso especial de Air Gap.
• Actualizaciones del sistema: u2d.log; comprobar también el estado de los patrones, DNS/HTTPS y el espacio de almacenamiento.

En problemas de gestión no se debe revisar solo el log de WebAdmin. Muy a menudo Device Access, una Local Service ACL Exception Rule o una red de origen incorrecta deciden si WebAdmin, SSH, User Portal, VPN Portal, DNS o SNMP son accesibles. Para esta parte, Asegurar el acceso a Sophos Firewall: Configurar correctamente el Device Access es el mejor punto de entrada.

Firewall, NAT y Packet Capture

• Coincidencia con reglas de firewall: firewall_rule.log; comprobar también el módulo Firewall de Log Viewer.
• Logs de firewall relativos a conexiones: fwlog.log; su generación depende del registro habilitado en la regla de firewall y de Log settings. Utilizar también Packet Capture.
• Reglas NAT: nat_rule.log; comprobar también NAT Rule ID en Log Viewer.
• DNAT con Link Load Balancing: comprobar también dgd.log cuando intervenga la selección de gateway o enlace.
• Packet Capture en WebAdmin: pktcapd.log; comprobar también Diagnostics > Packet capture.
• Gestión del ancho de banda / QoS: bwm.log; comprobar también Traffic Shaping Policy.
• Virtual Host / publicación de servidores antigua: vhost.log; comprobar también NAT y WAF.
• Web Server Protection / WAF: reverseproxy.log; algunos detalles de configuración de WAF también aparecen en firewall_rule.log. Comprobar la regla WAF, Hosted address y la conectividad con el backend.

NAT no se limita a nat_rule.log: la configuración NAT de una conexión IPsec de sitio a sitio se comprueba en charon.log, y un comando NAT ejecutado mediante la CLI, en applog.log. Así se puede distinguir una configuración de túnel de una regla NAT normal.

En problemas de DNAT, siempre verificar la regla de firewall y la regla NAT juntas. NAT solo traduce, pero no permite tráfico. Más información: Entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Sophos Firewall utiliza, entre otros, IP tables, ARP table, IPset y conntrack para conexiones de firewall. Para QoS o gestión de ancho de banda se utiliza IMQ. Esta información es útil cuando se ven mensajes de registro o salidas de soporte con términos técnicos del camino de red de Linux.

IPS, Application Control e Inspección TLS

• Intrusion Prevention: servicio ips, registro ips.log.
• Application Control: servicio ips / Application Filter, registro ips.log.
• DPI y TLS Inspection: motor DPI, registro ips.log.
• Antivirus en la ruta de red: servicio avd, registro avd.log.
• Zero-Day Protection / Sandbox: servicio Sandbox, registro sandboxd.log.
• Active Threat Response / X-Ops Threat Feeds: ATR en la ruta de red; primero Log Viewer, según módulo además ips.log.
• MDR Threat Feeds: ATR / estado del feed MDR, registro atr.log; la guía operativa correlaciona Audit ID, Task Queue y la prueba de tráfico local.
• Actualizaciones de firmas: actualizador de firmas, registro sig_upgrade.log.
• Migración de firmas: migración de firmas, registro sigmigration.log.

appcached.log también contiene la caché temporal de aplicaciones categorizadas antes de su almacenamiento en la base de datos; su uso para Application Based Routing se detalla más abajo. En el caso de MDR y de los feeds de amenazas de terceros, atr.log muestra el estado de la licencia y de la configuración, no únicamente una decisión sobre el tráfico. Para los IoC de direcciones IP, también se revisa firewall_rule.log. Para los IoC de dominios o URL, deben analizarse conjuntamente los logs de firewall, DNS, inspección SSL/TLS y proxy web: firewall_rule.log, dnsd.log, ips.log, httplogd.log y, según la ruta de procesamiento, awarrenhttp.log. Los módulos implicados implementan Active Threat Response en función del tipo de IoC.

Muchas funciones de protección modernas solo ven suficientes detalles cuando HTTPS se descifra. Si la inspección TLS no se aplica, los filtros web, el control de aplicaciones, IPS y el escaneo de malware son menos significativos según el tráfico.

Si no está claro si IPS está activo, qué política se aplica o por qué una firma bloquea, primero ayuda Configurar y probar Sophos Firewall IPS de manera segura. Luego se pueden combinar ips.log, Log Viewer y Packet Capture de manera más dirigida.

Si se trata de reconocimiento de aplicaciones, filtro de aplicaciones o bloqueos inesperados de control de aplicaciones, primero se debe usar Configurar y probar Sophos Firewall Application Control.

Para Zero-Day Protection conviene comprobar además si Web Protection, TLS Inspection, el tipo y el tamaño del archivo, la política y la acción encajan. El artículo operativo adecuado es Comprender y operar Sophos Firewall Zero-Day Protection. Para Threat Feeds encaja Configurar y operar Sophos Firewall Threat Feeds de forma segura. Más sobre TLS Inspection: Implementar inspección TLS en Sophos Firewall paso a paso.

Web, Proxy, WAF y filtro web

• HTTP y HTTPS a través del proxy web: servicio awarrenhttp, archivo de log awarrenhttp.log.
• Acceso al proxy HTTPS: log de acceso de awarrenhttp, archivo de log awarrenhttp_access.log. En SFOS 22/23, las solicitudes individuales al proxy web solo aparecen aquí si awarrenhttp se ejecuta con Debug activado; seguir el procedimiento de captura indicado más abajo.
• Categorización web / reputación: servicio nSXLd, archivo de log nSXLd.log.
• Actualizaciones de categorías (SFOS 22/23): archivo de log catUpdateLog; respetar las mayúsculas y minúsculas, sin extensión .log.
• FTP a través del proxy HTTP: servicio skein, archivo de log skein.log.
• Proxy FTP: servicio ftpproxy, archivo de log ftpproxy.log.
• Web Application Firewall: proxy inverso, archivo de log reverseproxy.log.

Para recopilar este registro de acceso, primero identificar el nodo de firewall/HA afectado, el caso de prueba, la hora y un intervalo breve de recopilación, comprobar el espacio en disco y confirmar con otros administradores o soporte que el debug está desactivado. No utilizar el comando de conmutación para consultar el estado. Después, ejecutar service awarrenhttp:debug -ds nosync exactamente una vez en Advanced Shell, reproducir el problema delimitado y guardar awarrenhttp_access.log de forma protegida. A continuación, ejecutar el mismo comando exactamente una vez para volver a desactivar el debug. Con una prueba breve y controlada, comprobar que no se generan nuevas entradas de debug y que el registro normal vuelve a crecer a su ritmo habitual; documentar la reversión y la comprobación del espacio en disco. Si el estado inicial o la comprobación posterior no están claros, no seguir conmutando y aclararlo con soporte. Este método se aplica aquí a awarrenhttp en SFOS 22/23, no de forma general a todos los servicios o versiones.

Ante un posible bucle de proxy, block_proxy_loop junto con el debug de awarrenhttp activado brevemente puede generar Duplicate Via header values, proxy loop. Comprobar de forma segura los ajustes HTTP Proxy explica el requisito, el efecto global y la reversión segura. El debug solo permanece activo durante la prueba reproducible.

Si el tráfico web aparece como bloqueado en el Log Viewer, la causa puede estar en varios módulos: política web, inspección SSL/TLS, control de aplicaciones, IPS o WAF. Por lo tanto, siempre seleccione el módulo específico en el Log Viewer y verifique además el archivo de registro adecuado.

Sophos bloquea siempre los sitios web de la categoría highly objectionable criminal activity y oculta el nombre de dominio en los logs y los informes. No se trata de una acción predeterminada que pueda elegirse libremente. Por tanto, si una entrada de esta categoría parece anonimizada de forma deliberada, puede ser intencionado.

Para categorías web, grupos de URL, políticas web y alertas instantáneas, consulte Usar categorías web y alertas instantáneas en Sophos Firewall.

VPN

• IPsec desde SFOS v17+: servicios strongswan, charon; registros strongswan.log, charon.log.
• IPsec específico de conexión: una IPsec Connection concreta, log /log/ipsec_conn/ipsec_<connectionname>.log.
• IPsec en versiones anteriores: servicio IPsec, registro ipsec.log.
• IPsec Monitoring: IPsec Monitor, log ipsec_monitor.log.
• XFRM / VPN basada en rutas: servicio xfrmi, registro xfrmi.log.
• SSL VPN: SSL VPN / OpenVPN, log sslvpn.log.
• SSL VPN Status: OpenVPN Status, log openvpn-status*.log.
• VPN Portal: log vpnportal.log.
• L2TP: servicio l2tpd, registro l2tpd.log. L2TP Remote Access en Sophos Firewall explica la configuración y el diagnóstico.
• PPTP: PPTP VPN, log pptpvpn.log.
• Certificados VPN: servicios de certificados VPN, registro vpncertificate.log.
• Clientless SSL VPN: Clientless Access, log clientless_access.log.

Sophos Firewall utiliza strongSwan para IPsec VPN y OpenVPN para SSL VPN. En problemas de IPsec, son cruciales la hora, IP del par, propuesta, subredes locales/remotas, NAT-T, enrutamiento y reglas de firewall.

Estas implementaciones se aplican tanto a las conexiones de sitio a sitio como al acceso remoto. /log/ipsec_conn/ipsec_<connectionname>.log contiene, en particular, las acciones de WebAdmin específicas de la conexión para activar, desactivar y conectar el túnel; <connectionname> se sustituye por el nombre real de la conexión. Para la autenticación de usuarios VPN, comprobar también access_server.log y, en caso de problemas con el portal, vpnportal.log. Ante problemas con el cliente Sophos Connect, el informe de soporte técnico del cliente también forma parte de la recopilación de evidencias: los logs del firewall por sí solos no muestran todo el estado del cliente. El procedimiento de solución de problemas de IPsec ayuda a correlacionar los resultados del cliente y del firewall.

Para problemas de IPsec, el artículo Solución de problemas de IPsec en Sophos Firewall es la mejor guía paso a paso. Si se trata de VPN basado en rutas y rutas IPsec manuales, ayuda Crear ruta IPsec en Sophos Firewall.

Autenticación, User Portal y SSO

• Autenticación, autorización y contabilidad de usuarios: Access Server / AAA, archivo de log access_server.log.
• NTLM / NASM: servicio nasm, archivo de log nasm.log.
• Chromebook SSO: backend de Chromebook SSO, archivo de log chromebook-sso-backend.log.
• Proceso de Chromebook SSO: csd.log; distinguirlo del log del backend.
• OAuth SSO Captive Portal (SFOS 22): archivo de log oauth_sso_captive.log.
• OAuth SSO WebAdmin (SFOS 22): archivo de log oauth_sso_webadmin.log.
• OAuth SSO VPN (SFOS 22): archivo de log oauth_sso_vpn.log.
• OAuth SSO (SFOS 23): oauth_sso_svc.log para los inicios de sesión SSO en WebAdmin, Captive Portal, VPN Portal, IPsec VPN y SSL VPN.
• RADIUS SSO: asignación de usuarios a IP mediante Accounting en access_server.log. La configuración y la validación se explican en RADIUS SSO con Accounting.
• STAS: contexto de STAS / Access Server, según el contexto del servicio y access_server.log.

En reglas de usuario, siempre hay que comprobar primero si el usuario es conocido. Si Match known users está activo y la autenticación no funciona, la regla no coincide. Para los logins clásicos en el navegador, Configurar y probar Captive Portal en Sophos Firewall combina Device Access, la regla de usuario, Live users, Log Viewer y access_server.log en un procedimiento de diagnóstico completo.

Si todavía no está claro si falla la selección del servicio, la identidad, la Main Group, la cuota o solo el posterior recorrido del tráfico, Solucionar sistemáticamente los errores de autenticación en Sophos Firewall reúne estas capas en un único procedimiento de diagnóstico.

Si se utiliza el portal cautivo con Microsoft Entra ID SSO, Configurar Microsoft Entra ID SSO para el portal cautivo de Sophos Firewall ayuda a verificar oauth_sso_captive.log (SFOS 22; en SFOS 23: oauth_sso_svc.log), Device Access, grupos y coincidencia de reglas posterior.

DNS, DHCP y red

• Servicio DNS: servicio dnsd, archivo de log dnsd.log.
• Servicio de FQDN con comodines / DNS Grabber: servicio dnsgrabber, archivo de log dnsgrabber.log.
• DNS Entity / otros componentes DNS: servicios entity, eacd; archivos de log entity.log, eacd.log.
• DHCP IPv4: servicio dhcpd, archivo de log dhcpd.log.
• DHCP IPv6: archivo de log dhcpd6.log.
• Interfaces físicas y virtuales: servicio networkd, archivo de log networkd.log.
• Hosts FQDN: servicio fqdnd, archivo de log fqdnd.log.
• Dead Gateway Detection y gestión de WAN/gateways: servicio dgd, archivo de log dgd.log; comprobar también la conmutación por error de enlaces y VPN, así como DNAT.
• DNS dinámico: cliente de DNS dinámico, archivo de log ddc.log.
• Cliente NTP: archivo de log ntpclient.log.
• Anuncios de router IPv6: servicio radvd, archivo de log radvd.log.

Los problemas de DNS y DHCP a menudo parecen problemas de firewall. Por lo tanto, primero se deben verificar la dirección IP, la puerta de enlace, el servidor DNS y si los clientes deben usar el firewall como servidor DNS o DHCP.

Si los dominios internos no se resuelven correctamente, generalmente es relevante Configurar rutas de solicitud DNS en Sophos Firewall. Para opciones especiales de DHCP, hay un artículo propio Configurar opciones DHCP en Sophos Firewall.

WAN celular

• WWAN / módem USB: revisar conexión y desconexión de dispositivos USB en modemd.log.
• Configuración de red del módem: revisar interfaces relacionadas con el módem y configuración IP en networkd.log.
• USB, módem y PPP: revisar mensajes de Syslog sobre USB, módem y Point-to-Point Protocol en syslog.log.

En problemas de WAN celular, también se debe verificar si se reconoce el módem, si PIN/SIM/APN son correctos y si el firewall crea una puerta de enlace adecuada.

Enrutamiento

• Rutas unicast estáticas: archivo de log staticd.log. La configuración y la comprobación se explican en Configurar una ruta estática en Sophos Firewall.
• Instalación de rutas unicast IPv4 estáticas: servicio zebra, archivo de log zebra.log.
• Enrutamiento basado en aplicaciones: servicio appcached, archivo de log appcached.log.
• Enrutamiento multicast: archivo de log mrouting.log.
• BGP y BGP-IPv6: servicio bgpd, archivo de log bgpd.log. La configuración y la validación se explican en Configurar BGP en Sophos Firewall; zebra.log también ayuda a comprobar si una ruta dinámica IPv4 o IPv6 aprendida se ha instalado en el kernel.
• OSPFv2 y OSPFv3: servicios ospfd y ospf6d, archivos de log ospfd.log y ospf6d.log. zebra.log también muestra si la ruta dinámica se ha incorporado al sistema. La configuración y la validación se explican en Configurar OSPF en Sophos Firewall.
• RIP: servicio ripd, archivo de log ripd.log. La configuración y la validación se explican en Configurar RIPv2 en Sophos Firewall; zebra.log también muestra si una ruta aprendida se ha instalado en la pila de enrutamiento.
• PIM-SM: servicio pimd, archivo de log pimd.log. La configuración y la validación se explican en Configurar PIM-SM en Sophos Firewall.

En problemas de enrutamiento, también verifique Routing > SD-WAN routes, puertas de enlace y Packet Capture. El Policy tester no reemplaza una prueba de enrutamiento real.

Para las rutas estáticas y dinámicas, csc.log aporta además información sobre códigos de operación e indicios de reinicios de servicios. En el contexto de HA, se añaden ha.log, msync.log y applog.log. Para las rutas SD-WAN, además de appcached.log, se revisan applog.log, csc.log y dgd.log; si interviene IPsec, también se consultan los logs de IPsec.

Más información: Ajustar prioridad de enrutamiento en Sophos Firewall.

GUI, CLI y acceso al sistema

Para WebAdmin, SSH, API y servicios locales de gestión, la lista básica está más arriba en Sistema, gestión y servicios básicos. Si WebAdmin o SSH no son accesibles, no se deben revisar solo apache.log, tomcat.log o sshd.log. El acceso local se controla mediante Administration > Device access y Local Service ACL.

Más información: Establecer conexión SSH con Sophos Firewall.

Sophos Fusion, Heartbeat y Central Management

• Sophos Central Management: Central Management, archivos de log centralmanagement.log, sophos-central.log.
• CSC y servicios auxiliares: servicios csc, cschelper, csd; archivos de log csc.log, cschelper.log, csd.log. cschelper.log corresponde a los correos electrónicos generados por el sistema y a las herramientas de autenticación; csd.log, al proceso de Chromebook SSO.
• Security Heartbeat y Synchronized Security: heartbeatd.log contiene el estado de los endpoints y la información de aplicaciones enviados al firewall; hbtrust.log, la comunicación con Central. Los servicios se llaman heartbeatd y hbtrust; comprobar también csc.log y applog.log.
• Synchronized Application Control: comprobar en sac-feedback.log los datos enviados a SophosLabs.
• Optimización de la base de datos de SAC (SFOS 22/23): sac-vacuum.log registra la optimización semanal de la base de datos de Synchronized Application Control; sac-feedback.log sigue siendo el log independiente para los datos enviados a SophosLabs.
• Eventos de Central, conexión y transferencia de configuración: fwcm-eventd.log muestra la información de zonas/interfaces enviada para objetos dinámicos; fwcm-heartbeatd.log, la conexión; y fwcm-updaterd.log, la configuración transferida. Los servicios se llaman fwcm-eventd, fwcm-heartbeatd y fwcm-updaterd; no todos ellos son servicios de Heartbeat.
• Central API Executor: servicio fwcm-api-executor, archivo de log fwcm-api-executor.log.
• Active Threat Response: contexto de ATR; comprobar según la versión y el módulo.

En caso de problemas con Sophos Fusion, primero verifique si el firewall está registrado, si los servicios de Central están activos y si DNS/HTTPS saliente funciona. Si una modificación de Sophos Fusion no llega localmente, se debe comparar la Sophos Fusion Firewall Task Queue con los registros locales. Un estado verde en Sophos Fusion no demuestra por sí solo que una política concreta se haya procesado localmente.

Para el registro y los tokens de acceso, el archivo relevante es sophos-central.log; para la gestión y los informes habilitados, centralmanagement.log. El registro y la cancelación del registro también se contrastan con applog.log, y las actualizaciones de firmware, con csc.log. hbtrust.log muestra la comunicación; en garner.log, las entradas del plugin SCM corresponden a Central Management y las del plugin CR, a Central Reporting. fwcm-api-executor.log también contiene análisis de MDR transferidos al firewall. La documentación de SFOS 22 considerada denomina a la plataforma Sophos Fusion (antes Sophos Central), mientras que la documentación de SFOS 23 la denomina Sophos Central; los nombres existentes de servicios y archivos no cambian.

Alta disponibilidad

• Estado y configuración de HA: log de la aplicación HA, archivo de log applog.log.
• Detección del nodo par de HA en QuickHA: servicio ha_pair, archivo de log ha_pair.log.
• Túnel SSH entre dispositivos HA a través del enlace dedicado: servicio ha_tunnel, archivo de log ha_tunnel.log.
• Sincronización de conntrack: servicio ctsyncd, archivo de log ctsyncd.log.
• Msync: servicio msync, archivo de log msync.log.
• Establecimiento de HA y cambios de estado: ha.log.
• Sincronización de archivos de determinados servicios con el dispositivo auxiliar: filesync.log.

Los logs e informes HA no se sincronizan entre los dispositivos. Cada nodo almacena solo los datos del tráfico que ha procesado él mismo. Por tanto, Log Viewer y Diagnostics > Tools > Troubleshooting logs se revisan en cada dispositivo afectado. Para obtener los troubleshooting logs del dispositivo Auxiliary, hay que iniciar sesión directamente en su CLI mediante la dirección IP o FQDN de su interfaz de administración. Sophos Central Firewall Reporting puede combinar informes de ambos dispositivos, pero no sustituye los archivos de troubleshooting locales de cada nodo.

Correo y anti-spam

• Antivirus: servicio AV, archivo de log avd.log.
• Actualizaciones de antivirus: Up2Date AV, archivo de log up2date_av.log.
• Antispam: servicio sasi, archivo de log sasi.log.
• Sandbox: servicio sandboxd, archivo de log sandboxd.log.
• SMTP MTA: servicio smtpd, archivo de log smtpd_main.log.
• Errores SMTP en modo MTA: smtpd_error.log para errores de análisis de correo, smtpd_panic.log para errores internos y smtpd_reject.log para correos rechazados; el servicio es smtpd.
• Proxy SMTP/S heredado: servicios awarrensmtp, awarrenmta; archivos de log awarrensmtp.log, awarrenmta.log. La configuración y la prueba de extremo a extremo se explican en Mail Protection en modo Legacy.
• Proxy POP/IMAP: servicio warren, archivo de log warren.log. La configuración y la prueba de extremo a extremo se explican en Analizar POP3 e IMAP en Sophos Firewall.

En problemas de correo, siempre verifique si el modo MTA, la regla de firewall, DNS, certificados y restricciones del proveedor son compatibles. El procedimiento para el flujo de correo, spool, cuarentena y relay se describe en Configurar protección de correo en modo MTA en Sophos Firewall.

Sophos Firewall utiliza Avira y Sophos Antivirus. El servicio anti-spam solo se inicia si hay una política de spam entrante o saliente. Esta dependencia es importante si sasi.log permanece vacío o el servicio anti-spam no se ejecuta.

Inalámbrico, RED, Hotspot y otros servicios

• Controlador inalámbrico y comunicación de AP/APX con el firewall: servicio awed, archivo de log awed.log.
• Clientes inalámbricos: comunicación entre el cliente y el AP/APX en wc_remote.log.
• SSID de LocalWifi: servicio hostapd, archivo de log hostapd.log; no confundir con los eventos de hotspot.
• Eventos de hotspot: servicio hotspotd, archivo de log hotspotd.log.
• RED: red.log registra todos los dispositivos RED configurados, incluidos Site-to-Site RED y SD-RED. red-<serial ID of RED>.log corresponde al dispositivo SD-RED respectivo, y red-<RED ID>.log, a la configuración de Site-to-Site RED correspondiente. La RED ID se encuentra en Network > Interfaces, al abrir el Site-to-Site RED correspondiente. Los marcadores de posición se sustituyen por su número de serie real o su RED ID, respectivamente.
• SNMP: servicio snmpd, archivo de log snmpd.log.
• Servicio Syslog: archivo de log syslog.log.
• Licencias: servicio de licencias, archivo de log licensing.log.
• Actualizaciones del sistema: servicio u2d, archivo de log u2d.log.
• VMware Tools: servicio vmtool, archivo de log vmtool.log.

En problemas de licencia, Air-Gap o patrones, licensing.log y u2d.log son los primeros puntos de referencia técnicos. Para el procedimiento operativo con archivo de licencia, ventana de 180 días y actualizaciones de patrones manuales, consulte Operar licencia y actualizaciones de patrones Air-Gap en Sophos Firewall.

Base de datos e informes

• Base de datos de configuración: Config DB, archivo de log postgres.log.
• Postgres: servicio postgres, archivo de log postgres.log.
• Base de datos de firmas: servicio sigdb, archivo de log sigdb.log.
• Base de datos de informes: nueva base de datos de informes a partir de SFOS 21.0, archivo de log reportdb.log.
• Base de datos de migración: migración de informes, archivo de log reportmigration.log.
• Migración de configuración (SFOS 22/23): archivo de log migration.log; no confundir con reportmigration.log, destinado a la migración de informes.
• Garner: servicio garner, archivo de log garner.log.
• Visualización de logs en WebAdmin: servicio iview, archivo de log iview.log.

Si faltan informes, son lentos o hay problemas de espacio de almacenamiento, los registros de informes y bases de datos son relevantes. Además, se debe verificar si los informes se almacenan localmente o se envían a Sophos Fusion.

Otros archivos de log para SFOS 22/23

Los siguientes archivos se necesitan con menos frecuencia en la solución de problemas de tráfico cotidiana, pero forman parte de la asignación de SFOS 22/23. Se agrupan por función para evitar deducir precipitadamente una causa a partir del nombre de un archivo:

• Auditoría, FIPS y acceso de soporte: configuration-audit.log registra el cambio de configuración, el administrador y el momento; fips.log, el inicio en modo FIPS; y uma.log, el acceso de soporte.
• Canalización de logs y mantenimiento local de datos: syslog-ng.log muestra la supresión de entradas consecutivas del mismo evento; reportdb_v9.log corresponde a la antigua base de datos de informes. dbcleanup.log corresponde a la limpieza de la base de datos al reiniciar el firewall; readobject.log, a la lectura interna de objetos; fstrim.log, al trimming del sistema de archivos; y logrotate.log, a la rotación a archivos .gz.
• ATR, NDR Essentials y FastPath: atr-service.log muestra el inicio y la finalización del servicio ATR. ndr.log abarca la licencia de NDR, la configuración y el inicio del agente; ndr_agent.log, el inicio del servicio y el procesamiento de metadatos. vfpdf.log muestra los metadatos enviados desde FastPath a NDR Essentials exclusivamente en XGS 88/88w, 108/108w, 118/118w y 128/128w. setup_vf_dpdk.log registra la inicialización de memoria de FastPath y, precisamente, no se aplica a estas cuatro series de modelos.
• TLS y SSL VPN: httplogd.log muestra las conexiones HTTPS no descifradas en la ruta DPI. peruser_cert_sslvpn.log registra los certificados SSL VPN generados específicamente para cada usuario; openvpn-status0.log, openvpn-status1.log y otros archivos numerados muestran las conexiones SSL VPN activas por proceso.
• Red y HA: dhcprelay.log corresponde a DHCP Relay. ha.log muestra el éxito o el fallo al establecer HA, así como los cambios de estado; filesync.log, la sincronización de archivos de determinados servicios con el dispositivo auxiliar.
• Central, despliegue y ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log y fwcm-updaterd.log abarcan la información de zonas/interfaces, la conexión y la transferencia de configuración. fwcm-frpcd.log corresponde a Fast Reverse Proxy al abrir varios firewalls simultáneamente en Central. ssod.log contiene información sobre actualizaciones de firmware enviada a Central y backups del firewall creados allí. Para True/Controlled Zero Touch, se revisan zt.log y fwcm-heartbeatd.log; para Zero Touch mediante USB, zerotouch.log, no fwcm-heartbeatd.log. ztna-connector.log contiene los ID de cuenta de cliente y de conector, el estado del conector, los túneles ZTNA, las aplicaciones a las que se ha accedido y las actualizaciones de configuración.
• Backup, firmware, Air Gap y certificados: interfacemapping.log registra la asignación de interfaces durante la restauración; legacyconversion.log, los backups sin Secure Storage Master Key; y fwmgmt.log, la instalación y gestión del firmware. u2d_airgap.log se aplica a las actualizaciones de Air Gap; cps_messages.log, a los errores de hotfix; y letsencrypt.log, junto con applog.log, a los certificados de Let’s Encrypt.
• API, restauración y gestión de certificados: apiparser.log corresponde a la traducción de la API entre JSON y XML; validation.log y validationError.log, a la validación de la API. Para backup/restore, comprobar también applog.log y postgres.log. vpncertificate.log no solo abarca certificados VPN, sino también CA, CSR y CRL.
• Hardware y estado del sistema: npu-startup.log muestra el inicio de la NPU; npu_syslog.log, los syslogs de la NPU; y xgs-host.log, los controladores del host durante el inicio. xgs-npu-fw.log corresponde a la comprobación de compatibilidad, la actualización y la recuperación de la NPU; xgs-npu-serial.log, al puerto serie de la NPU; y xgs-pport-wait.log, a la creación de interfaces físicas durante el inicio. xgs-healthmond.log abarca la utilización de CPU, la temperatura, la velocidad de los ventiladores y el puerto de gestión de la NPU. raid.log muestra el RAID por software, y lcd.log, la pantalla del hardware. En firewalls de hardware, virtuales, en la nube y de software, system-monitor/cpu_trigger.log y system-monitor/memory_trigger.log registran el estado del sistema cuando la carga de CPU o de memoria es elevada, respectivamente; ambos figuran en las listas de SFOS 22/23.
• Syslogs de FastPath: npu_syslog.log corresponde a FastPath basado en NPU y no se aplica a XGS 88/88w, 108/108w, 118/118w y 128/128w. syslog.log muestra la comunicación del host con FastPath basado en NPU y con Virtual FastPath. En VMware, además del log de VMware Tools vmtool.log, comprobar también syslog.log.
• Servicios de nube y plataforma: iaasd.log registra el aprovisionamiento de la configuración y la comprobación de licencias en Azure; waagent.log, el aprovisionamiento a nivel del sistema operativo y la supervisión del estado por el agente de aprovisionamiento de Azure; vmtool.log corresponde a VMware Tools.

La presencia de un archivo no demuestra un error en ese módulo. Primero se correlacionan la hora del evento, el node afectado, la plataforma, el estado del servicio y un síntoma reproducible; solo después se busca con un filtro limitado en el archivo adecuado.

Flujo de análisis

1. Anotar el problema con precisión: hora con zona horaria, cliente, destino, puerto, usuario, acción.
2. Decidir si se trata de tráfico, estado de servicio, cambio de configuración o sincronización con Central.
3. Filtrar en Log Viewer por Source IP, Destination IP, módulo y hora.
4. Verificar visibilidad de Firewall Rule ID, NAT Rule ID, usuario, gateway y Policy IDs.
5. Usar Packet Capture si el flujo de paquetes, ruta de retorno o vista NAT no están claros.
6. Revisar el log adecuado con tail -f, less o grep.
7. Reproducir el problema y documentar el momento exacto de prueba.
8. Si es necesario, activar Debug solo para el servicio afectado y solo brevemente.
9. Desactivar Debug de nuevo y comprobar espacio de almacenamiento.
10. Guardar logs mientras el error aún se haya reproducido recientemente.

Para casos de soporte, también se deben documentar todos los mensajes de error, pasos de reproducción y pasos de solución de problemas ya realizados. Esta información acelera significativamente los casos de soporte. El procedimiento adecuado se describe en Abrir un ticket de soporte de Sophos: Preparación y portal.

FAQ