Sophos XG vs XGS : différences, EOL et migration

La série XGS succède à la série XG depuis 2021. La comparaison entre l’ancien et le nouveau matériel ne se limite désormais plus aux performances. Les derniers modèles XG Series ont atteint leur End of Life le 31 mars 2025 ; certains modèles plus anciens étaient déjà EOL. De plus, SFOS 21.0 et les lignes firmware ultérieures ne prennent plus en charge le matériel XG et SG-Series.

La vraie question n’est donc plus XGS vaut-il la peine ?, mais Comment planifier proprement la migration depuis XG sans oublier le routage, VPN, Central Firewall Reporting ou les sites distants ?

Réponse courte

XG et XGS fonctionnent toutes deux avec Sophos Firewall OS, mais ce ne sont plus des plateformes équivalentes.

• Lifecycle : XG : End of Life. XGS : plateforme matérielle activement prise en charge.
• Firmware : XG : aucune version SFOS à partir de 21.0. XGS : lignes SFOS actuelles, y compris 22.0.
• Performance : XG : ancienne plateforme, avec moins de marge pour l’inspection moderne. XGS : architecture Xstream ; l’accélération disponible dépend du modèle, du firmware et du chemin de données.
• Exploitation : XG : limite de migration et de support. XGS : plateforme standard pour les nouveaux projets matériels.
• Planification : XG : remplacement nécessaire. XGS : sizing, Port-Mapping et transfert de licence doivent être définis avant le cutover.

Une XG ne doit donc plus être considérée comme un modèle firewall normal, mais comme une ancienne plateforme à remplacer. Pour les questions de licence et de lifecycle, consultez aussi le calendrier Sophos Product Lifecycle.

Ce que signifie End of Life dans l’exploitation firewall

End of Life n’est pas une simple entrée formelle dans un tableau lorsqu’il s’agit de matériel firewall. Un firewall se trouve en bordure de réseau, termine des VPNs, filtre le trafic web et applicatif, protège des services publiés et contient souvent des configurations sensibles. Si cette plateforme n’est plus maintenue, un vrai risque d’exploitation apparaît.

Pour une XG en production, ces points sont particulièrement critiques :

• Les nouvelles lignes firmware SFOS ne peuvent plus être utilisées.
• Sophos avertit que les mises à jour logicielles cessent peu après l’EOL ; le support constructeur et le remplacement matériel ne sont donc plus planifiables de manière fiable.
• Les nouvelles fonctions comme les fonctions VPN, logging, Health Check ou sécurité actuelles arrivent sur les plateformes prises en charge.
• Les licences, RMA, appareils de remplacement et cas de support deviennent plus difficiles à planifier.
• Les audits et cyberassurances peuvent évaluer de manière critique la poursuite de l’exploitation d’un firewall EOL.

C’est particulièrement critique pour les firewalls avec Remote Access VPN actif, Site-to-Site VPN, WAF, TLS Inspection, Web Protection, serveurs publiés ou WebAdmin largement accessible. Dans de tels environnements, la poursuite de l’exploitation d’une XG ne devrait plus être considérée que comme une solution transitoire limitée dans le temps avec un plan de migration documenté.

Les trois principales différences

Selon le modèle, XG et XGS se ressemblent extérieurement, mais elles diffèrent nettement sur les plans technique et opérationnel.

• Lifecycle et firmware : le matériel XG est End of Life. SFOS 21.0, 21.5 et 22.0 ne prennent plus en charge le matériel XG et SG-Series. XGS est la plateforme matérielle prise en charge pour les versions SFOS actuelles.
• Architecture et performance : XGS utilise l’architecture Xstream et une accélération qui dépend du modèle. Elle offre davantage de marge pour les fonctions de sécurité actuelles, VPN, TLS Inspection, IPS, Web Protection et routage. La fiche technique du modèle précis reste déterminante.
• Migration et exploitation : le passage à XGS est un projet de migration. La compatibilité des backups, le Port-Mapping, l’état des licences, HA, SD-WAN, Central Firewall Reporting, RED, Access Points et ZTNA-Gateways doivent être vérifiés.

Architecture : Xstream au lieu de l’ancienne plateforme XG

La série XGS a été conçue pour l’architecture Xstream, particulièrement utile lorsque les fonctions de protection sont activées. Les chemins de données accélérés et les ressources disponibles diffèrent toutefois entre les modèles desktop, 1U et 2U ; le nom de la série ne permet pas à lui seul de déduire le débit. Beaucoup d’anciennes installations XG ont aussi été dimensionnées avec moins de TLS Inspection, de trafic cloud, de SD-WAN et de charge Remote Access.

