Interpretar Live Connections en Sophos Firewall

Live Connections muestra qué conexiones están activas en Sophos Firewall. La vista permite saber rápidamente qué cliente, usuario o aplicación genera tráfico, qué interfaces intervienen y qué regla de firewall o NAT procesa la sesión. Para una conexión individual, Diagnostics > Connection list ofrece todavía más detalles técnicos.

Ambas vistas son instantáneas. No sustituyen ni a Log Viewer para las decisiones registradas ni a Packet Capture para el flujo real de paquetes. Sin embargo, combinadas correctamente ahorran mucho tiempo: primero se localiza la sesión activa y después, si hace falta, se revisan los logs y los paquetes.

Live Connections en siete pasos

1. Definir el flujo de prueba: Source IP, Destination IP, protocolo, Source Port si se conoce, Destination Port y hora exacta.
2. Generar una conexión nueva desde el cliente de prueba, por ejemplo HTTPS desde 192.0.2.25 hacia 198.51.100.50 mediante TCP 443.
3. Abrir Current activities > Live connections y agrupar por Source IP address.
4. Filtrar por 192.0.2.25 y abrir las conexiones individuales mediante Total.
5. Anotar Start time, In interface, Out interface, Source, Destination, puertos, Firewall Rule ID y NAT Rule ID.
6. En Diagnostics > Connection list > Display filter, filtrar el mismo flujo de la forma más estricta posible y comparar Translated source, Translated destination, Gateway ID, Policy IDs y RX/TX.
7. Si hay desviaciones, correlacionar el flujo en Log Viewer y Packet Capture antes de cambiar reglas, NAT o routing.

Las direcciones 192.0.2.25 y 198.51.100.50 pertenecen a redes de documentación. Para una prueba real deben sustituirse por las direcciones reales del cliente y del destino. TCP 443 solo es adecuado cuando se comprueba realmente una conexión HTTPS.

⚠️ Las vistas contienen direcciones IP internas, nombres de usuario, aplicaciones y relaciones de comunicación. Los filtros y las capturas de pantalla deben mantenerse restringidos, y los datos de soporte solo deben compartirse con destinatarios autorizados.

Diferenciar Live Connections y Connection List

Las dos vistas acceden al estado actual de las conexiones, pero están diseñadas para responder a preguntas distintas.

Live Connections para obtener una visión general

En Current activities > Live connections se agrupan las conexiones activas por:

• Application
• Source IP address
• Username

La vista muestra upload, download, uso medio del ancho de banda, características y número de sesiones. Así permite responder a preguntas como: ¿Qué cliente genera mucho tráfico ahora? ¿Qué aplicación está activa? ¿Qué usuario mantiene varias conexiones abiertas?

Los valores de transferencia mostrados abarcan el periodo desde que se estableció la conexión. Upstream bandwidth y Downstream bandwidth se calculan a partir de los bytes transferidos y de la duración acumulada de la conexión. Por tanto, no constituyen una prueba de línea segundo a segundo. Para medir el rendimiento es mejor utilizar iPerf3 correctamente con Sophos Firewall.

En Live Connections solo puede estar activo un filtro a la vez. La Source IP suele ser el punto de partida más claro. Username o Application resultan útiles cuando el cliente ya se ha autenticado correctamente o la aplicación ha sido identificada.

Connection List para la sesión individual

En Diagnostics > Connection list aparece una fila por cada conexión actual. Esta vista es más técnica y muestra, entre otros, los siguientes datos:

• In interface y Out interface
• Source y Destination con puertos
• Protocolo y Application
• Rule ID y NAT ID
• Usuario y User group
• Policy IDs de Web, Application, IPS, Traffic Shaping y Remote Access
• Gateway ID
• Translated source y Translated destination
• Expiry, RX/TX bytes y RX/TX packets
• Connection served by

El Display filter puede incluir varias características conocidas del flujo de prueba. De este modo, una lista extensa se reduce a un pequeño conjunto de sesiones coincidentes.

