La règle Sophos Firewall ne s'applique pas : vérifier les causes

Lorsqu’une règle Sophos Firewall ne s’applique pas, il ne faut pas commencer par déplacer des règles ou élargir des objets. Il faut d’abord reproduire et observer un seul flux de données : le paquet arrive-t-il, quelles Firewall Rule ID et NAT Rule ID le traitent, est-il transféré et une réponse revient-elle ?

On constate généralement qu’une condition diffère de ce qui était attendu, qu’une règle plus générale située plus haut s’applique ou que le problème apparaît seulement après la décision de règle. Le firewall lui-même est bien moins souvent en cause qu’un test défini de manière imprécise.

Décision rapide : Si un Packet Capture correctement démarré et filtré n’affiche aucun paquet, vérifier d’abord le client, le VLAN, la passerelle ou le chemin en amont. Une autre Rule ID mène à l’ordre et au matching. Si la Rule ID et la NAT ID sont correctes, poursuivre l’analyse avec le routage, le chemin de retour, le système de destination ou un module de sécurité.

Voie rapide : suivre un flux concret

Six étapes suffisent pour la première délimitation :

1. Définir le flux de test : Noter la Source IP, la Source zone, l’utilisateur, la destination, le protocole, le port et l’heure.
2. Prouver l’arrivée : Démarrer Packet Capture avec un filtre de capture restreint et déclencher le même flux.
3. Vérifier la Firewall Rule ID : La comparer à la règle attendue dans Log Viewer ou Packet Capture.
4. Vérifier la NAT Rule ID : Si le NAT intervient, contrôler la règle NAT réellement utilisée et sa traduction.
5. Vérifier le transfert et la réponse : Rechercher Forwarded, l’interface de sortie et les paquets de retour.
6. Approfondir seulement ensuite : Examiner le routage, le SD-WAN, le User Matching, TLS Inspection, IPS, la Web Policy ou le système de destination.

Cette procédure sépare les différentes couches. Une règle firewall décide de l’accès et des fonctions de protection, le NAT traduit des adresses ou des ports, le routage sélectionne le chemin suivant et le système de destination doit connaître le chemin de retour. Si toutes les couches sont modifiées simultanément, le symptôme peut disparaître, mais la cause reste incertaine.

Si le test vise WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP ou un autre service du firewall lui-même, les mêmes règles que pour le trafic de transit ne s’appliquent pas. Dans ce cas, le diagnostic mène directement à Administration > Device access et à la Local Service ACL.

Définir un cas de test reproductible

Une affirmation comme « Internet ne fonctionne pas » ou « la règle VPN ne s’applique pas » est trop générale. Un cas de test exploitable se présente par exemple ainsi :

• Source IP : 10.10.20.35
• Source zone : LAN
• User : admin@example.com ou volontairement aucun User Matching
• Destination : app.example.net, actuellement résolu en 203.0.113.20
• Service : TCP 443
• Règle firewall attendue : LAN-App-HTTPS, Rule ID 37
• Règle NAT attendue : NAT Rule ID 12 ou explicitement aucune règle NAT
• Heure du test : 2026-08-08 10:15:00

Les adresses IP, les ID, les noms et l’heure sont des exemples à remplacer par les valeurs de l’environnement concerné. La forme est importante : pendant le diagnostic, la source, l’IP de destination, le port et l’utilisateur restent identiques. Si la résolution DNS, le client ou l’application changent entre-temps, le même flux n’est plus comparé.

Interpréter les premières observations

• Un Packet Capture actif n’affiche aucun paquet malgré un filtre adapté : Vérifier d’abord l’état de la capture, le filtre et le tampon. S’ils sont corrects, la cause se situe probablement avant le firewall, par exemple au niveau du client, du VLAN, du switch, de la passerelle, du fournisseur ou du Security Group cloud.
• Log Viewer affiche une autre Rule ID : Une règle plus générale, générée automatiquement ou correspondant autrement est évaluée en premier.
• La Firewall Rule ID est correcte, mais pas la NAT Rule ID : Vérifier l’ordre NAT ainsi que la source, la destination et le service d’origine.
• La Rule ID et la NAT ID sont correctes, mais aucun Forwarded n’est visible : Vérifier l’action de règle, Reason, le routage ou un module de sécurité.
• Forwarded est visible, mais aucune réponse n’arrive : Vérifier la route de retour, le système de destination, le firewall local du serveur ou un blocage externe.
• Seuls certains utilisateurs sont concernés : Contrôler séparément l’authentification et le User Matching du flux de données réel.