Selon le modèle, une XGS Appliance apporte plus de réserves pour :

• IPS, Web Protection et Application Control.
• TLS Inspection et des déploiements de certificats/CA plus importants.
• IPsec VPN, SSL VPN, SD-WAN et plusieurs WAN uplinks.
• Davantage d’utilisateurs, de sessions et de règles simultanés.
• De nouvelles fonctions SFOS qui ne sont plus du tout disponibles sur XG.

Tous les chemins de données ne deviennent pas automatiquement plus rapides simplement parce qu’une XGS Appliance est installée. Un mauvais sizing, des modèles trop petits, une TLS Inspection mal planifiée ou une architecture VPN imprécise peuvent aussi freiner un nouveau firewall. Pour choisir le modèle cible adapté, le Sophos Firewall Sizing Guide est plus important qu’une simple comparaison de modèles 1:1.

Quand remplacer une XG

Le remplacement d’une XG ne doit pas être planifié seulement lorsqu’une mise à niveau firmware est bloquée ou qu’une panne matérielle met déjà la pression. Au plus tard avec ces signaux, un projet de migration est nécessaire :

• Le firewall doit être mis à jour vers SFOS 21.0, 21.5, 22.0 ou plus récent.
• Il existe Remote Access VPN, WAF, des services accessibles publiquement ou plusieurs Site-to-Site VPNs.
• Le support, les audits, RMA ou le renouvellement de licence ne peuvent plus être représentés proprement.
• La XG existante atteint ses limites sous charge IPS, Web Protection, TLS Inspection ou VPN.
• RED, Access Points, SD-WAN, Central Firewall Reporting ou ZTNA dépendent du firewall existant.
• Un cluster HA, un redesign des ports ou un changement de fournisseur est de toute façon prévu.

Si une XG fonctionne encore en production, il faut d’abord documenter un backup actuel, le Secure Storage Master Key et la version firmware utilisée. La procédure est décrite plus en détail dans Créer ou restaurer un backup Sophos Firewall.

Planifier la migration de XG vers XGS

Lors d’une migration de XG vers XGS, il ne faut pas seulement choisir le modèle supposé le plus proche. Un court inventaire avant la fenêtre de maintenance est plus judicieux :

• Quels ports WAN, LAN et DMZ sont effectivement utilisés ?
• Existe-t-il HA, des piles VLAN, RED, SD-WAN ou des cas particuliers VPN ?
• Quelles fonctions de sécurité sont actives aujourd’hui et lesquelles doivent être activées en plus à l’avenir ?
• Quels scénarios IPsec, SSL VPN, Sophos Connect ou ZTNA sont productifs ?
• Existe-t-il Central Firewall Reporting, la gestion via Sophos Fusion ou des SD-WAN Connection Groups ?
• Des Access Points ou des appareils SD-RED sont-ils liés à ce firewall ?
• Existe-t-il des routes statiques, alias IP, règles DNAT ou publications WAF qui doivent être immédiatement joignables après le changement ?
• La plateforme cible doit-elle à nouveau être matérielle ou une appliance virtuelle ou cloud ?

Définir le parcours firmware avant le backup

La XG ne peut pas être mise à niveau vers SFOS 21.0 ou 22.0. Sophos distingue donc le restore selon la version de la XG source ; sur la XGS Appliance cible, Backup-Restore Assistant nécessite SFOS 20.0 MR2 ou une version ultérieure :

• Avec 19.5 MR4 ou toute version 20.0, créez directement le backup et mappez les interfaces pendant le restore avec Backup-Restore Assistant.
• Avec 19.5 MR3 ou antérieure, la migration reste possible, mais l’assistant n’apparaît pas. Sophos recommande de mettre d’abord la XG à niveau vers 19.5 MR4 ou 20.0 MR2 et ultérieure, si cette étape intermédiaire est encore prise en charge et acceptable en exploitation.

Le Setup Assistant de la nouvelle XGS Appliance met la cible à niveau vers la dernière version proposée. Si la migration introduit aussi SFOS 22, consultez le guide de mise à jour du firmware Sophos Firewall avant la fenêtre de maintenance. Une ancienne configuration Remote Access IPsec bloque la mise à niveau vers 22.0 MR1 et ultérieure ; l’ancien marquage VLAN CLI sur les interfaces bridge bloque 22.0 MR2 et ultérieure, et les backups qui le contiennent ne peuvent pas non plus être restaurés vers 22.0 GA ou ultérieure. SFOS 22 peut en outre exiger de l’espace disque supplémentaire et modifie le comportement des VPN IPsec policy-based.

