Bien interpréter Live Connections sur Sophos Firewall

Live Connections indique quelles connexions sont actuellement actives sur Sophos Firewall. Cette vue permet de déterminer rapidement quel client, utilisateur ou application génère du trafic, quelles interfaces sont impliquées et quelle règle de pare-feu ou de NAT traite la session. Pour une connexion précise, Diagnostics > Connection list fournit encore davantage de détails techniques.

Les deux vues sont des instantanés. Elles ne remplacent ni Log Viewer pour les décisions journalisées, ni Packet Capture pour le flux réel des paquets. Correctement combinées, elles font toutefois gagner beaucoup de temps : commencer par trouver la session active, puis contrôler les logs et les paquets si nécessaire.

Live Connections en sept étapes

1. Définir le flux de test : adresse IP source, adresse IP de destination, protocole, port source s’il est connu, port de destination et heure exacte.
2. Générer une nouvelle connexion depuis le client de test, par exemple une connexion HTTPS de 192.0.2.25 vers 198.51.100.50 sur TCP 443.
3. Ouvrir Current activities > Live connections et regrouper par Source IP address.
4. Filtrer sur 192.0.2.25 et ouvrir les différentes connexions via Total.
5. Noter Start time, In interface, Out interface, Source, Destination, les ports, Firewall Rule ID et NAT Rule ID.
6. Sous Diagnostics > Connection list > Display filter, filtrer le même flux aussi précisément que possible, puis comparer Translated source, Translated destination, Gateway ID, les Policy IDs et RX/TX.
7. En cas d’écart, recouper le flux dans Log Viewer et Packet Capture avant de modifier les règles, le NAT ou le routage.

Les adresses 192.0.2.25 et 198.51.100.50 appartiennent à des réseaux de documentation. Pour un test réel, elles doivent être remplacées par les adresses effectives du client et de la destination. TCP 443 ne convient que si une connexion HTTPS est réellement testée.

⚠️ Ces vues contiennent des adresses IP internes, des noms d’utilisateur, des applications et des relations de communication. Limiter les filtres et les captures d’écran au strict nécessaire et ne transmettre les données de support qu’aux destinataires autorisés.

Distinguer Live Connections et Connection List

Les deux vues accèdent à l’état actuel des connexions, mais elles répondent à des questions différentes.

Live Connections pour la vue d’ensemble

Sous Current activities > Live connections, les connexions actives peuvent être regroupées par :

• Application
• Source IP address
• Username

La vue affiche l’upload, le download, la bande passante moyenne utilisée, les propriétés et le nombre de sessions. Elle aide à répondre à des questions telles que : quel client génère beaucoup de trafic en ce moment ? Quelle application est active ? Quel utilisateur a plusieurs connexions ouvertes ?

Les valeurs de transfert affichées couvrent la période écoulée depuis l’établissement de la connexion. Upstream bandwidth et Downstream bandwidth sont calculées à partir des octets transférés et de la durée actuelle de la connexion. Elles ne constituent donc pas un test de ligne seconde par seconde. Pour un test de performance, mieux vaut utiliser correctement iPerf3 avec Sophos Firewall.

Un seul filtre peut être actif à la fois dans Live Connections. L’adresse IP source est généralement le point de départ le plus clair. Username ou Application sont utiles lorsque le client est déjà correctement authentifié ou que l’application a été identifiée.

Connection List pour une session précise

Sous Diagnostics > Connection list, chaque connexion actuelle apparaît sur une ligne distincte. Cette vue est plus technique et affiche notamment :

• In interface et Out interface
• Source et Destination avec les ports
• Protocol et Application
• Rule ID et NAT ID
• User et User group
• les Policy IDs Web, Application, IPS, Traffic Shaping et Remote Access
• Gateway ID
• Translated source et Translated destination
• Expiry, RX/TX bytes et RX/TX packets
• Connection served by

Le Display filter peut contenir plusieurs caractéristiques connues du flux de test. Une longue liste peut ainsi être réduite à quelques sessions correspondantes.

