Sophos Firewall SFOS 22 : vérifier les blocages

Avant une mise à niveau vers SFOS 22, il faut vérifier que la plateforme, le chemin de mise à niveau et la configuration prennent en charge la version cible. Ce contrôle complète le périmètre précédent de SFOS 22.0 MR2 Build 546 du 14 juillet 2026 avec les notes de version de 22.0 MR3 Build 576 du 16 octobre 2026 et accompagne le guide général sur la mise à jour du firmware Sophos Firewall.

Blocages stricts de mise à niveau et de restauration

• Matériel XG ou SG : SFOS 22 n’est pas pris en charge. Au lieu d’une mise à niveau, il faut migrer vers une XGS Appliance ou vers une plateforme virtuelle, logicielle ou cloud.
• Legacy Remote Access IPsec : À partir de SFOS 22.0 MR1, la configuration doit être migrée ou supprimée avant la mise à niveau.
• Legacy CLI VLAN Tagging sur une interface bridge : À partir de SFOS 22.0 MR2, system vlan-tag doit être remplacé par des interfaces VLAN prises en charge.
• Sauvegarde avec Legacy VLAN Tagging : Pour une restauration sur SFOS 22.0 GA ou une version ultérieure, il faut nettoyer la configuration source et créer une nouvelle sauvegarde.
• Stockage ou chemin de mise à niveau : Si la page du firmware signale un espace insuffisant ou un chemin de mise à niveau non valide, il faut d’abord corriger la cause.

Si un blocage s’applique ou si un point reste incertain, la mise à niveau ne doit pas être lancée.

Les blocages ci-dessus doivent être distingués des avis suivants : NC-177529, NC-181885 et NC-184583 ne concernent que la version ou la fonction indiquée. Le cas Let’s Encrypt ci-dessous est un signalement non confirmé, et non un blocage général publié par Sophos.

Définir la version cible et le chemin de mise à niveau

État au 21 octobre 2026 : SFOS 22.0 MR3 Build 576 est publié. Depuis ce build, une mise à niveau vers SFOS 23.0 EAP1 est explicitement impossible. Pour préparer un pilote v23, il faut donc clarifier la suite du chemin de version avant de passer à MR3 ; la règle générale « d’abord la dernière v22, puis v23 » est fausse pour EAP1. Cela ne constitue pas une recommandation de renoncer à des correctifs nécessaires en production au profit d’un test EAP.

La liste suivante documente toujours uniquement le chemin direct vers MR2 Build 546. Pour MR3 ou une cible ultérieure, il faut vérifier la matrice de mise à niveau propre au build cible exact ; cette liste MR2 ne vaut pas validation pour ces versions.

Chemin de mise à niveau direct vers SFOS 22.0 MR2

Pour la cible traitée ici, SFOS 22.0 MR2 Build 546, Sophos prend en charge une mise à niveau directe depuis les versions suivantes :

• SFOS 22.0 : MR1 Build 490 ainsi que GA Build 411 ou 365
• SFOS 21.5 : MR2 Build 323, MR1 Build 261 ou GA Build 171
• SFOS 21.0 : MR2 Build 349, MR1 Build 277, 272 ou 237 ainsi que GA Build 169
• Versions antérieures : toute version de SFOS 20.0, 19.5 ou 19.0

⚠️ Si la version actuelle ne figure pas dans cette liste, l’avertissement concernant une migration non prise en charge ne doit pas être confirmé. Sinon, le pare-feu redémarre avec les paramètres d’usine et la configuration actuelle est perdue. De même, une sauvegarde ne peut être restaurée qu’à partir d’une version dont la migration de configuration est prise en charge.

Pour une version antérieure ou non répertoriée, il faut d’abord planifier un chemin intermédiaire pris en charge. La liste des versions ne remplace pas non plus les autres contrôles : la plateforme, le stockage, les dépendances anciennes et le plan de restauration doivent également être adaptés.

Contrôles avant la fenêtre de maintenance

Plateforme et dépendances anciennes