Recommandation Avanet : ne combinez changement matériel et changement firmware majeur dans une seule fenêtre qu’après ces contrôles. Sinon, un échec ne permet plus de distinguer clairement backup, Port-Mapping et firmware.

Backup-Restore Assistant et Port-Mapping

Le Port-Mapping et Backup-Restore Assistant doivent être préparés pour les appliances source et cible exactes : les noms et le nombre de ports, les modules Flexi Port, les variantes wireless et les modèles cibles ne correspondent pas toujours 1:1. Les modules Flexi Port XG ne sont pas compatibles avec XGS et doivent être remplacés par des modules XGS adaptés.

En pratique, il faut préparer un tableau de ports avant le restore :

• Port1 vers Port1 pour le LAN : vérifier les VLANs, DHCP et DNS.
• Port2 vers Port2 pour le WAN : vérifier la gateway, l’alias IP et NAT.
• Port3 vers Port4 pour la DMZ : vérifier les Firewall Rules, WAF et DNAT.
• Flexi Port vers un nouveau module : vérifier l’uplink, le trunk et la compatibilité du module.

L’assistant n’affiche que les ports physiques. Les interfaces VLAN et alias suivent leur Parent Interface ; les LAGs et bridges sont recréés à partir des membres physiques mappés. Les interfaces liées non mappées peuvent devenir des pseudo ports. Vérifiez donc le numéro de port, mais aussi Zone, IP Assignment, Link Mode, Parent Interface et appartenance.

Les modèles wireless ont des limites supplémentaires. Pour restaurer un backup XG Wireless ou XGS Wireless Gen.1 sur un modèle XGS Wireless Gen.2, Sophos impose notamment WPA2 ou plus récent, aucun TKIP, aucune interface wireless dans un bridge physique et au maximum huit SSIDs uniques sur LocalWiFi0 et LocalWiFi1. Un restore vers un modèle sans WLAN intégré exige de supprimer les réseaux wireless avant le backup. Traitez cette modification comme une étape séparée et vérifiée, pas comme une improvisation pendant le cutover.

Si l’adresse MAC WAN change, des routeurs en amont ou des CPEs fournisseur peuvent encore conserver d’anciennes entrées ARP. En cas de tels symptômes, l’article Résoudre un problème ARP Sophos Firewall après migration peut aider.

Traiter HA séparément

Un cluster XG-HA n’est pas simplement remplacé par un restore sur deux nouvelles XGS Appliances. Si un backup HA est restauré sur une nouvelle XGS Appliance sans HA, le restore ne recrée pas la configuration HA ; elle doit être configurée manuellement. Modèles identiques, version firmware, licences, port HA, monitoring, passphrase, changement de rôles et fenêtre de test relèvent donc d’une procédure séparée, par exemple Configurer Sophos Firewall High Availability.

Reprendre Sophos Fusion, Reporting, SD-WAN et ZTNA

Après le restore, la nouvelle XGS Appliance n’est pas automatiquement intégrée de la même manière dans chaque fonction Sophos Fusion. Selon l’environnement, il faut :

• enregistrer le nouveau firewall dans Sophos Fusion,
• vérifier Firewall Management et Central Firewall Reporting,
• affecter au nouvel appareil la licence Central Firewall Reporting séparée et ses données ; les rapports locaux XG ne sont pas transférés,
• pour les SD-WAN Connection Groups, supprimer d’abord sur la XGS Appliance les règles et tunnels créés par Sophos Fusion avec le préfixe Central_, puis l’ajouter au groupe,
• basculer les ZTNA-Gateways vers le nouveau firewall,
• tester l’affectation SD-RED et Access Point ; si la XG reste connectée en parallèle, y supprimer la configuration SD-RED et accepter les Access Points sur la XGS Appliance,
• revérifier les notifications, les backups et les rapports planifiés.

Pour les setups de reporting, consultez aussi Activer Central Firewall Reporting. Pour les preuves opérationnelles après la migration, Tester une règle Sophos Firewall avec Log Viewer et Packet Capture et Analyser les paquets rejetés sur Sophos Firewall sont plus utiles qu’un simple test ping.

Erreurs typiques lors des migrations XG vers XGS

Modèle cible trop petit

