Sophos Firewall : bit TCP réservé invalide dû à Accurate ECN

Lorsque Sophos Firewall rejette un trafic TCP légitime avec Invalid TCP reserved bit, Accurate ECN peut en être la cause. Une règle Allow supplémentaire ou une exception dans le filtre Web ne résout alors rien, car le rejet intervient dès la validation TCP stricte.

Sophos indique comme contournement la désactivation globale de strict-policy. Cette modification ne doit être effectuée qu’après avoir obtenu une preuve claire : elle s’applique à l’ensemble du pare-feu et ne relâche pas uniquement le contrôle du flux concerné.

Identifier l’erreur sans ambiguïté

Le contournement convient uniquement si toutes les conditions suivantes sont réunies :

Une connexion TCP déterminée échoue de manière reproductible ou ne s’établit pas.
Log Viewer ou Packet Capture indique Invalid TCP reserved bit comme motif du rejet.
La règle de pare-feu, NAT et le routage correspondent au chemin de trafic attendu.
Une règle Allow plus permissive ne modifie pas le comportement.
La capture de la négociation TCP montre AE, CWR et ECE positionnés sur le SYN initial rejeté. AE était auparavant nommé NS et reste étiqueté NS par Sophos et les anciens décodeurs.

Pour le premier test, ouvrir Log viewer en haut à droite de Web Admin, sélectionner le module Firewall, puis limiter les résultats selon la période, l’adresse IP source et l’adresse IP de destination avec Timer filter et Add filter. Rechercher aussi Invalid TCP reserved bit en texte libre. Une session interrompue ne s’affiche toutefois pas forcément immédiatement : Sophos Firewall journalise normalement les sessions de pare-feu à leur fermeture.

Il faut donc confirmer le motif du rejet sous Diagnostics > Packet capture. Sous Configure, ce filtre BPF limite par exemple l’affichage à deux adresses de documentation et à HTTPS :

host 192.0.2.10 and host 198.51.100.20 and port 443

Remplacer les deux adresses IP et le port par les valeurs de la connexion défaillante. Activer Trace On, déclencher une seule tentative de connexion, puis arrêter la capture. Dans Display filter, sélectionner Status: Violation et Reason: INVALID_TRAFFIC. SFOS confirme ainsi la violation et le motif Invalid TCP reserved bit ; utiliser la vue WebAdmin uniquement pour cette confirmation.

Pour analyser l’intégralité de la négociation TCP et des indicateurs, effectuer séparément via SSH une capture tcpdump limitée dans le temps et filtrée par hôtes et port. L’enregistrer au format PCAP, puis l’ouvrir dans Wireshark ou un autre décodeur. Suivre la procédure Collecter les journaux avec l’outil tcpdump de Sophos Firewall. La version actuelle de Wireshark utilise le champ d’affichage tcp.flags.ae ; tcp.flags.ns est l’ancienne terminologie.

Si le motif de rejet précis manque, strict-policy ne doit pas être désactivé par précaution. Il faut d’abord tester la règle de pare-feu, NAT et le flux de paquets.

Pourquoi Accurate ECN est considéré comme invalide

Explicit Congestion Notification, ou ECN, signale une congestion sans rejeter un paquet dans ce seul but. Accurate ECN étend ce mécanisme et nomme désormais AE le bit autrefois appelé NS. Sophos NC-169842 et les anciens décodeurs utilisent encore le nom NS.

La capture de la négociation TCP est indispensable pour reconnaître la signature du problème connu : le SYN initial rejeté comporte SYN ainsi que AE (anciennement NS), CWR et ECE. Si le SYN est transmis, examiner le SYN/ACK pour établir si la négociation Accurate ECN a réussi. AE/NS seul n’est pas concluant. Dans un flux établi, les combinaisons de AE, CWR et ECE forment le compteur ACE au lieu de conserver la signification historique de chaque indicateur. Voir la section 3.1.1 de la RFC 9768 et la section 3.2.2.

Sophos indique sous NC-169842 que la validation stricte des paquets peut interpréter le bit AE, qu’il appelle encore NS, comme un bit TCP réservé positionné et rejeter le trafic. Le journal affiche donc Invalid TCP reserved bit, bien que l’émetteur utilise ces bits pour Accurate ECN. La définition du problème vérifiée pour cette procédure identifie ECE, CWR et NS (désormais AE) comme signature et propose deux possibilités : générer un trafic dépourvu de ces bits Accurate ECN ou désactiver en CLI le contrôle TCP Strict Policy.

