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 couvre SFOS 22.0 MR2 Build 546 du 14 juillet 2026 et complète 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 XGS 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.

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

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 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 et aucun workaround public n’est disponible. 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

MR2 Build 546 prend en charge les nouvelles CA Let’s Encrypt YE Root, YE1, YE2, YR Root, YR1 et YR2. Indépendamment de cela, lors de deux mises à niveau documentées publiquement de MR1 Build 490 vers MR2 Build 546, la migration de la configuration a échoué en lien avec un certificat Let’s Encrypt utilisé. Le firewall est automatiquement revenu à MR1. Après un contrôle via Support Access, Sophos a confirmé un blocage de migration connu pour des certificats émis pendant une période déterminée, mais non délimitée publiquement. Au 9 août 2026, il n’existe toujours aucun identifiant public du problème, aucun test préalable fiable ni aucune version de correction confirmée.

Avant de mettre à niveau un firewall MR1 doté d’un certificat Let’s Encrypt récemment émis ou renouvelé, documenter l’Issuer et l’affectation au service sous Certificates > Certificates. Un Issuer YE/YR ou la simple présence de ces CA sous Certificate authorities ne prouve pas l’erreur de migration et ne constitue pas, à lui seul, un blocage général de la mise à niveau. Pour un firewall critique, il reste néanmoins judicieux de coordonner le cas au préalable avec Sophos Support ou de reporter la mise à niveau tant qu’aucun test préalable public ni aucun correctif ne sont confirmés. 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 et le hotfix déployé à cet effet.

Après un rollback automatique, le symptôme correspond au problème connu 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 et validation

• Avant : Exclure les blocages, préparer la sauvegarde et le SSMK, vérifier la synchronisation HA et documenter les chemins VPN, de test et 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 : Contrôler le firmware, les interfaces, Internet, les règles de pare-feu, le VPN, NAT, HA, STAS, DNS, DHCP, Central et Log Viewer.

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.

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