Un modèle successeur qui semble adapté peut être trop petit si davantage d’utilisateurs, de VPNs, de TLS Inspection, de Web Protection ou de bande passante se sont ajoutés depuis l’achat initial de la XG. Il faut donc comparer non seulement le modèle XG au modèle XGS, mais aussi la charge réelle, les fonctions de protection actives et la croissance.

Port-Mapping vérifié seulement grossièrement

Si LAN, WAN, DMZ, VLAN trunks, ports HA ou connexions fournisseur sont raccordés différemment, un restore réussi ne suffit pas. Après le restore, les zones d’interface, gateways, routes SD-WAN, règles NAT, règles WAF et Firewall Rules doivent être vérifiées de manière ciblée.

Ancien firmware ou ancien état de backup

Un état de backup très ancien augmente le risque que l’interface mapping, les certificats, VPNs ou configurations particulières migrent de manière inattendue. Avant le changement, il faut amener l’ancien firewall, dans la mesure où cela reste pertinent et pris en charge, à un état approprié et créer un backup récent.

Systèmes en aval oubliés

Beaucoup de migrations échouent non pas au restore, mais sur des systèmes dépendants : monitoring, Syslog, SIEM, mails de backup, clients VPN, ARP fournisseur, DNS, DHCP, RED, Access Points ou Sophos Fusion. Ces points doivent faire partie de la check-list, pas de la recherche d’erreur après le basculement.

Check-list avant le changement

• Firmware actuel de la XG et firmware cible de la XGS Appliance documentés.
• Compatibilité de restore des modèles source et cible exacts vérifiée dans l’outil Sophos.
• Backup actuel créé et mot de passe de restore conservé en sécurité.
• Secure Storage Master Key actuel et, le cas échéant, précédent, ainsi que mot de passe du backup disponibles séparément et en sécurité.
• Port-Mapping préparé pour WAN, LAN, DMZ, VLAN trunks et HA.
• Flexi Ports XG remplacés par des modules XGS compatibles ; limites wireless vérifiées.
• Transfert de licence, enregistrement dans Sophos Fusion et statut de support vérifiés.
• Pour SFOS 22 : ancien IPsec, marquage VLAN CLI, espace disque et VPN IPsec policy-based vérifiés.
• VPNs, NAT, WAF, SD-WAN, DHCP, DNS et routage préparés comme liste de tests.
• RED, Access Points, ZTNA, Central Firewall Reporting et monitoring pris en compte.
• Plan de rollback défini avec ancien appareil, plan de câblage et fenêtre de maintenance.
• Interlocuteurs pour le fournisseur, DNS, monitoring et applications joignables.

Rollback avec un seuil d’abandon clair

Conservez l’ancienne XG inchangée, éteinte ou physiquement isolée, avec un plan de câblage étiqueté jusqu’à la validation. Avant le cutover, fixez une heure et des critères d’abandon mesurables : WAN Gateway inaccessible, publication DNAT critique en panne ou tunnel VPN métier toujours down après le temps de diagnostic réservé.

Pour le rollback, isolez la XGS Appliance, remettez le câblage sur la XG selon le plan, puis seulement démarrez la XG. Revérifiez WAN, routage, VPN et services publiés. Les changements effectués pendant le test de la XGS Appliance ne se trouvent pas automatiquement sur l’ancienne XG ; consignez-les et évaluez-les après le rollback. Ne réinitialisez ni ne retirez la XG avant que la XGS Appliance soit validée stable, sauvegardée et documentée.

Contrôle après la migration

Après le basculement, il ne faut pas seulement vérifier si Internet fonctionne. Une migration propre n’est terminée que lorsque les principales fonctions d’exploitation sont validées :

• Vérifier Dashboard, état de licence, enregistrement dans Sophos Fusion et mail de backup.
• Tester WAN gateway, alias IP, NAT et services publiés.
• Vérifier Site-to-Site VPN, Remote Access VPN et profils Sophos Connect.
• Contrôler les routes SD-WAN, routes statiques et Route Precedence.
• Tester les Firewall Rules avec logging.
• Contrôler par échantillon IPS, Web Protection, TLS Inspection et Application Control.
• Contrôler les connexions RED et Access Point.
• Tester Syslog, Central Firewall Reporting, notifications et monitoring.
• Ne mettre l’ancienne XG hors service qu’après une phase d’exploitation stable.

Si certaines destinations ne sont pas joignables juste après la migration, il faut travailler méthodiquement avec Log Viewer, Packet Capture et des contrôles de routage. Pour le diagnostic de base, Utiliser Sophos Firewall Packet Capture dans WebAdmin et Modifier Sophos Firewall Route Precedence en sécurité sont utiles.

FAQ