Utiliser Packet Capture de Sophos Firewall dans WebAdmin

Sous Diagnostics > Packet capture, il est possible de suivre un flux réseau unique directement dans WebAdmin. Il suffit de définir un filtre BPF précis, de démarrer la capture, de reproduire le problème une fois, puis de vérifier les interfaces, Rule ID, NAT ID, Status et Reason.

Packet Capture montre le flux réel des paquets. La stratégie ayant pris la décision doit également être vérifiée dans Log Viewer. Pour des captures plus longues ou un fichier .pcap, il faut utiliser tcpdump via SSH, car la capture WebAdmin ne peut pas être téléchargée au format PCAP.

Si la connexion est déjà établie et qu’il faut d’abord uniquement trouver la session active avec son utilisateur, ses interfaces, Rule ID, NAT ID ou sa passerelle, commencer par Live Connections et Connection List. Packet Capture intervient ensuite lorsque le chemin réel aller et retour doit être prouvé.

Packet Capture en six étapes

Noter la Source IP, la destination, le protocole, le port et l’heure du test. Exemple : client 172.16.10.25 vers 93.184.216.34 via TCP 443.
Ouvrir Diagnostics > Packet capture et cliquer sur Configure.
Définir et enregistrer une chaîne BPF, par exemple host 172.16.10.25 and port 443.
Régler Packet Capture sur Trace On. Dans les versions actuelles de SFOS, les détails des paquets apparaissent dans une nouvelle fenêtre du navigateur.
Reproduire exactement un test, puis arrêter la capture avec Trace Off.
Lire la séquence de bas en haut et contrôler In/Out interface, Rule ID, NAT ID, Status, Reason et les paquets de réponse.

Si la chaîne BPF est modifiée pendant une capture, régler d’abord Packet Capture sur Trace Off, puis de nouveau sur Trace On afin d’appliquer le nouveau filtre.

⚠️ Une capture large et continue complique l’analyse et collecte inutilement des données d’exploitation. Utiliser un filtre précis, effectuer un test court et désactiver Packet Capture ensuite.

Définir un Capture Filter précis

Le Capture Filter détermine avant la capture quels paquets entrent dans le tampon de 2048 KB. Le Display Filter limite uniquement l’affichage des données déjà capturées. L’interface ne se sélectionne donc pas dans Capture Filter, mais plus tard dans Display Filter.

Pour un test HTTPS, il faut connaître au moins la source, la destination et le port. Si la destination reste incertaine à cause du DNS, d’un CDN ou du NAT, mieux vaut commencer uniquement avec la Source IP, puis affiner le flux visible.

Avant de commencer, les éléments suivants doivent être connus :

Source IP et Destination IP actuelle
protocole ainsi que ports source et de destination, s’ils sont pertinents
interfaces d’entrée et de sortie attendues ou zones correspondantes
Firewall Rule et NAT Rule attendues
résultat attendu, par exemple autorisé, bloqué, DNAT, SNAT ou VPN
heure exacte du test et une seule action reproductible

Exemples BPF

Hôte : host 10.10.10.1
Source IP : src host 10.10.10.1
Destination IP : dst host 10.10.10.1
Réseau : net 10.10.10.0/24
Port : port 443
Port de destination : dst port 443
Protocole : proto TCP, proto UDP ou proto ICMP

Un test web précis peut se présenter ainsi :

host 172.16.10.25 and host 93.184.216.34 and port 443

Pour un test ping, ceci suffit généralement :

host 172.16.10.25 and proto ICMP

Sophos documente ces formes BPF de base. Cela ne garantit pas automatiquement que toute expression tcpdump fonctionne dans WebAdmin.

Avec le NAT, le point de vue est important : un filtre sur l’adresse IP interne du client peut masquer l’entrée côté WAN après MASQ. S’il manque des paquets, filtrer d’abord uniquement par source, destination ou port, puis vérifier que les deux directions restent visibles.

Packet Capture de Sophos Firewall avec boîte de dialogue Configure, chaîne BPF et commutateur Trace — La chaîne BPF se définit sous Configure, puis Trace On démarre la capture.