La procédure combinée détaillée est présentée dans Tester une règle firewall avec Log Viewer, Policy Tester et Packet Capture. Cet article se concentre sur l’explication d’un match de règle inattendu.

Vérifier l’ordre et le matching des règles

Une règle firewall ne s’applique que si tous les critères pertinents correspondent et qu’aucune règle antérieure n’a déjà traité le même trafic.

La première règle correspondante gagne

Sophos Firewall évalue les règles de haut en bas et arrête la recherche à la première règle correspondante. La position dans la liste est donc décisive ; la Rule ID n’est qu’un identifiant fixe et ne correspond pas à la position.

Il faut également tenir compte des points suivants :

• Une règle générale située au-dessus peut masquer complètement une règle spécifique située en dessous.
• Les Rule Groups améliorent la lisibilité, mais ne créent pas leur propre logique de matching. Les règles qu’ils contiennent sont évaluées.
• Les règles générées automatiquement, par exemple pour MTA, IPsec ou les hotspots, peuvent être insérées en haut et vérifiées en premier.
• Un filtre actif dans la table des règles peut masquer des règles pertinentes. Utiliser Reset filter avant l’analyse.
• La règle Default Drop non modifiable porte la Rule ID 0, se trouve à la fin et ne possède pas de Usage Counter normal. Les filtres de la table ne s’appliquent pas à elle.

Pour revoir entièrement la logique fondamentale d’une règle, consulter Comprendre et configurer correctement les règles Sophos Firewall.

Lire ensemble tous les critères de matching

Une règle qui semble correcte peut échouer à cause d’un seul champ :

• Source zones : Le client provient d’une autre zone, par exemple VPN au lieu de LAN, ou le VLAN est affecté différemment.
• Source networks and devices : L’objet IP, le groupe d’hôtes ou le sous-réseau ne contient pas la Source IP réelle.
• Destination zones : La zone de destination est incorrecte, notamment avec le DNAT, le VPN ou des réseaux routés.
• Destination networks : L’adresse IP réellement contactée ne correspond pas à l’objet ou les vues avant et après NAT ont été confondues.
• Services : Le port manque, TCP et UDP ont été intervertis ou l’application ouvre des connexions supplémentaires.
• Users or groups : Le firewall ne peut pas associer l’utilisateur à la Source IP ou le groupe importé ne correspond pas.
• Schedule : Le planning n’est pas actif au moment du test.
• Exclusions : Le flux est exclu de la règle, puis comparé aux règles suivantes.

Pour le trafic web, le protocole fait également partie du test. Les navigateurs peuvent utiliser QUIC sur UDP 443, alors que la règle ou l’inspection web attendue ne couvre que le HTTPS classique sur TCP 443. Contrôler QUIC sur Sophos Firewall explique les effets.

Réinitialiser de manière contrôlée le volume de données transféré

L’option Reset data transfer count peut aider pendant le test, mais elle est souvent mal interprétée. Elle réinitialise le volume de données transféré par la règle ; il ne s’agit pas d’un compteur de sessions ou de correspondances.

1. Ouvrir Rules and policies > Firewall rules.
2. Rechercher la règle concernée et ouvrir le menu à trois points.
3. Sélectionner Reset data transfer count.
4. Déclencher à nouveau le flux de test défini.
5. Évaluer ensemble le volume de données, la Rule ID et Packet Capture.

Si la valeur augmente après le test contrôlé, cela indique que du trafic a été transféré par cette règle. Si elle reste inchangée, cela ne prouve pas à lui seul que la règle n’a jamais correspondu. Pour une conclusion fiable, vérifier la Rule ID réelle dans Log Viewer et le chemin des paquets dans Packet Capture. Ce compteur de données n’est de toute façon pas disponible pour la règle Default Drop ID 0.

