Sophos Firewall v22 MR3 : IPsec et 16 correctifs

Sophos a publié Sophos Firewall OS 22.0 MR3 Build 576 le 16 octobre 2026. Après les nouveautés fonctionnelles de v22 MR2, cette version se concentre sur une mise à jour de maintenance plus limitée : les notes de version officielles recensent 16 problèmes corrigés. Elle ajoute également un nouveau paramètre pour les connexions IPsec site à site avec des équipements tiers.

Pour préparer la mise à jour, il faut avant tout tenir compte des services utilisés sur chaque pare-feu. Un site disposant de plusieurs équipements VPN distants nécessite des tests de validation différents de ceux d’un pare-feu avec Mail Protection ou d’un cluster HA. MR3 doit donc être évaluée en fonction de la configuration en place et installée pendant une fenêtre de maintenance planifiée.

IPsec avec des équipements tiers : tunnel établi, trafic absent

MR3 ajoute une commande permettant de désactiver les vérifications strictes des politiques pour les connexions IPsec site à site. Elle concerne les équipements distants qui utilisent la même Security Association (SA) pour plusieurs paires de sous-réseaux. Dans ce cas, le trafic entrant pouvait être rejeté lorsqu’il ne correspondait pas à la SA attendue.

Pour simplifier, une SA décrit les paramètres de sécurité d’une connexion IPsec. Un tunnel établi ne prouve donc pas à lui seul que tous les réseaux prévus peuvent communiquer entre eux. En présence de plusieurs réseaux locaux et distants, la validation doit couvrir chaque combinaison nécessaire.

Cette nouvelle option ne justifie pas de désactiver la vérification partout par précaution. Il convient d’abord de suivre la procédure de dépannage IPsec afin de déterminer si les symptômes correspondent réellement à un problème d’association avec la SA. Le routage, les règles de pare-feu et le NAT restent des causes possibles lorsqu’un tunnel ne transporte aucune donnée utile. Notre article KB Paramètres VPN globaux décrit la syntaxe, la portée et l’utilisation contrôlée de ipsec-strict-policy-check dans la section consacrée à la vérification stricte des politiques IPsec.

Pour obtenir un test fiable, les connexions doivent être initiées dans les deux sens. Les captures de paquets et les compteurs des tunnels concernés permettent de distinguer une absence de trafic entrant, des paquets rejetés et un chemin de retour manquant.

Les correctifs les plus importants en exploitation

Les points suivants constituent une sélection des notes de version officielles :

• NC-186809, HA : la synchronisation des certificats pouvait rendre WebAdmin et VPN Portal inaccessibles.
• NC-186075, réseau : les ports RJ45 perdaient temporairement la liaison avec certains commutateurs.
• NC-182635, Application Control : des mises à jour répétées des chemins d’applications provoquaient une charge CPU élevée.
• NC-181808, RED : des entrées RED_DEVICE_DROP obsolètes bloquaient le trafic après un nouveau déploiement.
• NC-183979, e-mail : une file d’attente de messages volumineuse prolongeait le redémarrage lors de la mise à jour vers MR2.
• NC-180464, DNAT : le trafic SMTP était rejeté à tort après une mise à jour.
• NC-184117, STAS : des utilisateurs déjà authentifiés se voyaient à nouveau présenter la page de connexion du portail captif.
• NC-182222, SSL VPN : les noms d’utilisateur numériques empêchaient les connexions après la mise à jour vers MR1.

Les autres entrées concernent les filtres utilisateur, les erreurs Syslog, la création d’AP VXLAN, la désactivation HA, IPsec, les bases de signatures et les rapports PDF.

En pratique, cette liste doit servir à établir une courte série de tests de validation propre à chaque site. Pour HA, elle doit inclure l’accès à l’interface d’administration et à VPN Portal ainsi que l’état de synchronisation. Sur les sites RED, il convient de tester une application réelle à travers la connexion. Pour une passerelle de messagerie, la remise des messages entrants et sortants ainsi que la file d’attente sont plus révélatrices qu’un ping réussi.

En cas de problèmes de CPU, une comparaison avant et après la mise à jour sous une charge similaire est également utile. La présence d’un correctif correspondant dans les notes de version constitue un indice, mais ne prouve pas encore que la cause d’un incident précis a été identifiée.

Config Studio 2.7 facilite les modifications ciblées

Parallèlement au firmware, Sophos présente Config Studio 2.7. Cet outil distinct, accessible dans le navigateur, permet d’afficher des modifications ciblées et de les exporter au format XML ou TAR. Les requêtes API peuvent également être limitées aux objets ajoutés, modifiés et supprimés. Cette version apporte aussi des corrections à la comparaison des configurations, à l’assistant d’exceptions web et au calcul des tunnels SD-WAN.

L’intérêt se situe notamment au niveau de la revue : un petit ensemble de modifications est plus facile à vérifier qu’un export complet de la configuration. Avant un import, il reste toutefois nécessaire de vérifier quels objets dépendants doivent déjà exister sur le système cible. Un export réduit ne remplace ni une sauvegarde ni les tests fonctionnels qui suivent. Notre article sur Config Studio 2.6 présente les fonctions disponibles jusqu’ici.

Notre article KB Planifier la mise à jour du firmware décrit la préparation, avec le chemin de mise à jour, la sauvegarde et la fenêtre de maintenance. Les différentes étapes dans WebAdmin et via Sophos Fusion, ainsi que les vérifications après la mise à jour et le retour à la version précédente, sont détaillées dans Effectuer une mise à jour du firmware Sophos Firewall.