Lo que ninguna de las dos vistas demuestra

Una sesión visible demuestra que existe una entrada actual de seguimiento de conexiones. No demuestra automáticamente:

• que cada solicitud y cada respuesta se haya transferido por completo
• que el servidor de destino haya procesado correctamente la aplicación
• que un error anterior del mismo flujo siga disponible como historial
• que la regla de firewall o NAT seleccionada sea la correcta desde el punto de vista funcional
• que una entrada verde no contenga pérdida de paquetes, retransmisiones o un problema de MTU

Para consultar decisiones históricas se necesita logging. Para comprobar ingreso, egreso, respuestas y drops se necesita Packet Capture. Para la propia aplicación siguen siendo relevantes los logs del servidor, del cliente o del servicio SaaS.

Preparar un flujo de prueba controlado

Una prueba útil no empieza con una recarga cualquiera del navegador. Primero se define la quíntupla:

• Source IP
• Destination IP
• Protocolo
• Source Port
• Destination Port

El Source Port suele ser dinámico en las conexiones de cliente. Si todavía no se conoce, para el primer filtro bastan Source IP, Destination IP, protocolo y Destination Port. Después de localizar la entrada se puede tomar el Source Port concreto de la sesión.

También se definen los valores esperados:

• In interface y Out interface
• Firewall Rule ID y, si corresponde, NAT Rule ID
• Usuario o grupo de usuarios si la regla utiliza identidad
• Gateway o ruta SD-WAN
• Source y Destination esperados después de NAT
• Hora exacta de la prueba con zona horaria

Crear siempre una conexión nueva después de los cambios

Las sesiones existentes conservan el estado con el que se establecieron. En particular, las decisiones NAT no se vuelven a evaluar para cada paquete posterior. Después de modificar una regla, NAT, routing o SD-WAN, hay que cerrar la sesión de la aplicación y generar un flujo nuevo.

Una recarga del navegador puede seguir utilizando la misma conexión TCP, HTTP/2 o HTTP/3. Para una validación fiable sirve una ventana privada nueva, un proceso de cliente reiniciado u otra prueba controlada que abra con seguridad una conexión nueva. El método concreto debe adaptarse a la aplicación y no debe interrumpir accidentalmente una sesión de producción.

Utilizar Live Connections para localizar la primera entrada

1. Abrir Current activities > Live connections.
2. Elegir un Automatic refresh interval adecuado para la prueba o actualizar manualmente con Refresh.
3. Seleccionar Source IP address para un cliente conocido.
4. Abrir el filtro, seleccionar un modificador adecuado e introducir la Source IP.
5. Comprobar transfer, bandwidth y Total en la fila.
6. Hacer clic en el número de Total para abrir las conexiones individuales en una pestaña nueva.
7. Identificar el flujo correspondiente mediante Start time, interfaces, direcciones IP, puertos y Protocol.

Una solicitud DNS, ICMP o web muy breve puede haber desaparecido antes de que se actualice la página. En ese caso, configurar primero el filtro, preparar Refresh y volver a ejecutar la prueba exactamente una vez.

Interpretar correctamente Other applications y DNS

Other applications incluye aplicaciones no identificadas y tráfico generado por el sistema, como descargas de firmas, acceso a la consola o solicitudes DNS generadas por la propia firewall. No es automáticamente una clase de error.

DNS requiere una atención adicional: el tráfico entre un cliente interno y un servidor DNS externo está sujeto a reglas de firewall normales y aparece como DNS. El tráfico DNS generado por la firewall puede aparecer tanto en DNS como en Other applications.

Si una aplicación no se identifica y Security Heartbeat está activo, Connection List puede ofrecer la resolución de Application Information para endpoints conectados. Sin un Sophos Endpoint conectado o sin Heartbeat, puede seguir apareciendo No information available. Por tanto, un nombre desconocido no implica automáticamente tráfico malicioso.