Cette procédure est volontairement limitée à la seule version alors identifiée comme affectée : SFOS 21.5.0 GA Build 171 (21.5.0.171) ; aucune version corrective n’était indiquée. L’aide de SFOS 22.0 documente toujours le paramètre strict-policy, mais cela n’établit pas que NC-169842 affecte aussi SFOS 22.0. Sur un autre build, n’utiliser le contournement qu’après avoir vérifié la signature complète et ouvrir d’abord un dossier auprès du support avec la capture et l’extrait du journal. Si les notes de version d’un build plus récent indiquent explicitement que NC-169842 est corrigé, préférer cette mise à jour testée au maintien du contournement global.

Vérifier Strict Policy

Les commandes s’exécutent à l’invite console> de la Device Console, et non dans l’Advanced Shell :

Se connecter au pare-feu par SSH ou via la console locale.
Dans le menu principal, sélectionner 4. Device Console.
Afficher l’état actuel :

show advanced-firewall

Rechercher cette ligne dans la sortie :

Strict Policy                  : on

La sortie complète contient d’autres paramètres globaux du pare-feu. Ils ne doivent pas être modifiés pour ce test. Si l’accès n’est pas encore configuré, consulter Se connecter à Sophos Firewall par SSH.

Dans SFOS 22.0, on est la valeur par défaut documentée. Pour le retour arrière, c’est néanmoins la valeur actuelle qui vient d’être relevée avec show advanced-firewall qui fait foi. Si elle vaut déjà off, le contournement est déjà actif : ne rien basculer et analyser plutôt le cas avec Sophos Support. Contrôler les Advanced Firewall Settings en toute sécurité explique les autres valeurs ainsi que la référence initiale, le test de contrôle et le retour arrière.

Tester le contournement de manière contrôlée

⚠️ Effet sur la sécurité : strict-policy off désactive globalement la validation stricte des paquets. Sophos Firewall ne rejette alors plus, au moyen de ce contrôle, certains modèles de paquets inhabituels ou potentiellement dangereux. La commande ne crée pas d’exception pour une adresse IP, un domaine ou une règle de pare-feu particulière.

Avant la modification, sauvegarder un état actuel de la configuration, documenter le cas de test concerné et prévoir une fenêtre de maintenance. Exécuter ensuite :

set advanced-firewall strict-policy off

Vérifier le nouvel état :

show advanced-firewall

Ligne attendue :

Strict Policy                  : off

Tester maintenant uniquement le flux documenté précédemment. S’il fonctionne immédiatement et si Invalid TCP reserved bit disparaît, cela confirme que Strict Policy provoque le rejet. Seule une négociation capturée montrant SYN ainsi que AE/NS, CWR et ECE sur le SYN initial rejeté rattache le rejet à la signature de NC-169842.

Si l’erreur reste inchangée, réactiver immédiatement strict-policy. La cause se situe alors probablement ailleurs dans le flux de paquets.

Réactiver Strict Policy

Si la valeur relevée avant la modification était on, la commande de retour est :

set advanced-firewall strict-policy on

Utiliser ensuite de nouveau show advanced-firewall pour vérifier que Strict Policy : on s’affiche, puis contrôler le cas de test et le trafic normal. Si le SYN initial répété contient la même signature AE/NS, CWR et ECE et suit le même chemin, Invalid TCP reserved bit devrait réapparaître. Sinon, comparer les indicateurs de la négociation et le chemin avant de tirer une conclusion du test de contrôle.

Même si le contournement fonctionne, strict-policy off ne doit pas devenir un état permanent sans évaluation. L’ordre à privilégier est le suivant :

Vérifier si l’émetteur, le système d’exploitation, l’application ou le service en amont peut désactiver Accurate ECN ou le négocier différemment.
Vérifier si les notes des versions de maintenance SFOS disponibles mentionnent explicitement un correctif pour NC-169842.
Solliciter Sophos Support en fournissant la version SFOS, l’horodatage, la source et la destination, le motif du rejet ainsi que Packet Capture.
Uniquement si aucune solution plus ciblée n’est possible, maintenir la modification globale après acceptation du risque, avec une surveillance et une procédure de retour documentée.

Les éléments nécessaires peuvent être rassemblés avec Enregistrer les journaux Sophos Firewall pour un dossier de support.

Ce qui ne résout pas le problème

Une règle de pare-feu plus large : La validation TCP stricte ne correspond pas au matching normal des règles.
Des exceptions Web ou TLS : Le rejet peut intervenir avant le traitement par ces politiques.
Une exception IPS par précaution : Pour NC-169842, Sophos désigne explicitement Strict Policy comme cause et contournement.
La désactivation globale sans état de référence : Sans test avant-après reproductible, rien ne prouve qu’Accurate ECN était la cause.