Ce qu’aucune des deux vues ne prouve

Une session visible prouve qu’une entrée actuelle de suivi de connexion existe. Elle ne prouve pas automatiquement :

• que chaque requête et chaque réponse ont été intégralement transmises
• que le serveur de destination a correctement traité l’application
• qu’une erreur antérieure du même flux est encore disponible dans l’historique
• que la règle de pare-feu ou de NAT sélectionnée est fonctionnellement la bonne
• qu’une entrée verte ne comporte aucune perte de paquets, retransmission ou erreur MTU

Les décisions historiques nécessitent des logs. L’entrée, la sortie, les réponses et les drops nécessitent Packet Capture. Pour l’application elle-même, les logs du serveur, du client ou du service SaaS restent pertinents.

Préparer un flux de test contrôlé

Un test exploitable ne commence pas par un simple rechargement aléatoire du navigateur. Il faut d’abord définir le quintuplet :

• adresse IP source
• adresse IP de destination
• protocole
• port source
• port de destination

Le port source est souvent dynamique pour les connexions clientes. S’il n’est pas encore connu, l’adresse IP source, l’adresse IP de destination, le protocole et le port de destination suffisent pour le premier filtre. Après avoir trouvé l’entrée, reprendre le port source précis dans la session.

Définir également les éléments attendus :

• In interface et Out interface
• Firewall Rule ID et, le cas échéant, NAT Rule ID
• utilisateur ou groupe d’utilisateurs si la règle utilise l’identité
• Gateway ou chemin SD-WAN
• Source et Destination attendues après le NAT
• heure exacte du test avec le fuseau horaire

Toujours créer une nouvelle connexion après une modification

Les sessions existantes conservent l’état établi lors de leur création. Les décisions NAT, en particulier, ne sont pas réévaluées pour chaque paquet suivant. Après une modification de règle, de NAT, de routage ou de SD-WAN, fermer la session applicative et générer un nouveau flux.

Un rechargement du navigateur peut continuer à utiliser la même connexion TCP, HTTP/2 ou HTTP/3. Une nouvelle fenêtre de navigation privée, un processus client redémarré ou un autre test contrôlé ouvrant avec certitude une nouvelle connexion permet une validation fiable. La méthode exacte doit être adaptée à l’application et ne pas interrompre involontairement une session de production.

Utiliser Live Connections pour trouver la première entrée

1. Ouvrir Current activities > Live connections.
2. Choisir un Automatic refresh interval adapté au test ou actualiser manuellement avec Refresh.
3. Pour un client connu, sélectionner Source IP address.
4. Ouvrir le filtre, choisir un modificateur approprié et saisir l’adresse IP source.
5. Contrôler Transfer, Bandwidth et Total sur la ligne.
6. Cliquer sur le nombre sous Total pour ouvrir les différentes connexions dans un nouvel onglet.
7. Identifier le flux correspondant à partir de Start time, des interfaces, des adresses IP, des ports et de Protocol.

Une requête DNS, ICMP ou Web très courte peut avoir disparu avant l’actualisation de la page. Dans ce cas, définir d’abord le filtre, préparer Refresh et déclencher le test une seule fois de plus.

Interpréter correctement Other applications et DNS

Other applications contient les applications non identifiées et le trafic généré par le système, par exemple les téléchargements de signatures, l’accès à la console ou les requêtes DNS générées par le pare-feu. Il ne s’agit pas automatiquement d’une catégorie d’erreur.

DNS nécessite une attention supplémentaire : le trafic entre un client interne et un serveur DNS externe est soumis aux règles de pare-feu normales et apparaît comme DNS. Le trafic DNS généré par le pare-feu lui-même peut, en revanche, apparaître à la fois sous DNS et sous Other applications.

Lorsqu’une application n’est pas identifiée et que Security Heartbeat est activé, Connection List peut proposer de résoudre Application Information pour les endpoints connectés. Sans Sophos Endpoint connecté ou sans Heartbeat, No information available reste possible. Un nom inconnu n’indique donc pas automatiquement un trafic malveillant.

