Comprendre et configurer en toute sécurité les règles Sophos Firewall

Une règle Sophos Firewall détermine quel trafic entre les zones, les réseaux, les utilisateurs et les services est autorisé ou bloqué. L’objectif n’est pas d’activer le plus d’options possible, mais de choisir des critères de correspondance adaptés, le bon ordre, des fonctions de protection appropriées et un test reproductible.

Le chemin du menu est le suivant :

Rules and policies > Firewall rules > Add firewall rule > New firewall rule

Cet article explique le formulaire de règle de haut en bas et utilise systématiquement l’exemple LAN_to_WAN_Clients. Les sujets spécialisés tels que NAT, TLS Inspection ou IPS sont expliqués dans la mesure nécessaire pour la règle de pare-feu ; les guides détaillés sont liés à l’endroit approprié.

Planifier avant de créer la règle

Identifier le bon point de contrôle

Les règles de pare-feu normales contrôlent le trafic transféré qui traverse le pare-feu. D’autres tâches se configurent ailleurs :

• Services locaux du pare-feu : WebAdmin, User Portal, VPN Portal, SSH, DNS et SNMP sont contrôlés via Administration > Device access, Local Service ACL et la configuration du service concerné. Voir Device Access et Local Service ACL.
• Trafic généré par le système : les connexions initiées par le pare-feu lui-même ne nécessitent pas de règle de pare-feu normale. Les éléments déterminants sont la configuration du service, le routage, WAN Link Manager et, le cas échéant, SD-WAN pour le trafic système.
• Traduction d’adresses et de ports : NAT traduit le trafic, mais ne l’autorise pas. La règle de pare-feu et la règle NAT doivent fonctionner ensemble.
• Routage et chemin de retour : une règle de pare-feu correspondante ne prouve pas que le routage, SD-WAN, VPN ou le chemin de retour sont corrects.
• Logique Web : les catégories Web, les groupes d’URL et les actions sont définis dans la Web Policy. La règle de pare-feu applique cette politique.
• Déchiffrement HTTPS : une SSL/TLS inspection rule déchiffre le trafic. Scan HTTP and decrypted HTTPS analyse uniquement le trafic HTTPS déjà déchiffré.
• Identité de l’utilisateur : AD SSO, STAS, Captive Portal, Entra ID SSO ou RADIUS doivent d’abord associer l’utilisateur au trafic de manière fiable. Les équipements sans connexion peuvent être configurés comme Clientless Users avec une IP fixe et sans ambiguïté ; cette attribution n’est pas une authentification.

Les accès d’administration qui passent à travers le pare-feu vers des serveurs, des commutateurs ou des hyperviseurs relèvent des règles de pare-feu normales. L’accès au pare-feu lui-même relève en revanche de Device Access.

Ordre des règles, IPv4 et IPv6

Sophos Firewall évalue les règles de haut en bas. Dès que tous les critères de correspondance d’une règle sont satisfaits, les règles suivantes ne sont plus évaluées. Une règle générale LAN_to_WAN_Any placée au-dessus de LAN_to_WAN_Restricted rend donc la règle spécifique inopérante.

Une règle peut notamment établir une correspondance selon Source zone, Source network, la planification, Destination zone, Destination network, Service, l’utilisateur et les Exclusions. Tous les critères configurés doivent correspondre à la connexion.

Les règles MTA, IPsec ou Hotspot générées automatiquement peuvent apparaître en haut de la liste. Il faut donc vérifier à nouveau l’ordre après un assistant, une migration ou une modification VPN. Pour un hotspot Sophos Firewall, ce contrôle fait explicitement partie de la procédure de configuration. Si SFOS ne trouve aucune règle correspondante, la règle implicite drop-all avec le Firewall Rule ID #0 s’applique en bas de la liste. Elle n’affiche aucun Usage Count ; le trafic abandonné est journalisé en tant qu’événement.

Les règles IPv4 et IPv6 sont gérées séparément. Une règle IPv4 fonctionnelle ne protège pas automatiquement le même service via IPv6. Dans les environnements dual-stack, les deux ensembles de règles doivent être planifiés et testés de manière délibérée.

Séparer clairement la base de règles

Avant de créer une règle, il faut définir sa Source, sa Destination, ses Services, son Owner et son cas de test. Des risques différents ne doivent pas être regroupés dans une règle fourre-tout :