• Documenter le modèle et le firmware actuel afin que le chemin de mise à niveau indiqué ci-dessus et une éventuelle restauration restent traçables.
• Traiter le matériel XG et SG comme une migration, pas comme une mise à niveau normale.
• Remplacer les tunnels UTM9 SSL VPN ainsi que les appareils RED 15, RED 15w et RED 50 avant la mise à niveau.
• Sous Network > Interfaces, corriger les noms qui se terminent par dix chiffres ou plus. De tels noms peuvent masquer des interfaces dans WebAdmin après la mise à niveau.

Stockage, sauvegarde et accès

Sous Backup & Firmware > Firmware, relever d’abord Current firmware, la version et le build du slot actif. Sous Latest available firmware, ou pour l’image chargée manuellement, la cible doit correspondre exactement au build validé au préalable. Si le chemin MR2 documenté ci-dessus est expressément retenu, il s’agit de SFOS 22.0 MR2 Build 546 ; pour MR3, sa propre matrice de mise à niveau doit avoir été validée. Download ne fait que télécharger l’image ; Install lance le changement de version. Upload Firmware place une image manuelle dans le slot inactif, tandis que Upload & Boot redémarre immédiatement. Revérifier le build cible, l’action et le slot actif avant de cliquer. Un avertissement sur cette page affiche le champ Reference code.

Le remplissage des partitions peut être contrôlé sommairement dans Advanced Shell :

df -kh

Si la page du firmware affiche un avertissement, la mise à niveau ne doit pas encore être lancée. Le code de référence indique la cause et l’étape suivante :

• FWDS501 : le Primary Disk ou l’une de ses partitions système est trop petit pour SFOS 22. Sur une VM déployée avant SFOS 18, le même état hérité peut d’abord apparaître uniquement sous la forme d’une erreur générique de firmware lors d’une mise à niveau vers SFOS 21.5 ou une version ultérieure (NC-151465) ; ce message seul ne prouve toutefois pas un problème de disque. Pour un pare-feu virtuel, agrandir le Primary Disk avant SFOS 22 montre comment contrôler et agrandir Hard disk 1, puis vérifier le résultat. Le même article fournit les seuils et les solutions adaptés à une Software Appliance.
• FWDS502 : l’espace libre dans /var est insuffisant. Dans 4. Device Console, system firmware check-disk-space indique l’espace nécessaire et les zones de données concernées. Les reports ou logs ne doivent être nettoyés de manière contrôlée qu’après la sauvegarde des données nécessaires ; la procédure est décrite dans Contrôler l’espace et gérer les reports.
• FWDS503 : la partition /content est trop petite. Sophos exige une réinitialisation aux paramètres d’usine avec interruption de service et perte de la configuration actuelle. Après avoir créé une sauvegarde récente et sécurisé le SSMK, saisir RESET en majuscules via la console série et sélectionner l’option 2 ; les configurations personnalisées sont alors supprimées et les signatures de patterns sont réinitialisées à l’état du firmware actif. Restaurer ensuite la sauvegarde, tester les fonctions et effectuer la mise à niveau seulement après ces contrôles. Les reports locaux ne sont pas restaurés.
• FWDS504 : le firmware du SSD est obsolète et doit être mis à jour avant la mise à niveau de SFOS.
• FWDS505 : Sophos Support doit vérifier l’état du SSD. Un contrôle SMART local peut documenter des valeurs pour le support, mais ne lève pas le blocage.

Dans un cluster HA, chaque nœud doit être contrôlé séparément, car les deux appliances peuvent afficher des codes de référence différents.

Avant le démarrage, les éléments suivants doivent également être disponibles :

• une sauvegarde récente stockée en externe et le Secure Storage Master Key correspondant
• un accès administrateur local ou un accès alternatif en dehors du chemin VPN habituel
• un chemin de repli défini avec un responsable et un point de décision
• pour HA, un cluster sain et synchronisé avec des liens HA et des Monitored Ports stables

Les détails sur la sauvegarde et la restauration figurent dans Créer ou restaurer une sauvegarde Sophos Firewall.

Configurations présentant un risque particulier

Legacy Remote Access IPsec

À partir de SFOS 22.0 MR1, une configuration Legacy Remote Access IPsec existante bloque la mise à niveau. Les utilisateurs, pools et profils concernés doivent d’abord être migrés vers la configuration Remote Access IPsec actuelle, SSL VPN, ZTNA ou une autre conception adaptée. La procédure est décrite dans Migrer Legacy Remote Access IPsec avant SFOS 22 MR1.