Firewall Rule ID 0 dépend du contexte

Le trafic généré par le système porte la Firewall Rule ID 0 dans Live Connections, car les règles de pare-feu normales ne le contrôlent pas. L’accès aux services locaux du pare-feu est notamment contrôlé par Administration > Device access et la Local Service ACL. Device Access et Local Service ACL explique la configuration sécurisée.

Cette valeur 0 ne doit pas être interprétée hors contexte comme une règle de drop implicite. Rule #0 peut avoir une autre signification de diagnostic dans un log de pare-feu ou dans Packet Capture. Les éléments décisifs sont la vue utilisée, Status, Reason et la distinction entre trafic système et trafic client transféré.

Limiter Connection List à un seul flux

1. Ouvrir Diagnostics > Connection list.
2. Sélectionner Display filter.
3. Définir Network protocol sur IPv4 ou IPv6 selon le test.
4. Saisir l’adresse IP source et l’adresse IP de destination.
5. Ajouter Packet type ainsi que le port source ou de destination s’ils sont connus.
6. Saisir la Rule ID attendue si la recherche porte précisément sur les sessions actives de cette règle.
7. Appliquer le filtre avec OK et comparer les résultats avec l’heure du test.

Un résultat vide ne prouve pas que le pare-feu bloque le trafic. La session peut déjà être terminée, le client peut utiliser une autre adresse de destination obtenue par DNS ou via un CDN, le NAT peut modifier l’adresse visible ou le test peut avoir été traité par l’autre nœud HA. Contrôler d’abord le flux de test et le sens d’observation au lieu d’élargir la règle de pare-feu.

Lire ensemble les champs les plus importants

• Time: heure de début de la connexion. Elle doit correspondre au test contrôlé.
• In interface / Out interface: indiquent les chemins d’entrée et de sortie utilisés par la session.
• Source / Destination / Ports: définissent le flux visible avant l’interprétation détaillée.
• Rule ID: indique la règle de pare-feu qui autorise la session.
• NAT ID: indique la règle NAT impliquée.
• Translated source / Translated destination: rendent visibles SNAT, MASQ, DNAT ou PAT.
• Gateway ID: associe la session à une passerelle et joue un rôle particulièrement important pour les questions WAN ou SD-WAN.
• Username / User group: indiquent si le contexte utilisateur attendu est associé à la session.
• Policy IDs: indiquent les politiques Web, Application, IPS, Traffic Shaping ou Remote Access attribuées.
• Expiry: indique après combien de secondes une session inactive expire.
• RX/TX bytes et packets: aident à déterminer si une seule direction transporte des données ou si les deux sont actives.
• Connection served by: indique quel pare-feu traite la connexion dans un environnement HA.

Toujours lire Rule ID et NAT ID avec les interfaces, les adresses et les ports. Une Rule ID attendue avec une NAT ID inattendue indique un problème de correspondance NAT. Si les deux ID sont correctes, mais que Out interface ou Gateway ne le sont pas, il faut ensuite examiner le routage ou le SD-WAN. Le NAT sur Sophos Firewall en explique les principes.

Ne pas surinterpréter Related Connections

Un clic sur la Connection ID peut afficher les connexions dépendantes, par exemple avec Web Proxy, FTP, SIP ou d’autres protocoles qui créent des sessions liées. Si aucun flux dépendant n’existe, la vue reste vide. Une vue Related Connections vide ne constitue donc pas une preuve d’erreur.

Recouper la session active, Log Viewer et Packet Capture

Les trois outils répondent successivement à trois questions différentes :

1. Live Connections ou Connection List : quelle session existe actuellement et quelles ID, interfaces, adresses, politiques et associations de passerelle porte-t-elle ?
2. Log Viewer : quelle décision de pare-feu, de NAT ou de sécurité a été journalisée ?
3. Packet Capture : les paquets arrivent-ils, sont-ils transférés et les réponses reviennent-elles ?

Pour une comparaison fiable :