• Accès Internet des clients : réseaux clients vers la zone WAN, avec une Web Policy adaptée, Application Control, IPS et la journalisation.
• Accès Internet des serveurs : uniquement les destinations de mise à jour, de sauvegarde ou de cloud nécessaires, généralement sans correspondance utilisateur.
• Wi-Fi invité : zone Guest vers Internet, sans destinations internes et, si nécessaire, avec une limite de bande passante.
• Administration : réseaux d’administration définis vers les serveurs et l’infrastructure, séparés du trafic client normal.
• Remote Access VPN : zone VPN vers les destinations et services internes réellement nécessaires.
• Site-to-site : réseaux locaux et distants avec le routage, NAT et le chemin de retour appropriés.
• Systèmes publiés : WAN vers une DMZ ou une zone de serveurs avec une source étroitement limitée, DNAT ou WAF, IPS, journalisation et un niveau de correctifs actuel.
• Accès temporaires : règle distincte avec un ticket, un Owner, une date d’expiration et un retrait planifié.

Pour structurer le réseau, voir Configurer les zones et les interfaces de Sophos Firewall.

⚠️ Any peut être utile pour un test rapide, mais constitue rarement une bonne configuration finale. Il faut ensuite limiter la règle aux sources, destinations et Services réellement nécessaires, ou la supprimer.

Exemple pratique : LAN_to_WAN_Clients

Dans cet exemple, les clients d’un LAN défini sont autorisés à accéder à Internet. Les serveurs, les invités, la VoIP et l’administration utilisent des règles distinctes.

• Rule name: LAN_to_WAN_Clients
• Description: Accès Internet pour le réseau client. Web Filtering, App Control et IPS activés. Owner IT, révision 2026-12-01.
• Rule position: Bottom, puis placer la règle sous les règles spécifiques de blocage et d’exception
• Rule group: Internet Access
• Action: Accept
• Log firewall traffic: activé
• Source zones: LAN
• Source networks and devices: net_LAN_Clients
• During scheduled time: All the time
• Destination zones: WAN
• Destination networks: Any
• Services: HTTP, HTTPS et uniquement les services de base effectivement consultés directement sur Internet
• Web policy: Default Workplace Policy
• Block QUIC protocol: activé
• IPS: politique client appropriée
• App control: politique d’application client appropriée
• Shape traffic: uniquement pour un objectif concret de bande passante
• DSCP marking: uniquement si les appareils en aval traitent le marquage

DNS et NTP ne doivent être ajoutés à cette règle LAN-to-WAN que si les clients communiquent directement avec des résolveurs ou des serveurs de temps externes. S’ils utilisent le pare-feu comme service DNS ou de temps, il s’agit d’un trafic local.

Le test d’acceptation doit utiliser un client défini, une destination précise, le Firewall Rule ID attendu, le NAT Rule ID attendu et le Log Viewer. Cela confirme non seulement que l’application fonctionne, mais aussi que les règles prévues traitent la connexion.

Configurer la règle de pare-feu

En-tête

Rule status, Rule name et Description

Rule status est activé par défaut pour une nouvelle règle. Les règles préparées à l’avance peuvent rester désactivées jusqu’à la fenêtre de maintenance. Les règles de test ou de migration désactivées en permanence doivent être révisées régulièrement.

Le nom doit faire apparaître la Source, la Destination et l’objectif, par exemple :

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

La Description documente l’objectif, l’Owner, le ticket, les restrictions et, le cas échéant, la date d’expiration. Des noms comme Rule1, Allow ou Internet sont peu utiles lors de l’exploitation ultérieure. Voir Documenter clairement les règles Sophos Firewall pour la méthode Avanet.

Rule position et Rule group

Lors de la création d’une règle, Rule position propose Top ou Bottom dans SFOS 22. Après l’enregistrement, la règle peut être déplacée dans le tableau ou positionnée précisément avec Move To. Il ne faut utiliser Top que lorsqu’une règle spécifique doit délibérément prendre la priorité sur des règles existantes.

Rule group améliore la lisibilité, mais ne modifie pas la logique de correspondance. None est la valeur par défaut. Avec Automatic, SFOS affecte la règle à un groupe existant en fonction du premier type de règle correspondant ainsi que des zones Source et Destination. Le pare-feu continue d’évaluer chaque règle de haut en bas.

Action et journalisation

Action détermine la manière dont le trafic correspondant est traité :