Lire correctement Log Viewer, Policy Tester et Packet Capture

Les outils répondent à des questions différentes :

• Log Viewer : Quelle session journalisée, quelle règle, quelle règle NAT, quelle action et quel utilisateur ont été détectés ?
• Policy Tester : Quelle logique de politique s’appliquerait aux valeurs saisies ?
• Packet Capture : Quels paquets arrivent réellement, comment le firewall les traite-t-il et ressortent-ils ?

Aucun de ces outils ne remplace entièrement les autres. Si la simulation et le flux réel de paquets se contredisent, les données de log et de paquets issues du test reproductible ont plus de poids.

Log Viewer : Rule ID et NAT Rule ID réelles

Log firewall traffic doit être activé dans la règle firewall. En outre, le type de log adapté à l’affichage local, à Sophos Central ou à syslog doit être activé sous System services > Log settings.

Pour le test, des filtres sur les champs suivants sont utiles :

• Source IP et Destination IP
• Port ou service
• Rule ID et Rule name
• NAT rule ID
• Action et User
• l’heure de test notée

L’absence d’une entrée ne prouve pas encore que le firewall n’a rien vu. Les sessions firewall sont notamment journalisées lorsque la connexion se termine par un événement Destroy. En cas d’interruption brutale de la connexion, l’entrée attendue peut donc manquer ou apparaître plus tard. Packet Capture fournit alors un résultat plus direct. Les services et fichiers de log correspondants sont décrits dans Dépannage Sophos Firewall : services et logs.

Policy Tester : logique de politique sans flux de paquets réel

Sous Diagnostics > Tools > Policy tester, définir volontairement l’URL, l’utilisateur, l’heure, la Source IP et la Source zone. Le protocole et le port doivent ressortir de l’URL complète, par exemple https://app.example.net:8443/. Sans protocole, l’outil teste HTTP ; pour HTTPS, le port 443 est utilisé par défaut et un autre port doit être indiqué dans l’URL.

Policy Tester est utile, mais présente des limites claires :

• Il ne génère aucun flux de paquets réel et ne vérifie ni le système de destination ni le chemin de retour.
• Les résultats ne reflètent pas les routes SD-WAN.
• Les règles comportant des adresses MAC sous Source networks and devices ne peuvent pas correspondre.
• Les problèmes de fournisseur, de switch, de passerelle et de perte de paquets restent invisibles.

⚠️ Sur SFOS 22.0 GA Build 411, NC-177587 et NC-176083 pouvaient provoquer des résultats erronés dans Policy Tester. Le trafic semblait bloqué ou associé à la mauvaise règle alors qu’il circulait correctement en réalité. MR1 Build 490 contient les corrections documentées. En cas de résultats contradictoires, vérifier d’abord la version du firmware, Log Viewer et Packet Capture avant de modifier les règles de production.

Packet Capture : vérifier le chemin réel des paquets

Sous Diagnostics > Packet capture, définir d’abord un filtre de capture BPF restreint, par exemple sur la Source IP, la Destination IP et le port du flux de test. Activer ensuite Trace On, vider la liste et déclencher exactement le flux défini.

Un Packet Capture vide n’est significatif que si les conditions suivantes sont remplies :

1. Trace On est actif.
2. Le filtre de capture BPF correspond à la destination réelle et ne masque pas le flux.
3. Le tampon n’a pas déjà écrasé le trafic de test pertinent. Sans Wrap capture buffer once full, l’enregistrement s’arrête lorsque le tampon de 2048 KB est plein et reprend avec Clear. Lorsque l’option Wrap est activée, l’enregistrement continue et écrase les paquets les plus anciens.

Un Display Filter supplémentaire ne modifie pas ce qui a été enregistré, mais peut masquer des entrées existantes. Il faut donc contrôler séparément le filtre de capture et le Display Filter.

Les valeurs de statut signifient :

• Incoming : Le paquet a été reçu sur une interface.
• Forwarded : Le firewall transfère le paquet via une interface de sortie.
• Consumed : Le paquet est destiné au firewall lui-même ou utilisé par celui-ci.
• Generated : Le firewall a lui-même généré le paquet.
• Violation : Une violation de politique provoque le rejet ; le champ Reason précise la raison.

