Sophos XG vs XGS : différences, EOL et migration
La série XGS est le successeur de la série XG depuis 2021. La comparaison initiale entre l’ancien et le nouveau matériel n’est toutefois plus seulement une question de performance aujourd’hui. Le matériel Sophos XG est End of Life depuis le 31 mars 2025. 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 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: End of Life. plateforme matérielle activement supportée.
- Firmware: aucune prise en charge SFOS 21.0/21.5/22.0. versions SFOS actuelles.
- Performance: ancienne plateforme, moins de réserves pour l’inspection moderne. architecture Xstream avec plus de réserves.
- Exploitation: risque de migration et limite de support. plateforme standard pour les nouveaux projets.
- Planification: remplacement nécessaire. sizing, Port-Mapping et transfert de licence à planifier proprement.
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.
- Les mises à jour de sécurité, Hotfixes et le support constructeur sont limités ou ne sont plus disponibles.
- 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 avec des fonctions d’accélération dédiées. Il y a donc plus de réserves pour les fonctions de sécurité actuelles, VPN, TLS Inspection, IPS, Web Protection et le routage.
- 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 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. Au quotidien, ce n’est pas seulement un terme marketing, mais un point surtout pertinent lorsque les fonctions de protection sont activées. Beaucoup d’installations XG plus anciennes ont été dimensionnées à une époque où il y avait moins de TLS Inspection, moins de trafic cloud, moins de SD-WAN et moins de charge Remote Access.
Selon le modèle, une XGS 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 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 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, Sophos Central Management ou 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 ?
Backup-Restore Assistant et Port-Mapping
Le Migration Center pour les migrations XG vers XGS est la référence externe la plus importante pour le Port-Mapping et le Backup-Restore Assistant. C’est important parce que les noms de ports, le nombre de ports, les Flexi-Port-Modules, les modèles wireless et les modèles cibles ne correspondent pas toujours 1:1.
En pratique, il faut préparer un tableau de ports avant le restore :
- Port1: Port1. LAN. VLANs, DHCP, DNS.
- Port2: Port2. WAN. Gateway, alias IP, NAT.
- Port3: Port4. DMZ. Firewall Rules, WAF, DNAT.
- Flexi Port: nouveau module. Uplink ou trunk. compatibilité du module.
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 nouveaux appareils XGS. Il faut replanifier HA consciemment : modèle identique, version firmware, licences, port HA, monitoring, passphrase, changement de rôles et fenêtre de test. Les détails font partie de la planification HA, par exemple avec Configurer Sophos Firewall High Availability.
Reprendre Central, Reporting, SD-WAN et ZTNA
Après le restore, la nouvelle XGS n’est pas automatiquement intégrée de la même manière dans chaque fonction Sophos Central. Selon l’environnement, il faut :
- enregistrer le nouveau firewall dans Sophos Central,
- vérifier Firewall Management et Central Reporting,
- contrôler la licence Central Firewall Reporting et l’affectation des données,
- réattribuer les SD-WAN Connection Groups,
- basculer les ZTNA-Gateways vers le nouveau firewall,
- tester l’affectation RED et Access Point,
- 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 Central. 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 documentés.
- Backup actuel créé et mot de passe de restore conservé en sécurité.
- Secure Storage Master Key connu et documenté.
- Port-Mapping préparé pour WAN, LAN, DMZ, VLAN trunks et HA.
- Transfert de licence, enregistrement Central et statut de support vérifiés.
- VPNs, NAT, WAF, SD-WAN, DHCP, DNS et routage préparés comme liste de tests.
- RED, Access Points, ZTNA, Central 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.
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 Central 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 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.