• Accept: autorise la connexion.
• Drop: abandonne normalement le trafic sans envoyer de réponse. Si Use web authentication for unknown users est activé, SFOS peut afficher à la place une page de blocage pour le trafic Web.
• Reject: la rejette et envoie un reset TCP ou une réponse ICMP appropriée pour UDP et ICMP.
• Protect with web server protection: crée une règle WAF. Cette option est disponible uniquement pour IPv4 et nécessite Webserver Protection. La configuration est expliquée dans Sophos Firewall WAF.

Drop convient à un abandon silencieux ; Reject fournit un retour plus rapide et plus clair lors de tests internes ou du dépannage.

Log firewall traffic doit être activé pour les règles importantes. Les destinations locales, Sophos Central ou Syslog appropriées doivent également être activées sous System services > Log settings. Sans événement Destroy, une session peut se terminer sans journal de session final, par exemple en cas de coupure brutale de la liaison.

Central Firewall Reporting ou un serveur Syslog/SIEM conviennent à une conservation plus longue. La journalisation ne sert pas uniquement au dépannage, mais aussi aux révisions : quelles sources correspondent à la règle, quelles destinations sont utilisées et l’accès reste-t-il approprié ?

La même case à cocher est la source de données de NetFlow v5 sur Sophos Firewall : sans Log firewall traffic, NetFlow n’exporte pas les connexions de cette règle.

Source, Destination et Services

La section Source définit l’origine du trafic :

• Source zones: par exemple LAN, VPN, DMZ, Guest ou WAN.
• Source networks and devices: hôtes individuels, réseaux, plages IP, groupes, FQDN hosts ou objets pays.
• During scheduled time: All the time, les heures de travail ou une fenêtre de maintenance.

La zone seule est généralement trop large. L’exemple client combine donc LAN avec net_LAN_Clients. Pour les règles planifiées, l’heure du pare-feu, le fuseau horaire et la planification doivent tous correspondre.

Configurer des planifications pour les règles et stratégies Sophos Firewall montre comment créer et affecter des plages récurrentes ou ponctuelles, puis les tester à leurs limites de commutation.

Sous Destination and services, il faut configurer :

• Destination zones: par exemple WAN, DMZ, LAN ou VPN.
• Destination networks: Any, un hôte, un réseau, un groupe, un objet pays ou un FQDN host.
• Services: définitions de protocoles et de ports telles que HTTP, HTTPS, DNS, NTP ou un service personnalisé.

Le guide Utiliser correctement les hôtes et services de Sophos Firewall explique comment créer des IP hosts, réseaux, plages, listes, services et groupes, puis contrôler leurs dépendances avant toute modification.

Any peut être acceptable pour une règle générale d’accès Internet des clients. Les règles de serveur, d’administration et VPN doivent utiliser des destinations et des Services beaucoup plus restrictifs. Pour les destinations cloud dynamiques, les FQDN hosts et wildcard FQDNs peuvent être utiles.

Utilisateurs, Exclusions et Linked NAT

Match known users

Avec Match known users, les utilisateurs ou les groupes deviennent des critères de correspondance. Selon la configuration, d’autres champs deviennent alors disponibles :

• Use web authentication for unknown users: redirige les utilisateurs Web inconnus vers AD SSO ou Captive Portal. L’authentification et l’accès depuis la zone concernée doivent déjà être configurés. Configurer et tester Captive Portal sur Sophos Firewall montre comment interagissent l’authentification, Device Access, le prérequis DNS et la règle utilisateur.
• Users or groups: limite la règle aux identités sélectionnées.
• Exclude this user activity from data accounting: exclut ce trafic utilisateur de la comptabilisation individuelle de la consommation de données.

Une règle utilisateur fonctionne uniquement si l’association de l’utilisateur est fiable. Une règle de repli large placée en dessous ne doit pas autoriser le même trafic sans correspondance utilisateur. Lors du test d’acceptation, l’utilisateur, le groupe et le Rule ID dans le Log Viewer doivent correspondre.

Add exclusion

Add exclusion exclut du trafic de cette règle. SFOS ignore la règle uniquement lorsque tous les critères d’exclusion configurés correspondent, puis évalue la règle suivante.

Les critères disponibles sont Source zones, Source networks and devices, Destination zones, Destination networks et Services.

Une exclusion pertinente peut concerner un serveur de mise à jour exclu d’une règle client générale et traité par une règle distincte placée au-dessus avec d’autres fonctions de protection. Si les Exclusions deviennent nombreuses ou difficiles à comprendre, une règle spécifique distincte est généralement plus claire.