Microsoft Entra ID SSO avec Same as firewall

SFOS 22.0 ou version ultérieure active automatiquement Microsoft Entra ID SSO pour VPN Portal, Remote Access IPsec et SSL VPN lorsque leur méthode d’authentification est définie sur Same as firewall avant la mise à niveau. Il faut donc consigner les réglages sous Authentication > Services et le fournisseur d’identité réellement attendu avant la fenêtre de maintenance.

Après la mise à niveau, contrôler séparément chaque méthode effective. Si Entra SSO est prévu, la VPN portal and remote access URL exacte de l’objet serveur Entra doit être enregistrée comme Redirect URI dans l’application Entra ; l’URL reverse SSO de Sophos Fusion (anciennement Sophos Central) ne convient pas. Une connexion pilote réelle valide le portail, le client et le MFA. Si le SSO n’est pas prévu, définir explicitement la méthode voulue. La procédure complète figure dans Configurer Microsoft Entra ID SSO pour le VPN Sophos Firewall.

IPsec basé sur des politiques et NAT

Les tunnels Site-to-Site basés sur des politiques utilisés en production doivent être contrôlés avant et après la mise à niveau avec un flux de test concret. Cela comprend Source, Destination, Service, Traffic Selectors, le pair, ainsi que la règle de pare-feu et la règle NAT attendues. En cas de problème, consulter Dépannage VPN IPsec et Comprendre NAT sur Sophos Firewall.

Avant la mise à niveau, il faut également déterminer si OSPF ou BGP annonçait jusque-là des réseaux VPN policy-based distants via redistribute kernel. À partir de SFOS 22, ces réseaux ne sont plus disponibles comme routes ordinaires du noyau ; SFOS 22 : routes IPsec et redistribute kernel indique quels préfixes contrôler avant et après la mise à niveau et pourquoi une architecture XFRM route-based convient mieux au routage dynamique.

SMTP via DNAT

Lorsqu’un serveur de messagerie interne est publié via DNAT, le plan de maintenance doit prévoir plusieurs véritables messages de test entrants, et pas seulement un test de port. Sous NC-184583, Sophos répertorie des connexions SMTP interrompues de manière sporadique après une mise à niveau vers SFOS 22.x ; GA Respin Build 411 est explicitement indiqué comme version affectée. La liste officielle des Known Issues renvoie à Sophos Support pour obtenir le workaround, sans en publier les étapes. La délimitation exacte des versions, la collecte des preuves et l’escalade vers le support sont décrites dans Publier un serveur via DNAT sur Sophos Firewall.

Let’s Encrypt et rollback de la migration MR2

Selon les release notes, MR2 Build 546 prend en charge les nouvelles CA Let’s Encrypt YE Root, YE1, YE2, YR Root, YR1 et YR2. Séparément, deux signalements publics de la Community décrivent un échec de migration de MR1 Build 490 vers MR2 Build 546 pendant l’utilisation d’un certificat Let’s Encrypt, suivi d’un rollback automatique vers MR1. Les release notes et la liste publique des Known Issues ne confirment pas ce lien. Au 5 septembre 2026, il n’existe donc aucun identifiant officiel, aucun test préalable fiable ni aucune version corrective confirmée.

Avant de mettre à niveau un firewall MR1 doté d’un certificat Let’s Encrypt récemment émis ou renouvelé, relever Issued by et toutes les affectations de service sous Certificates > Certificates. Un issuer YE/YR ou la simple présence de ces CA sous Certificates > Certificate authorities ne prouve pas l’erreur signalée et ne constitue pas, à lui seul, un blocage. Sophos Support peut évaluer au préalable le cas particulier d’un firewall critique ; en l’absence de confirmation officielle, le report de la mise à niveau reste lui aussi une décision opérationnelle fondée sur le risque. Les certificats et les CA ne doivent pas être supprimés ou renommés sur la base d’un simple soupçon : une tentative de suppression documentée dans la Community n’a pas résolu le problème de manière fiable, et le certificat peut protéger WAF, WebAdmin, des portails, Hotspot ou SMTP TLS. Gérer les certificats sur Sophos Firewall explique comment vérifier les affectations et préparer un remplacement sûr avec une possibilité de retour arrière.