Tampon et options de capture

Number of bytes to capture (per packet) définit le nombre d’octets enregistrés par paquet. Les données d’en-tête suffisent souvent pour un premier test.
Sans Wrap capture buffer once full, la capture s’arrête automatiquement à 2048 KB. Avec Wrap, les données les plus anciennes sont écrasées.
Clear vide le tampon avant un nouveau test.
La capture continue lors du passage à une autre page de WebAdmin. Il faut donc la régler volontairement sur Trace Off après le test.

Lire correctement les résultats

Un flux apparaît plusieurs fois, car le pare-feu capture l’entrée et la sortie sur les interfaces. Un aller-retour ping comprend généralement quatre lignes : la requête arrive sur LAN, sort sur WAN, la réponse arrive sur WAN et sort sur LAN. Les entrées les plus récentes figurent en haut ; pour suivre l’ordre chronologique, lire la liste de bas en haut.

Packet Capture de Sophos Firewall avec filtre BPF actif, interfaces, NAT ID, Rule ID et Status — La liste des paquets montre le flux sur les interfaces ainsi que NAT ID, Rule ID et Status associés.

Les champs les plus importants

In interface / Out interface : Où le paquet arrive et par quelle interface il repart.
Source IP / Destination IP / Ports : Quel flux est examiné.
Rule ID : Quelle règle de pare-feu traite le trafic.
NAT ID : Quelle règle NAT intervient.
Status : Ce que fait le pare-feu à cette étape du traitement.
Reason : Pourquoi un paquet est rejeté.

La liste des paquets contient au besoin d’autres champs comme Connection ID, Gateway ID, Username ainsi que les ID de stratégies Web, Application ou IPS. Pour le paquet sélectionné, la vue détaillée affiche également les en-têtes et les données Hex et ASCII.

Interpréter correctement Status

Incoming : Le paquet a été reçu sur une interface ; cela ne prouve pas encore une décision ultérieure.
Forwarded : Le pare-feu a transféré le paquet via une interface de sortie.
Consumed : Le paquet est destiné au pare-feu lui-même, par exemple à WebAdmin, VPN Portal, SSH, DNS ou un service VPN.
Generated : Le pare-feu a généré le paquet, par exemple comme réponse ou via un service système.
Violation : Le pare-feu a rejeté le paquet en raison d’une violation de stratégie.

Avec Consumed, Administration > Device access, une Local Service ACL ou le service de pare-feu concerné sont souvent déterminants. Sécuriser Device Access de Sophos Firewall explique la configuration correspondante.

Vérifier ensemble Rule ID, NAT ID et Reason

Une Rule ID inattendue ne prouve pas qu’une règle est défectueuse. Vérifier d’abord l’ordre des règles, les zones et la correspondance dans Log Viewer. La procédure complète est décrite dans Tester correctement une règle Sophos Firewall.

Avec le NAT, le même flux peut apparaître avec des adresses différentes avant et après la traduction. La NAT ID attendue, In/Out interface et les paquets de réponse sont déterminants. Comprendre le NAT sur Sophos Firewall explique la logique de traduction.

Si Reason affiche par exemple LOCAL_ACL, IPS, APPLICATION_FILTER, USER_IDENTITY ou IP_SPOOF, vérifier le module correspondant dans Log Viewer. Une classification détaillée figure dans Analyser les paquets rejetés sur Sophos Firewall.

Pour comparer avec Log Viewer :

Ouvrir Log Viewer et Packet Capture en parallèle.
Définir Capture Filter et reproduire exactement un test.
Dans Packet Capture, contrôler les interfaces, les paquets de réponse, Rule ID et NAT ID.
Dans le module approprié de Log Viewer, vérifier quelle règle ou Security Policy a pris la décision.
Ensuite seulement, examiner précisément la règle, le NAT, le routage ou le module de sécurité concerné.

Utiliser Display Filter

Display Filter est utile lorsque la liste contient déjà des paquets. Il permet notamment de filtrer par interface, IPv4/IPv6/ARP, Packet type, Source/Destination IP et port, Reason, Status, Rule ID, User ou Connection ID. Allowed est également disponible comme valeur de filtre pour les paquets autorisés ; les lignes de paquets montrent les étapes de traitement telles que Incoming ou Forwarded.