Firewall Rule ID 0 depende del contexto

El tráfico generado por el sistema lleva Firewall Rule ID 0 en Live Connections porque las reglas de firewall normales no controlan este tráfico. El acceso a los servicios locales de la firewall se controla, entre otros mecanismos, mediante Administration > Device access y Local Service ACL. Device Access y Local Service ACL explica la configuración segura.

Este 0 no debe interpretarse fuera de contexto como una regla de drop implícita. Rule #0 en un log de firewall o en Packet Capture puede tener un contexto de diagnóstico distinto. Lo decisivo es la vista, Status, Reason y si se trata de tráfico del sistema o de tráfico de cliente reenviado.

Restringir Connection List a un flujo

1. Abrir Diagnostics > Connection list.
2. Seleccionar Display filter.
3. Configurar Network protocol como IPv4 o IPv6 de acuerdo con la prueba.
4. Introducir Source IP y Destination IP.
5. Añadir Packet type y Source Port o Destination Port si se conocen.
6. Introducir la Rule ID esperada cuando se busquen específicamente las sesiones activas de esa regla.
7. Aplicar el filtro con OK y comparar los resultados con la hora de la prueba.

Un resultado vacío no demuestra que la firewall bloquee el tráfico. La sesión puede haber terminado, el cliente puede utilizar otra dirección de destino obtenida mediante DNS o un CDN, NAT puede cambiar la dirección visible o la prueba puede haberse procesado en el otro nodo HA. Primero hay que comprobar el flujo y la dirección de observación, no ampliar la regla de firewall.

Leer juntos los campos más importantes

• Time: hora de inicio de la conexión. Debe coincidir con la prueba controlada.
• In interface / Out interface: muestran la ruta de entrada y salida utilizada por la sesión.
• Source / Destination / Ports: definen el flujo visible antes de interpretar los detalles.
• Rule ID: muestra la regla de firewall que permite la sesión.
• NAT ID: muestra la regla NAT implicada.
• Translated source / Translated destination: hacen visibles SNAT, MASQ, DNAT o PAT.
• Gateway ID: asigna la sesión a un gateway y es especialmente importante para cuestiones de WAN o SD-WAN.
• Username / User group: muestran si el contexto de usuario esperado está asociado a la sesión.
• Policy IDs: muestran la política Web, Application, IPS, Traffic Shaping o Remote Access asignada.
• Expiry: muestra después de cuántos segundos caduca una sesión inactiva.
• RX/TX bytes y packets: ayudan a reconocer si solo una dirección transmite datos o si ambas están activas.
• Connection served by: muestra qué firewall procesa la conexión en un entorno HA.

Rule ID y NAT ID siempre se leen junto con interfaces, direcciones y puertos. Una Rule ID esperada con una NAT ID inesperada indica un problema de coincidencia NAT. Si ambas ID son correctas, pero no lo son Out interface o Gateway, la siguiente comprobación corresponde a routing o SD-WAN. NAT en Sophos Firewall explica los fundamentos.

No sobrevalorar Related Connections

Al hacer clic en Connection ID pueden aparecer conexiones dependientes, por ejemplo con Web Proxy, FTP, SIP u otros protocolos que crean sesiones relacionadas. Si no existe ningún flujo dependiente, la vista queda vacía. Por tanto, una vista Related Connections vacía no demuestra un error.

Correlacionar la sesión activa, Log Viewer y Packet Capture

Las tres herramientas responden sucesivamente a tres preguntas distintas:

1. Live Connections o Connection List: ¿Qué sesión existe actualmente y qué ID, interfaces, direcciones, políticas y asignaciones de gateway contiene?
2. Log Viewer: ¿Qué decisión de firewall, NAT o seguridad se ha registrado?
3. Packet Capture: ¿Llegan los paquetes, se reenvían y regresan las respuestas?

Para realizar una comparación fiable:

1. Anotar la hora de la prueba y la quíntupla.
2. Anotar la sesión activa y Connection ID.
3. Documentar Rule ID, NAT ID, In/Out interface, Gateway y direcciones traducidas.
4. Filtrar Log Viewer por Source, Destination, port y hora.
5. Si falta la respuesta o la ruta no está clara, iniciar Packet Capture con un filtro BPF restringido.
6. Documentar el resultado antes de cambiar la configuración.

Si Live Connections muestra una sesión pero Log Viewer no contiene el evento de firewall correspondiente, primero hay que comprobar Log firewall traffic, Local reporting y los filtros. El procedimiento se explica en Log Viewer no muestra logs nuevos.

Device Console ofrece además system diagnostics utilities connections. La ayuda pública actual documenta la herramienta, pero no todas las opciones dependientes del build. Antes de utilizarla, comprobar la sintaxis disponible con ? y mantener la consulta en modo de solo lectura. Troubleshooting de CLI en Sophos Firewall explica el marco seguro de la CLI.

Síntomas habituales

La sesión esperada no aparece

Primero hay que comprobar si el flujo sigue activo y si Source, Destination y la versión IP son correctos. Con DNS, CDN, proxies, NAT o IPv6, la dirección de destino real puede diferir de la prevista. Generar una prueba nueva e iniciar Packet Capture en paralelo si no está claro si la firewall recibe paquetes.

Se muestra una Rule ID o NAT ID incorrecta

Puede que una regla más general situada más arriba sea la que coincida. Comparar el orden de firewall y NAT, zonas, Source, Destination, Service, User y Schedule. No mover varias reglas al mismo tiempo. Probar correctamente una regla de Sophos Firewall ofrece el procedimiento guiado.

Solo una dirección incrementa RX o TX

Esto puede indicar una ruta de retorno ausente, una traducción NAT incorrecta, un problema en el sistema de destino o la firewall local del servidor. Comprobar interfaces, direcciones traducidas y Gateway, y después buscar ambas direcciones en Packet Capture. Un contador por sí solo no demuestra la causa.

Los valores no cambian después de modificar la configuración

Probablemente se sigue observando la sesión existente. Cerrar correctamente la conexión del cliente, generar un flujo nuevo y volver a comprobar Start time y Connection ID. No utilizar un flush global de sesiones ni un reinicio de servicio como primera prueba habitual.

En HA falta la sesión o el log correspondiente

Anotar Connection served by y tener en cuenta el nodo que procesó el tráfico en el momento del evento. Los logs se guardan localmente en cada nodo HA y no se sincronizan por completo entre nodos. Una Connection List visible no permite deducir la continuidad de la sesión sin interrupciones. Configurar HA en Sophos Firewall explica estos límites.

Other applications es inusualmente grande

Primero agrupar por Source IP y abrir las sesiones individuales. Esta agrupación puede combinar aplicaciones no identificadas, tráfico del sistema y varias causas distintas. Comprobar Rule ID, destinos, puertos, usuario y contexto de la aplicación antes de considerarlo un incidente de seguridad.

Lista de comprobación

• Se conocen Source, Destination, protocolo, puertos y hora de la prueba.
• Se ha generado una conexión nueva para la prueba.
• Live Connections se ha agrupado de forma útil por Source IP, usuario o Application.
• Start time, In/Out interface, Rule ID y NAT ID coinciden con lo esperado.
• Translated source/destination y Gateway ID coinciden con la ruta planificada.
• User y Policy IDs solo se esperaban cuando la identificación correspondiente estaba activa.
• Rule ID 0 se ha interpretado en el contexto correcto de tráfico del sistema.
• En HA se ha documentado Connection served by.
• Log Viewer y, si ha sido necesario, Packet Capture confirman la sesión.
• No se ha utilizado un flush global de sesiones ni un reinicio de servicio como primer intento de diagnóstico.

Preguntas frecuentes