Ce rollback de migration n’est pas la même erreur qu’une chaîne de certificats incomplète délivrée après le renouvellement. Certificats Let’s Encrypt sur Sophos Firewall décrit le contrôle de ce second symptôme.

Après un rollback automatique, le symptôme correspond au schéma signalé si dbv22.004 et tblvpncertificate_caid_fkey apparaissent dans migration.log et que l’instruction de suppression environnante mentionne des objets YE/YR. Ces termes de recherche permettent de trouver les lignes concernées :

dbv22.004
tblvpncertificate_caid_fkey
Lets_Encrypt_YE
Lets_Encrypt_YR

Si elles apparaissent, sauvegarder migration.log, migrationhash.log, le message du firmware, l’heure ainsi que les builds source et cible, puis ne pas répéter la même tentative de mise à niveau sans changement. Contrôler ensuite le firmware source, HA, WAN, le routing, VPN, la connexion à Central et tous les services dépendant des certificats. Sauvegarder les logs Sophos Firewall pour le support décrit la procédure de collecte appropriée ; ces données permettent à Sophos Support d’isoler l’erreur de migration.

Legacy VLAN Tagging sur les bridges

Legacy CLI VLAN Tagging sur les interfaces bridge a trois conséquences :

• Sous GA et MR1, le trafic depuis ou vers le pare-feu peut échouer alors que le trafic de transit continue.
• À partir de MR2, la mise à niveau est bloquée.
• Une sauvegarde concernée ne peut pas être restaurée sur SFOS 22.0 GA ou une version ultérieure.

Avant le nettoyage, documenter le bridge, les VLAN IDs, les adresses IP, les zones, les trunks des switches et les services dépendants. Créer ensuite des interfaces VLAN prises en charge avec le bridge comme Parent, puis générer une nouvelle sauvegarde. Ce cas particulier est décrit dans Contrôler les Bridge VLANs Sophos Firewall avant SFOS 22.

STAS

Pour une mise à niveau vers MR1, l’option Restrict client traffic during identity probe doit être définie sur No sous Authentication > STAS. MR2 corrige le défaut de MR1 et utilise No par défaut pour les nouvelles configurations ; les valeurs existantes et les règles basées sur les utilisateurs doivent néanmoins être contrôlées. Pour plus de détails, consulter Configurer STAS sur Sophos Firewall.

Analyse antimalware lors de la mise à niveau vers GA Build 411

Uniquement lors d’une mise à niveau ciblée vers SFOS 22.0 GA Respin Build 411, NC-177529 peut temporairement signaler Malware Unscannable pendant la migration, souvent pour www.msftconnecttest.com, car le nouveau moteur d’analyse Sophos n’est pas encore disponible. Avant cette mise à niveau vers GA, passer de Single engine à Dual engine sous Web > General settings, puis revenir au Single Engine utilisé auparavant une fois la mise à niveau terminée. Cette mesure ne s’applique pas de manière générale à MR1, MR2 ou aux versions ultérieures ; Configurer et tester l’analyse antimalware de Sophos Firewall explique le contexte et le choix du moteur d’analyse.

Fenêtre de maintenance, validation et repli

Planifier l’interruption et la séquence HA

Sur un pare-feu autonome, le nouveau firmware est installé puis activé par un redémarrage ; le trafic reste interrompu jusqu’à la fin du redémarrage. HA ne garantit pas non plus une mise à niveau sans interruption. Les deux nœuds doivent être accessibles, sains et synchronisés, et chacun doit satisfaire aux exigences de stockage et de SSD. Un seul nœud non conforme peut bloquer toute la mise à niveau.

Lancer la mise à niveau HA uniquement sur le Primary, et non séparément sur l’Auxiliary. Le cluster met d’abord à niveau l’Auxiliary, lui transfère le trafic, puis met à niveau l’ancien Primary. Selon le Preferred Primary, un failback peut ensuite avoir lieu. Prévoir de brèves interruptions lors des deux basculements. Le guide de mise à jour du firmware décrit l’installation et le chargement manuel pour les environnements hors ligne.

