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

Les avertissements de la page du firmware doivent être résolus avant la mise à niveau. Le code de référence indique ce qui bloque la mise à niveau :

• FWDS501 : le Primary Disk ou l’une de ses partitions est trop petit pour SFOS 22. FWDS501 : agrandir le Primary Disk avant SFOS 22 explique comment identifier la partition concernée et déterminer si l’installation existante peut être agrandie ou si le pare-feu doit être redéployé.
• 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.

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.

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.

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.

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