Pour les problèmes ARP ou NDP, Contrôler le cache des voisins ARP et NDP montre comment comparer la capture au cache local des voisins et aux associations statiques.

Save applique le filtre et Clear le réinitialise. Pour le trafic VPN, on peut par exemple régler Capture Filter sur un hôte ou un réseau, puis limiter l’affichage à l’interface XFRM ou tunnel attendue.

Analyse rapide des erreurs

Aucun paquet visible : Vérifier Capture Filter et Display Filter. Pour les FQDN et CDN, contrôler l’adresse IP de destination actuelle ; avec le NAT, filtrer d’abord uniquement par Source IP. Si la liste reste vide, vérifier la passerelle du client, le VLAN, le port du commutateur et les équipements en amont.

Le client n’accède pas à Internet : Filtrer sur l’adresse IP du client et, par exemple, TCP 443. Si rien n’arrive, la cause se situe avant le pare-feu. Si la requête arrive sans être transférée, vérifier la règle de pare-feu, le NAT et le routage.

Seul Incoming est visible : Rechercher Forwarded, Consumed ou Violation et vérifier que le filtre ne masque pas les étapes suivantes. Dans SFOS 22.0 MR1, le Known Issue NC-178387 peut faire apparaître les rejets par défaut avec Firewall ID 0 sans ligne Violation Firewall. Comparer alors avec Policy tester ou créer, pour le flux concerné, une règle de rejet explicite avec journalisation à la fin de la liste des règles. Définir précisément les zones source et de destination ; les détails figurent dans Analyser les paquets rejetés sur Sophos Firewall.

Forwarded, mais aucune réponse : Vérifier la route de retour, le NAT, le système cible, le pare-feu local de la cible et l’extrémité distante. Forwarded prouve uniquement que Sophos Firewall a transmis le paquet.

Rule ID ou NAT ID inattendue : Comparer les ID avec Log Viewer et la position de la règle. Ne pas modifier plusieurs règles à la fois ; La règle Sophos Firewall ne correspond pas aide à résoudre les problèmes de correspondance.

DNAT ne fonctionne pas : Vérifier si la requête arrive sur WAN, quelle NAT ID la traite et si elle est transférée vers le serveur interne. Si rien n’apparaît sur WAN, la cause se situe souvent avant le pare-feu. Publier un serveur avec DNAT présente la configuration complète.

Le trafic VPN est absent : Capturer par hôte, réseau ou protocole et sélectionner l’interface tunnel ou XFRM attendue dans Display Filter. Pour poursuivre l’analyse, consulter Dépannage IPsec sur Sophos Firewall.

Le filtre web bloque de façon inattendue : Packet Capture montre le flux, mais pas la décision complète de Web, Application Control ou SSL/TLS. La vérifier dans le module Log Viewer approprié.

Les petits tests fonctionnent, mais les transferts volumineux se bloquent : Dans WebAdmin, surveiller les réponses manquantes et la taille des paquets. Les retransmissions peuvent être analysées de manière fiable avec un fichier PCAP dans Wireshark. Vérifier aussi MTU et MSS.

Packet Capture ne démarre pas : Vider d’abord le tampon et vérifier la nouvelle fenêtre du navigateur. Si le problème persiste, redémarrer le service Packet capture and Live connections sous System services > Services. Le redémarrage interrompt aussi temporairement l’affichage Live Connections.

Confidentialité et passage à tcpdump

Les données de capture peuvent contenir des adresses IP internes, des noms d’hôte, des noms d’utilisateur, des relations de communication et, avec des protocoles non chiffrés, des données utiles. Avant de les partager, vérifier le destinataire, l’étendue et la conservation ; quelques lignes pertinentes suffisent souvent au lieu de la capture complète.

Pour des captures plus longues, une interface précise, un nombre fixe de paquets, Snap Length ou un fichier .pcap, utiliser tcpdump sur Sophos Firewall. Transférer ensuite le fichier de manière sécurisée et le supprimer du pare-feu.