Create linked NAT rule

Une Linked NAT Rule est une règle Source NAT qui s’applique uniquement au trafic traité par la règle de pare-feu liée. La règle NAT définit principalement la Source traduite et la Source translation propre à l’interface.

La configuration d’usine contient normalement une règle Default SNAT avec MASQ. Avant d’ajouter une Linked NAT Rule, il faut vérifier si cette règle traite déjà correctement le trafic. Si une règle NAT indépendante placée plus haut correspond, elle prend la priorité sur la Linked NAT Rule.

Pour DNAT, SFOS détermine d’abord la destination traduite, puis utilise sa zone pour établir la correspondance avec la règle de pare-feu. Une redirection de port vers un serveur de la DMZ nécessite donc généralement Destination zone DMZ dans la règle de pare-feu, même si le client se connecte à l’adresse WAN publique.

Si le NAT Rule ID est inattendu, il faut également vérifier l’ordre sous Rules and policies > NAT rules. Après une modification NAT, une nouvelle connexion doit être créée, car les sessions existantes ne sont pas évaluées à nouveau. NAT n’autorise pas le trafic à lui seul : la règle de pare-feu décide de l’action Accept ou Drop, tandis que NAT traduit les adresses ou les ports. Voir Comprendre NAT sur Sophos Firewall pour les détails.

Sélectionner les fonctions de protection

Toutes les options ne sont pas disponibles avec la Base License. Avant le déploiement, il faut vérifier sous Administration > Licensing :

• Règles de pare-feu normales : Base License
• IPS et Security Heartbeat : Network Protection
• Web Security, Application Control et protection contre les logiciels malveillants Web : Web Protection
• Sandboxing et analyse de fichiers : Zero-Day Protection
• Protection des e-mails : Email Protection
• WAF : Webserver Protection
• NDR Active threat intelligence : Xstream Protection Bundle

Standard Protection et Xstream Protection incluent Web Protection. Le bundle Avanet Epic Protection inclut également Web Protection. Voir Comparer les bundles de licences Sophos Firewall pour la vue d’ensemble complète.

Web Filtering

Web policy applique une Web Policy contenant des catégories, des groupes d’URL, des utilisateurs et des actions. Sans Web Policy, ce champ ne fournit aucun contrôle Web fondé sur les catégories. La politique est créée et testée sous Web Protection.

Apply web category-based traffic shaping utilise les paramètres de bande passante des catégories Web. Cette option est utile uniquement si des limites ou des garanties y sont effectivement configurées.

Block QUIC protocol bloque le trafic UDP sortant sur les ports 80 et 443 pour cette règle. QUIC ne peut pas être analysé comme du trafic HTTP/HTTPS normal et contourne Web Filtering. SFOS active cette option par défaut lorsqu’une Web Policy ou l’analyse des logiciels malveillants est sélectionnée. Voir Bloquer QUIC et HTTP/3 pour les détails.

Scan HTTP and decrypted HTTPS recherche des logiciels malveillants dans le trafic HTTP et HTTPS déjà déchiffré. Cette option n’active pas le déchiffrement. Il faut pour cela une SSL/TLS inspection rule correspondante sous Rules and policies > SSL/TLS inspection rules.

Use Zero-day protection soumet les téléchargements suspects à une analyse supplémentaire après la recherche de logiciels malveillants. Cette fonction nécessite Zero-Day Protection et peut entraîner un délai selon le type de fichier et la politique.

Scan FTP for malware est nécessaire uniquement si la règle autorise FTP. L’analyse doit être testée séparément pour les systèmes legacy.

Use web proxy instead of DPI engine limite le filtrage proxy aux ports habituels 80 et 443. Le Web Proxy est notamment requis pour SafeSearch, les restrictions YouTube, les restrictions de domaine Google Workspace, Pharming Protection, Web Cache et Parent Proxy. En mode DPI, les SSL/TLS inspection rules s’appliquent à HTTP et TLS sur tous les ports.

Configurer un upstream proxy sur Sophos Firewall décrit la chaîne supplémentaire de règles et de NAT d’un parent proxy. Un proxy dans WAN nécessite un chemin différent de celui d’un proxy dans LAN ou DMZ.

En revanche, un client Direct Web Proxy explicitement configuré utilise le listener même sans cette option. Configurer Direct Web Proxy avec un fichier PAC explique la configuration complète avec le port, Device Access, le fichier PAC, la règle et les tests.

