Utiliser Packet Capture Sophos Firewall dans WebAdmin
Packet Capture est l’un des outils de troubleshooting les plus importants dans Sophos Firewall WebAdmin. Il montre si des paquets arrivent sur une interface, s’ils sont transférés, quelle règle ou quel NAT ID intervient et si un paquet est rejeté.
Log Viewer montre la décision de la firewall. Packet Capture montre le flux des paquets. Ensemble, ils constituent souvent le moyen le plus rapide d’identifier la cause.
Point important : cet article décrit la version WebAdmin de Packet Capture. Elle est idéale pour une première vérification, car on voit directement dans le navigateur si des paquets arrivent, sont transférés ou sont rejetés. Pour des captures plus longues, des filtres très précis, un export PCAP ou des cas de support, tcpdump via SSH est souvent plus adapté.
Quand Packet Capture est utile
Packet Capture aide surtout à répondre à des questions comme :
- Le trafic arrive-t-il vraiment sur la firewall ?
- Le trafic ressort-il sur l’interface attendue ?
- Une Firewall Rule correspond-elle ?
- Une NAT Rule correspond-elle ?
- Un paquet est-il rejeté par une policy, IPS ou le routing ?
- Une réponse revient-elle du système cible ?
- Un autre port ou protocole est-il utilisé que celui prévu ?
Si rien n’est visible dans Log Viewer, Packet Capture est souvent l’étape suivante. On voit alors si le problème se situe avant la firewall ou si la firewall traite le trafic.
Chemin de menu
L’outil se trouve sous :
Diagnostics > Packet capture
Packet Capture s’ouvre directement dans WebAdmin. Selon la version SFOS et l’affichage du navigateur, il ressemble à une fenêtre de diagnostic séparée dans WebAdmin.
Log Viewer ou Packet Capture ?
Log Viewer et Packet Capture répondent à des questions différentes.
| Outil | Montre principalement |
|---|---|
| Log Viewer | Quelle Firewall Rule, Web Policy, Application Control, IPS ou SSL/TLS inspection a pris la décision |
| Packet Capture | Si des paquets individuels arrivent, sont transférés, consommés, générés ou rejetés |
Un bon exemple est un ping. Dans Log Viewer, on voit souvent seulement une entrée ou une décision résumée pour la connexion. Dans Packet Capture, on voit les paquets ICMP individuels : Echo Request vers la destination et Echo Reply en retour. Windows envoie par défaut quatre ICMP Echo Requests avec ping. Dans Packet Capture, on s’attend donc à voir plusieurs paquets aller et retour. Si seuls les requests sont visibles mais qu’aucun reply ne revient, le problème est différent de celui où aucun request n’arrive sur la firewall.
En pratique :
- Log Viewer répond : Quelle règle ou quel module a pris la décision ?
- Packet Capture répond : Les paquets sont-ils vraiment arrivés et quel chemin prennent-ils ?
- Pour les problèmes de routing, NAT, VLAN, gateway ou chemin retour, Packet Capture est souvent plus parlant.
- Pour les décisions Web filter, Application Control, IPS ou SSL/TLS inspection, Log Viewer est également nécessaire.
Réduire le périmètre avant de démarrer
Packet Capture ne devrait pas être lancé sans filtre. Dans les réseaux de production, cela génère très vite beaucoup de données et rend la sortie difficile à lire.
Il faut noter à l’avance :
- Source IP
- Destination IP ou FQDN
- Protocole
- Source port, si pertinent
- Destination port
- Interface ou zone
- Heure du test
- Application concernée
Pour un test web, le périmètre pourrait ressembler à ceci :
| Champ | Exemple |
|---|---|
| Source IP | 172.16.10.25 |
| Destination | 93.184.216.34 |
| Protocol | TCP |
| Destination Port | 443 |
| Direction attendue | LAN vers WAN |
Configurer le capture filter
Avec Configure, on définit un filtre aussi précis que possible.
Filtres typiques :
- Source IP du client
- Destination IP du serveur
- Destination port
- Protocole TCP, UDP ou ICMP
- Interface
Si le serveur cible n’est pas connu, on peut commencer par filtrer uniquement sur la Source IP. Si trop de paquets apparaissent, il faut réduire davantage.
Sophos Firewall utilise la syntaxe Berkeley Packet Filter, ou BPF. Le capture filter décide quels paquets sont écrits dans le capture buffer. Il doit donc être défini proprement avant le test.
Exemples BPF typiques :
| Objectif | Exemple BPF |
|---|---|
| hôte précis | host 10.10.10.1 |
| Source IP précise | src host 10.10.10.1 |
| Destination IP précise | dst host 10.10.10.1 |
| réseau précis | net 10.10.10.0 |
| port précis | port 443 |
| port de destination précis | dst port 443 |
| hôte et port précis | host 10.10.10.1 and port 443 |
| ICMP/ping | proto ICMP |
| TCP | proto TCP |
| UDP | proto UDP |
Pour un test web très ciblé, un filtre peut par exemple ressembler à ceci :
host 172.16.10.25 and host 93.184.216.34 and port 443
Pour un test ping, ceci suffit souvent :
host 172.16.10.25 and proto ICMP
Dans WebAdmin, le BPF string actif apparaît au-dessus de la liste des paquets après l’enregistrement. Le premier screenshot montre la configuration du filtre, le second la liste des résultats avec le filtre actif.
⚠️ Les données PCAP peuvent contenir des adresses IP, noms d’hôte, détails de protocoles et, selon le protocole, des données utiles. Les captures ne doivent être partagées qu’avec des personnes ou partenaires autorisés à voir ces données.
Démarrer la capture et reproduire le problème
- Définir le filtre.
- Activer Packet Capture avec le curseur.
- Reproduire le problème de manière ciblée.
- Arrêter la capture.
- Analyser les résultats.
- Effacer la capture avant de lancer un nouveau test.
Sophos Firewall affiche le statut et le buffer :
| Affichage | Signification |
|---|---|
Trace On | Packet Capture est en cours |
Trace Off | Packet Capture est désactivé |
Buffer size | Taille du capture buffer, 2048 KB dans la documentation Sophos |
Buffer used | buffer actuellement utilisé |
Lorsque le buffer est plein, la capture s’arrête automatiquement. Il faut ensuite utiliser Clear avant de pouvoir enregistrer une nouvelle capture utile. C’est pourquoi un filtre précis est important.
Dans les paramètres du filtre, on peut aussi définir combien d’octets par paquet sont capturés. Pour beaucoup de premières analyses, les informations d’en-tête suffisent. Si davantage de payload est nécessaire, il faut capturer plus d’octets, tout en tenant compte de la protection des données et de la taille du buffer.
Comprendre les colonnes importantes
Packet Capture affiche de nombreux champs. En pratique, les plus importants sont :
| Champ | Signification |
|---|---|
| Time | Heure du paquet |
| In interface | Interface sur laquelle le paquet est arrivé |
| Out interface | Interface par laquelle le paquet sort |
| Source IP | Adresse source |
| Destination IP | Adresse destination |
| Packet type | Protocole ou type de paquet |
| Ports [src, dst] | Port source et port destination |
| NAT ID | Règle NAT correspondante |
| Rule ID | Firewall Rule correspondante |
| Status | Statut du paquet |
| Reason | Raison du drop ou de la violation |
| Connection status | État de la connexion |
| Gateway ID | Gateway utilisée |
| Username | Utilisateur détecté |
| IPS policy ID | IPS Policy appliquée |
| Application filter ID | Application Control Policy appliquée |
Ces champs sont précieux, car ils comblent l’écart entre « la règle semble correcte » et « le trafic passe réellement ainsi ».
Avec Show additional properties ou la vue détaillée, d’autres informations peuvent apparaître selon la version, comme Connection ID, Web filter ID, Application ID, Web category ID, Gateway ID, Username ou d’autres policy IDs. Ces détails aident lorsqu’un paquet n’est pas traité uniquement par une Firewall Rule, mais aussi par Web, Application Control, IPS ou d’autres modules.
Interpréter correctement le statut
| Status | Signification |
|---|---|
| Incoming | Le paquet a été reçu sur une interface |
| Forwarded | Le paquet a été transféré |
| Consumed | Le paquet est destiné à la firewall elle-même |
| Generated | Le paquet a été généré par la firewall |
| Violation | Le paquet a été rejeté à cause d’une violation de policy |
Si seul Incoming est visible et pas Forwarded, le paquet reste probablement bloqué sur la firewall. Il faut alors vérifier Firewall Rule, NAT, routing et security features.
Si Forwarded est visible mais qu’aucune réponse ne revient, le problème se situe souvent sur le système cible, le chemin retour, NAT ou un pair distant.
Avec un ping réussi, on voit généralement des paquets dans les deux directions. Si Windows envoie quatre pings, on voit plusieurs ICMP Echo Requests du client vers la destination et plusieurs Echo Replies en retour. Si les Replies manquent, il faut vérifier la route retour, le système cible, la firewall locale du système cible, NAT ou un pair distant. Si même les Requests manquent, il faut vérifier le client, la gateway, le VLAN, le port du switch ou si le trafic atteint Sophos Firewall.
Utiliser Display filter
Le capture filter limite les paquets enregistrés. Le Display filter, lui, filtre l’affichage déjà enregistré. C’est pratique si la capture a volontairement été lancée un peu plus largement et que seuls certains paquets doivent ensuite être affichés.
Dans Display filter, on peut filtrer entre autres sur :
- Interface name
- Ethernet type, par exemple IPv4, IPv6 ou ARP
- Packet type
- Source IP et Source port
- Destination IP et Destination port
- Reason
- Status
- Rule ID
- User
- Connection ID
Pour le troubleshooting, Status, Reason, Rule ID, Source IP, Destination IP et Destination port sont particulièrement utiles. Si beaucoup de paquets sont dans la capture, ils permettent de réduire rapidement l’affichage à la partie pertinente sans relancer immédiatement le test.
Lire NAT dans Packet Capture
Avec NAT, il faut tenir compte du fait qu’un paquet a un aspect différent avant et après NAT. Packet Capture peut afficher NAT ID, Rule ID et les adresses modifiées.
Pour les problèmes NAT, il faut vérifier :
- Le paquet est-il visible avec l’adresse originale ?
- Le paquet est-il visible après la traduction ?
- Le NAT ID attendu est-il affiché ?
- Le paquet sort-il par le Out interface attendu ?
- Une réponse revient-elle ?
Pour DNAT, il y a un point supplémentaire : la Firewall Rule utilise la zone de destination après NAT, mais l’IP de destination avant NAT. Cela paraît inhabituel au début.
Plus d’informations : Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT.
Combiner Packet Capture et Log Viewer
Le meilleur déroulement est :
- Ouvrir Log Viewer.
- Démarrer Packet Capture avec un filtre précis.
- Reproduire le test.
- Vérifier dans Packet Capture si les paquets arrivent et sortent.
- Vérifier dans Log Viewer quelle règle ou quel module a décidé.
- Si nécessaire, passer au fichier de log correspondant.
Log Viewer affiche par exemple les événements Firewall, Web, SSL/TLS inspection, IPS ou Application Control. Packet Capture montre en revanche le flux de paquets au niveau des interfaces.
Cette combinaison est importante surtout avec ping ou de simples connexions TCP. Log Viewer peut seulement montrer qu’une connexion a été autorisée ou bloquée. Packet Capture montre en plus si les paquets de réponse reviennent, si NAT s’applique, si le bon Out interface est utilisé et si le chemin retour fonctionne.
Exemples fréquents
Le client n’atteint pas Internet : Définir une capture sur Source IP et TCP 443. Si aucun paquet n’arrive, vérifier client, VLAN, gateway ou switch. Si le paquet arrive mais ne sort pas, vérifier Firewall Rule, NAT ou routing.
DNAT ne fonctionne pas : Définir une capture sur l’IP publique de destination et le port externe. Si aucun paquet n’arrive, vérifier le routeur du provider, port forwarding, cloud Security Group ou WAN. Si le paquet arrive mais ne va pas vers le serveur interne, vérifier la règle DNAT et la Firewall Rule.
Le trafic VPN ne fonctionne pas : Définir une capture sur l’interface tunnel, XFRM interface ou les réseaux source/destination concernés. Vérifier aussi strongswan.log, charon.log ou xfrmi.log.
Web filter bloque de manière inattendue : Dans Packet Capture, on voit généralement seulement le flux de paquets. La décision réelle se vérifie mieux dans Log Viewer sous Web, Application Control ou SSL/TLS inspection.
Quand tcpdump est préférable
WebAdmin Packet Capture est idéal pour les analyses rapides. Pour des captures plus longues, des filtres très précis ou des cas de support, tcpdump en CLI est souvent meilleur.
Plus d’informations : Collecter les logs Sophos Firewall avec TCPDump pour analyse.