La Rule ID, la NAT ID, Reason ainsi que les interfaces d’entrée et de sortie doivent toujours être lus ensemble. Consumed et Generated sont des résultats normaux et ne constituent pas automatiquement des erreurs.

⚠️ Sur SFOS 22.0 MR1 Build 490, NC-178387 peut afficher les rejets par la règle par défaut ID 0 uniquement sous la forme Incoming. L’entrée attendue Violation Firewall et l’entrée dans drppkt sont absentes, bien que le firewall continue à rejeter le flux. Pour cette version concernée, Policy Tester ou une règle de rejet journalisée, placée volontairement à la fin de la liste de règles personnalisée, peuvent aider. La mention actuelle dans Known Issues n’indique aucune version corrigée.

Une procédure de capture détaillée est disponible dans Utiliser Packet Capture dans Sophos Firewall WebAdmin. Analyser les paquets rejetés sur Sophos Firewall traite des rejets et d’une règle finale contrôlée.

Vérifier le NAT, le DNAT, le routage et le chemin de retour

Le NAT n’autorise pas le trafic. Il traduit des adresses ou des ports pour le trafic qu’une règle firewall autorise. La Firewall Rule ID et la NAT Rule ID doivent donc correspondre séparément.

Évaluer ensemble Firewall Rule ID et NAT Rule ID

• La Firewall Rule ID est correcte, la NAT Rule ID est incorrecte : Vérifier l’ordre NAT, les champs Original et les règles NAT plus générales.
• La NAT Rule ID est correcte, la Firewall Rule ID est incorrecte : Comparer l’ordre des règles firewall, les zones, la source, la destination, le service et le planning.
• Les deux ID sont correctes, mais la connexion échoue : Vérifier le routage, le chemin de retour, le serveur de destination, le module de sécurité ou l’application.
• Aucune NAT Rule ID n’est visible alors que le NAT est attendu : Contrôler la direction, Inbound/Outbound Interface et les critères d’origine de la règle NAT.

Sous Rules and policies > NAT rules, la première règle correspondante gagne également. Une règle SNAT ou MASQ générale peut donc masquer une règle spécifique située en dessous. Les Linked NAT Rules ne sont en outre prises en compte que pour le trafic correspondant à leur règle firewall associée ; une règle NAT autonome antérieure peut néanmoins s’appliquer en premier.

Comprendre le NAT sur Sophos Firewall explique la logique complète des ID.

Comprendre le DNAT du point de vue avant et après NAT

Une règle importante s’applique au trafic DNAT entrant :

La règle firewall utilise la zone de destination après NAT, mais comme Destination Network l’adresse contactée à l’origine avant NAT.

Exemple de redirection de port :

• Le client externe se connecte à 198.51.100.10 sur TCP 8888.
• La règle NAT traduit vers le serveur 10.10.50.20 dans la zone DMZ et vers TCP 4444.
• Dans la règle NAT, TCP 8888 est l’Original service et TCP 4444 le Translated service (PAT).
• La règle firewall utilise WAN comme Source zone, DMZ comme Destination zone et 198.51.100.10 comme Destination network.
• Dans l’exemple PAT officiel de Sophos, la règle firewall associée contient à la fois le service d’origine et le service traduit.

Le test externe continue de viser le port 8888 ; le serveur interne reçoit la connexion sur le port 4444. Si un seul des deux ports est pris en compte, la règle peut rapidement sembler correcte alors que le matching du service et la traduction ne correspondent pas. La publication complète est décrite dans Publier un serveur par DNAT sur Sophos Firewall.

Établir une nouvelle connexion après des modifications NAT

Sophos Firewall n’évalue une règle NAT que pour le premier paquet d’une connexion. Les sessions existantes continuent d’utiliser la traduction précédente, même si la règle NAT a été modifiée depuis.

Après une correction NAT, établir une nouvelle connexion : arrêter le test en cours, fermer la session existante du navigateur ou de l’application et relancer le flux. Un rechargement dans la même session TCP ne prouve pas de manière fiable la nouvelle configuration NAT.