Decrypt HTTPS during web proxy filtering appartient au mode Web Proxy. En mode DPI, le déchiffrement est contrôlé par les SSL/TLS inspection rules. Les Web Exceptions peuvent contourner le déchiffrement, l’analyse des logiciels malveillants, Zero-Day Protection et Policy Checks ; elles doivent donc être étroitement limitées et révisées régulièrement.

Synchronized Security Heartbeat

Les règles Heartbeat nécessitent :

• un pare-feu enregistré dans le même compte Sophos Central avec Security Heartbeat activé ;
• un Sophos Endpoint administré avec une licence d’évaluation ou complète ;
• Network Protection sur le pare-feu.

Pour détecter les Heartbeats manquants, il faut sélectionner les zones concernées sous System > Sophos Central > Optional configurations > Missing heartbeat zones.

Minimum source HB permitted et Minimum destination HB permitted définissent un état de santé minimal. Destination Heartbeat convient uniquement aux destinations internes, et non à la zone WAN.

Les options Block clients with no heartbeat et Block request to destination with no heartbeat concernent les appareils sans Heartbeat. Un appareil qui n’a jamais envoyé de Heartbeat reste autorisé par défaut et n’est bloqué que lorsque les deux options sont activées. Il faut tester ce comportement délibérément avec des appareils qui n’exécutent pas Sophos Endpoint.

Une Web Exception qui ignore les Policy checks peut autoriser des requêtes Web malgré Block clients with no heartbeat. Voir Analyser les alertes Security Heartbeat manquantes pour le processus de vérification pratique.

Application Control, IPS et Traffic Shaping

Identify and control applications (App control) applique une Application Filter Policy. Application Control nécessite Web Protection. Pour les micro-applications basées sur des URL dans le trafic chiffré, telles que les chargements et téléchargements de fichiers dans Dropbox ou Gmail, une SSL/TLS inspection rule de déchiffrement appropriée est nécessaire. Les filtres, les journaux et les faux positifs sont expliqués dans Configurer Application Control.

Apply application-based traffic shaping policy utilise la politique de bande passante attribuée à une application ou une catégorie sous Applications > Traffic shaping default. Les Application Objects servent en revanche aux routes SD-WAN. Une Rules policy sélectionnée via Shape traffic façonne tout le trafic traité par la règle de pare-feu. Sophos ne documente pas toujours de manière cohérente la priorité lorsque des politiques Application et Rules sont utilisées ensemble. Pour une conception prévisible, il convient de n’utiliser qu’une méthode par cas d’utilisation et de tester toute combinaison nécessaire sur le build SFOS déployé.

Detect and prevent exploits (IPS) applique une IPS Policy. IPS nécessite Network Protection ou une licence d’évaluation valide et doit être activé globalement sous Intrusion prevention > IPS policies. Le trafic client, serveur, serveur Web et VoIP nécessite des politiques distinctes et testées. Voir Configurer et tester IPS pour un déploiement sûr.

Shape traffic attribue une Traffic Shaping Policy à l’ensemble de la règle, par exemple pour la VoIP, les réunions, les sauvegardes ou les invités. Les garanties et les limites doivent correspondre à la bande passante WAN disponible. Voir Configurer Application Traffic Shaping pour plus d’informations.

DSCP marking marque les paquets pour les commutateurs, les routeurs ou les appareils WAN en aval. Le marquage seul n’établit aucune priorité ; tous les appareils concernés doivent traiter les valeurs DSCP sélectionnées de manière cohérente.

NDR Active threat intelligence

Scan with NDR Active threat intelligence compare le trafic à des signatures NDR sélectionnées. L’action est fixée à Log threats : la fonction détecte et journalise les événements, mais ne bloque pas le trafic.

Les conditions requises sont les suivantes :

• Xstream Protection Bundle ;
• activation globale de NDR Active threat intelligence ;
• journalisation IPS activée ;
• sélection de l’option dans chaque règle de pare-feu concernée.

Les déploiements XGS, virtuels, logiciels et cloud courants sont pris en charge, à l’exception des XGS 87, 87w, 88 et 88w. XDR ou MDR ainsi que le transfert vers Sophos Central sont facultatifs pour une analyse approfondie dans Central.

Scan email content

Sous Scan email content, il est possible de sélectionner IMAP, IMAPS, POP3, POP3S, SMTP et SMTPS. La protection nécessite Email Protection. Si les ports standard sont absents sous Services, ils peuvent être ajoutés via Add ports.