Un redémarrage supplémentaire avant la mise à niveau n’est qu’une possibilité facultative pour vider le cache mémoire, pas une condition préalable ni une solution à une instabilité inexpliquée. Il provoque une autre interruption ; conserver d’abord les logs utiles et vérifier le moyen de récupérer l’accès de gestion. La préparation générale des mises à jour explique les contrôles de santé du système. Les contrôles du stockage et du SSD s’appliquent aussi à SFOS 22.0 et aux versions ultérieures, mais le chemin direct indiqué ci-dessus ne vaut que pour MR2 Build 546, pas pour SFOS 23 ni pour d’autres builds cibles.

Évaluer un échec de mise à niveau en toute sécurité

À partir de SFOS 20.0, le pare-feu peut revenir automatiquement au firmware et à la configuration précédents lors de certains échecs de migration de la configuration. Cela protège l’état fonctionnel, sans garantir un retour arrière pour chaque erreur ni la réussite de la prochaine tentative. Attendre d’abord la fin du processus ou d’un éventuel rollback automatique, puis contrôler la version active, la santé du système, le stockage et les deux nœuds en HA. Conserver les logs de migration, déterminer la cause et le chemin pris en charge, puis seulement planifier une nouvelle tentative ; solliciter Sophos Support si le diagnostic reste incertain. Le guide du firmware explique les limites du rollback automatique et le dépannage, notamment lorsque firmware, patterns ou hotfixes ne sont pas reçus à cause de problèmes de connexion ou de services de mise à jour bloqués.

Avant un repli manuel en HA, les deux nœuds doivent disposer du même firmware inactif compatible. S’il manque, ne pas sélectionner aveuglément Boot firmware image, mais planifier la procédure HA spécifique décrite dans le guide du firmware. Si HA n’était pas configuré dans l’ancien état de configuration, les deux appareils démarrent en mode autonome après le repli et HA doit être configuré à nouveau.

Validation et décision de repli

• Avant : Exclure les blocages, préparer la sauvegarde et le SSMK, vérifier la synchronisation HA et relever la version source, le slot actif, le build cible, les chemins VPN, les flux de test et le plan de repli.
• Pendant : Ne pas effectuer de modifications parallèles du routage, du VPN ou du switching ; surveiller l’état et le failover HA. Après la reconnexion, confirmer sous Backup & Firmware > Firmware que Current firmware affiche le build cible approuvé au préalable (Build 546 uniquement si le chemin MR2 a été expressément choisi) ; en HA, contrôler également la version, le rôle et la synchronisation des deux nœuds.
• Après : Tester les interfaces et le WAN, l’accès à Internet, DNS, DHCP, Central, HA, STAS, l’authentification, les règles de pare-feu, le VPN, NAT et les services publiés avec les flux prédéfinis. Log Viewer et Packet Capture doivent afficher les Firewall et NAT Rule IDs attendus.

Un tunnel au vert ou un Policy Test réussi ne prouve pas encore que le trafic utile fonctionne. Les connexions critiques doivent donc être testées avec des paquets réels, Log Viewer, Packet Capture ainsi que les Firewall et NAT Rule ID. En cas de problème, ne pas modifier plusieurs domaines simultanément.

Définir avant la fenêtre la durée pendant laquelle une interruption peut être analysée. Si le WAN, HA, les VPN centraux ou les publications critiques restent instables à ce point de décision, choisir Boot firmware image pour le slot compatible précédent sous Backup & Firmware > Firmware. Ce repli manuel active à la fois le firmware et l’ancien état de configuration de ce slot ; les modifications postérieures à la mise à niveau peuvent être perdues. Ne pas le prévoir pour un chemin de mise à niveau non pris en charge ni comme substitut à une sauvegarde, au SSMK et à une procédure de reimage. Après le repli, retester la version active, HA, le WAN, le routage, le VPN, NAT, DNS, DHCP, Central et les logs, puis conserver les logs de migration avant une nouvelle tentative.

La mise à niveau est terminée lorsque les tests définis réussissent et que la version cible, l’état HA, les résultats des tests et les tâches de suivi en suspens ont été documentés.

FAQ