Examiner le routage uniquement après avoir confirmé le match

Si la Rule ID et la NAT Rule ID sont correctes et que Packet Capture affiche Forwarded, le matching de la règle est en principe prouvé. Vérifier ensuite :

• la route statique ou Default Route adaptée
• la SD-WAN route et la passerelle active
• l’interface de sortie réelle
• la route sur le système de destination et dans les réseaux distants
• le chemin de retour symétrique via VPN, MPLS ou WAN
• le firewall local du serveur de destination

Policy Tester ne reflète pas le SD-WAN. La Gateway ID, l’interface et le chemin des paquets sont déterminants pour la décision réelle. Adapter la priorité du routage sur Sophos Firewall explique l’ordre des routes statiques, SD-WAN et VPN.

Cas particuliers après le premier constat

Ce n’est qu’une fois le flux de base classifié qu’il est utile d’approfondir les services locaux, les utilisateurs, la résolution de noms ou les modules de sécurité.

Trafic vers le firewall lui-même : Device Access plutôt qu’une règle firewall

WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS et SNMP se terminent sur le firewall. Le statut Packet Capture peut donc être Consumed. L’accès est contrôlé sous Administration > Device access ainsi qu’avec les Local Service ACL Exception Rules, et non avec une règle de transit normale.

Vérifier la zone, le réseau source de confiance, le service autorisé, les droits de l’utilisateur et MFA. Sécuriser Sophos Firewall Device Access et Local Service ACL explique l’interaction importante pour la sécurité ; Aperçu des portails Sophos Firewall classe les différentes interfaces web.

Séparer la connexion utilisateur et le User Matching

Une connexion réussie à VPN Portal, User Portal, Captive Portal ou via Entra ID SSO confirme d’abord uniquement l’authentification. Pour que la règle utilisateur prévue s’applique, le firewall doit également associer l’utilisateur au flux de données réel et à sa Source IP.

Constats typiques :

• Le champ User dans Log Viewer est vide : Vérifier STAS, AD SSO, Captive Portal, Entra ID SSO ou Clientless User. Pour une IP d’équipement fixe, configurer et tester les Clientless Users montre l’attribution avec la vérification dans Live Users et le test négatif.
• L’utilisateur est visible, mais une autre règle s’applique : Comparer la position de la règle, la condition de groupe ou une règle plus générale située au-dessus.
• Seuls les utilisateurs VPN sont concernés : Vérifier la zone VPN, le pool VPN, le Source network et le matching de groupe.
• Seuls certains utilisateurs sont concernés : Comparer l’UPN, l’adresse e-mail, le groupe d’annuaire importé et le groupe Sophos Firewall.

Pour les environnements AD locaux, consulter Configurer STAS sur Sophos Firewall et Ajouter Active Directory à Sophos Firewall. Selon le chemin de connexion Entra, utiliser Entra ID SSO pour Sophos Connect et VPN Portal ou Entra ID SSO pour Captive Portal. Avec un très grand nombre d’utilisateurs détectés ou de Clientless Users, la limite User ID de Sophos Firewall peut également être pertinente.

Vérifier DNS, FQDN, CDN et IPv6

Pour le matching de la règle, l’IP de destination réellement utilisée compte, et pas seulement le nom d’hôte saisi. Le cache DNS, Split DNS, les services CDN, un autre résolveur, des destinations API supplémentaires ou IPv6 peuvent diriger le flux vers une autre adresse.

Le firewall résout lui-même les FQDN Hosts normaux et met à jour l’association en fonction du TTL DNS. Les FQDN génériques fonctionnent différemment : le firewall apprend les adresses IP des sous-domaines correspondants à partir des réponses DNS observées. Si le client utilise un résolveur externe, son trafic DNS UDP sur le port 53 doit traverser le firewall. Si la réponse concernée n’est pas visible pour le firewall, l’IP du sous-domaine peut manquer dans l’objet générique et la règle ne pas s’appliquer malgré un nom apparemment correct.