Le trafic de messagerie ne doit pas être dissimulé dans une règle générale d’accès Internet des clients. Une règle de messagerie distincte rend la Source, la Destination, les protocoles, la journalisation et les fonctions de protection plus clairs.

Tester et exploiter la règle

Test d’acceptation après l’enregistrement

Après l’enregistrement, la règle n’est terminée que lorsque le cas de test défini produit les résultats attendus :

Il ne faut effectuer qu’une seule modification par test afin de pouvoir associer clairement la cause et l’effet.

1. Vérifier la position de la règle et le Rule group.
2. Vérifier Log firewall traffic et les destinations sous System services > Log settings.
3. Générer exactement une connexion de test depuis un client défini vers une destination et un Service définis.
4. Vérifier le Firewall Rule ID, le Rule name, l’utilisateur et l’Action dans le Log Viewer.
5. Vérifier le NAT Rule ID et les adresses traduites.
6. Vérifier DNS et le routage séparément.
7. Valider la Web Policy, Application Control, IPS et TLS Inspection par rapport à l’action attendue.
8. Rechercher des rejets inattendus, des erreurs SSL/TLS ou des problèmes de performance.
9. Supprimer la règle de test ou la limiter aux objets de production.

Voir Tester une règle Sophos Firewall pour la procédure avec Policy Test, Log Viewer et Packet Capture.

Nouvelle règle, règle existante ou désactivation

Une règle existante peut être étendue si la Source, la Destination, l’objectif, l’Owner et la protection nécessaire restent identiques. Une règle distincte est préférable lorsque la journalisation, la date d’expiration, les Security Features, les responsabilités ou les cycles de révision diffèrent.

Les accès d’assistance temporaires, les serveurs, les invités, la VoIP, l’IoT et l’administration ne doivent pas disparaître dans une règle client générale. Pour les anciennes règles peu claires, une désactivation contrôlée est généralement plus sûre qu’une suppression immédiate :

1. Clarifier l’objectif, l’Owner et les dépendances.
2. Définir la journalisation et la fenêtre de test.
3. Informer les équipes concernées.
4. Désactiver la règle et exécuter les tests définis.
5. La supprimer uniquement après une période d’observation traçable.

Une règle d’urgence rarement utilisée peut être importante. Inversement, une règle large fréquemment utilisée n’est pas automatiquement sûre.

Compteur de données, révision et suivi des modifications

Reset data transfer count remet à zéro la quantité de données transférées par une règle. Il ne s’agit pas d’un compteur de sessions ou de correspondances. L’état Unused signifie uniquement qu’aucun trafic correspondant n’a été trouvé au cours des dernières 24 heures. Les deux indicateurs doivent être évalués avec les journaux, la description de la règle et le cas d’utilisation. Reports > Dashboards > Traffic dashboard > Allowed policies permet également d’analyser les données transférées.

Les révisions régulières doivent au minimum contrôler :

• Source, Destination et Services ;
• les objets Any restants ;
• l’Owner, le ticket et la date d’expiration ;
• la journalisation et l’utilisation réelle ;
• NAT, Web Policy, IPS, TLS Inspection et les autres fonctions de protection ;
• les règles désactivées, temporaires et générées automatiquement.

Une sauvegarde doit être disponible avant toute modification importante. Audit Trail Logs et Config Studio montrent les modifications de configuration. Pour les groupes gérés via Central, la Firewall Management Task Queue confirme que la modification est arrivée sur la bonne appliance. Le Firewall Health Check complète la révision de sécurité régulière.

Erreurs typiques

• La règle attendue ne correspond pas ou le Rule ID #0 apparaît : vérifier l’ordre, IPv4/IPv6 et tous les critères Source, Destination, Service, utilisateur et Exclusion.
• Le Firewall Rule ID est correct, mais le NAT Rule ID ou le chemin des paquets ne l’est pas : vérifier l’ordre NAT, le routage, SD-WAN et le chemin de retour.
• La règle correspond, mais la protection est absente ou l’application échoue : vérifier individuellement la licence, l’activation globale, la journalisation, la Web Policy, QUIC, TLS Inspection, IPS et la Traffic Shaping Policy.

Si le Rule ID, le NAT ID ou le chemin des paquets est inattendu, La règle Sophos Firewall ne correspond pas fournit une procédure structurée de recherche des causes.