1. Noter l’heure du test et le quintuplet.
2. Noter la session active et la Connection ID.
3. Documenter Rule ID, NAT ID, In/Out interface, Gateway et les adresses traduites.
4. Filtrer Log Viewer par source, destination, port et heure.
5. Si la réponse manque ou si le chemin n’est pas clair, démarrer Packet Capture avec un filtre BPF précis.
6. Documenter le résultat avant toute modification de la configuration.

Si Live Connections affiche une session, mais qu’aucun événement de pare-feu correspondant n’apparaît dans Log Viewer, contrôler d’abord Log firewall traffic, Local reporting et les filtres. La procédure figure dans Log Viewer n’affiche pas de nouveaux logs.

Device Console propose également system diagnostics utilities connections. L’aide publique actuelle documente l’outil, mais pas toutes les options qui peuvent dépendre du build. Avant toute utilisation, vérifier la syntaxe disponible avec ? et n’utiliser la sortie qu’en lecture seule. Dépannage CLI de Sophos Firewall décrit ce cadre sûr.

Symptômes fréquents

La session attendue n’apparaît pas

Vérifier d’abord si le flux est encore actif et si la source, la destination et la version IP sont correctes. Avec DNS, CDN, proxy, NAT ou IPv6, l’adresse de destination réelle peut différer de celle supposée. Générer un nouveau test et lancer Packet Capture en parallèle si la réception des paquets par le pare-feu n’est pas claire.

Une Rule ID ou NAT ID incorrecte est visible

Une règle plus générale située plus haut peut être prioritaire. Comparer l’ordre des règles de pare-feu et de NAT, les zones, la source, la destination, le service, l’utilisateur et le calendrier. Ne pas déplacer plusieurs règles simultanément. La procédure guidée se trouve dans Tester correctement une règle Sophos Firewall.

Seule une direction incrémente RX ou TX

Cela peut indiquer un chemin de retour absent, une traduction NAT incorrecte, un problème du système de destination ou le pare-feu local du serveur. Contrôler les interfaces, les adresses traduites et la passerelle, puis rechercher les deux directions dans Packet Capture. Un compteur seul ne prouve pas la cause.

Les valeurs ne changent pas après une modification de configuration

La vue affiche probablement encore la session existante. Fermer proprement la connexion du client, générer un nouveau flux, puis contrôler à nouveau Start time et Connection ID. Ne pas utiliser un vidage global des sessions ou un redémarrage de service comme premier test standard.

La session ou le log correspondant manque dans un environnement HA

Noter Connection served by et tenir compte du nœud qui traitait le trafic au moment de l’événement. Les logs sont stockés localement sur chaque nœud HA et ne sont pas entièrement synchronisés entre les nœuds. Ne pas déduire une continuité de session sans interruption d’une Connection List visible. Configurer la HA sur Sophos Firewall explique ces limites.

Other applications est inhabituellement volumineux

Commencer par regrouper les connexions par adresse IP source et ouvrir chaque session. Des applications non identifiées, du trafic système et plusieurs causes différentes peuvent être réunis dans ce groupe. Contrôler d’abord Rule ID, les destinations, les ports, l’utilisateur et le contexte applicatif avant d’en déduire un incident de sécurité.

Liste de contrôle

• Source, destination, protocole, ports et heure du test sont connus.
• Une nouvelle connexion a été générée pour le test.
• Live Connections a été regroupé de manière pertinente par adresse IP source, utilisateur ou application.
• Start time, In/Out interface, Rule ID et NAT ID correspondent aux attentes.
• Translated source/destination et Gateway ID correspondent au chemin prévu.
• User et Policy IDs n’ont été attendus que si l’identification correspondante est active.
• Rule ID 0 a été interprétée dans le bon contexte de trafic système.
• Connection served by a été documenté en HA.
• Log Viewer et, si nécessaire, Packet Capture confirment la session.
• Aucun vidage global des sessions ni redémarrage de service n’a été utilisé comme première tentative de diagnostic.

Questions fréquentes