En outre, les FQDN Hosts ne prennent pas en charge la résolution IPv6. Avant d’élargir un objet, comparer la réponse DNS, l’IP de destination et la version IP avec Log Viewer ou Packet Capture. Les détails sur le TTL, les wildcards et le comportement d’apprentissage sont décrits dans FQDN Hosts et Wildcard FQDN sur Sophos Firewall. Pour la résolution interne, consulter DNS Request Routes ; un environnement IPv6 actif nécessite ses propres règles adaptées et un concept IPv6 défini.

Distinguer les modules de sécurité et Traffic Shaping

Si la Firewall Rule ID, la NAT Rule ID et le routage sont corrects, un module attribué à la règle peut influencer l’application :

• Web Policy et Application Control
• SSL/TLS inspection rule et Decryption Profile
• IPS Policy et Malware Scan
• Zero-Day Protection
• Security Heartbeat

Un seul module est isolé à la fois pour le flux concret et pendant une courte période de test. Une exception reste limitée à la source, à la destination et au service ; ensuite, la protection d’origine est rétablie ou l’exception nécessaire est documentée. Pour les problèmes HTTPS, consulter le déploiement contrôlé de TLS Inspection.

Traffic Shaping est en revanche une fonction QoS. Elle garantit, priorise ou limite la bande passante et peut ainsi provoquer un faible débit, des pertes de paquets en cas de congestion ou des timeouts. Ce n’est pas la même chose que la décision d’accès Drop ou Reject. Pour un blocage réel, vérifier le statut de Packet Capture, Reason et le module de sécurité responsable. Pour les transferts volumineux ou les connexions VPN, inclure également MTU et MSS dans l’analyse.

Tester et documenter les modifications de manière contrôlée

En cas de problème de règle, ne modifier qu’une variable par test :

1. Noter l’état initial avec la source, la destination, le service, l’utilisateur, l’heure, la Rule ID et la NAT ID.
2. Modifier exactement une position de règle, un objet, un service ou un module.
3. Pour le NAT, établir une nouvelle connexion ; sinon, déclencher à nouveau le même flux de test.
4. Comparer Log Viewer et Packet Capture avec les mêmes filtres.
5. Documenter le succès ou l’échec, puis seulement examiner la modification suivante.

Les règles temporaires Allow, Drop ou d’exception reçoivent un nom compréhensible, un Owner et une date d’expiration. Sans cela, une aide de diagnostic à court terme peut rapidement rester en permanence dans l’ensemble de règles.

Si la connexion fonctionnait encore hier, les dernières modifications de configuration doivent également être contrôlées. Audit Trail Logs indique qui a modifié des règles ou des objets. Config Studio aide à comparer des configurations plus importantes. Si la modification provient de Sophos Central, contrôler également la Central Firewall Task Queue.

Liste de contrôle pour le dépannage des règles

• Un flux de test concret avec source, destination, service, utilisateur et heure a été défini.
• Il a été vérifié s’il s’agit de trafic de transit ou d’un service local du firewall.
• La position des règles, les règles automatiques et les filtres masqués de la table ont été contrôlés.
• Tous les champs de matching ont été comparés au flux réel.
• Le volume de données a uniquement été utilisé comme indice, et non comme compteur de correspondances.
• Log Viewer affiche la Firewall Rule ID réelle et, le cas échéant, la NAT Rule ID.
• Le résultat de Policy Tester a été comparé à la version du firmware et aux données de paquets réelles.
• Packet Capture fonctionne avec un filtre de capture adapté et un tampon disponible.
• Incoming, Forwarded, Consumed, Generated, Violation, Reason et les interfaces ont été correctement interprétés.
• Pour le DNAT, la zone de destination après NAT, le Destination Network avant NAT et les deux services PAT ont été vérifiés.
• Une nouvelle connexion a été établie après les modifications NAT.
• La réponse DNS, l’IP de destination, le comportement d’apprentissage FQDN et la version IP ont été contrôlés.
• La connexion utilisateur et le User Matching du flux de données ont été vérifiés séparément.
• Le routage, le SD-WAN, la passerelle et le chemin de retour n’ont été examinés qu’après confirmation du match de la règle.
• Les modules de sécurité ont été vérifiés séparément et Traffic Shaping en tant que QoS.
• Chaque modification a été documentée ; les règles de test ont un Owner et une date d’expiration.

FAQ