Sophos XG vs. XGS: differenze, EOL e migrazione
La serie XGS è il successore della serie XG dal 2021. Il confronto originale tra hardware vecchio e nuovo oggi non è però più solo una questione di prestazioni. L’hardware Sophos XG è End of Life dal 31 marzo 2025. Inoltre SFOS 21.0 e le linee firmware successive non supportano più hardware XG e SG-Series.
La vera domanda quindi non è più XGS conviene?, ma Come si pianifica il passaggio da XG in modo pulito, senza trascurare routing, VPN, Central Reporting o sedi remote?
Risposta breve
XG e XGS eseguono entrambe Sophos Firewall OS, ma non sono più piattaforme equivalenti.
- Lifecycle: End of Life. piattaforma hardware supportata attivamente.
- Firmware: nessun supporto SFOS 21.0/21.5/22.0. versioni SFOS attuali.
- Prestazioni: piattaforma più vecchia, meno riserve per inspection moderna. architettura Xstream con più riserve.
- Operatività: rischio di migrazione e limite di supporto. piattaforma standard per nuovi progetti.
- Pianificazione: sostituzione necessaria. pianificare correttamente sizing, port mapping e trasferimento licenza.
Una XG non dovrebbe quindi più essere considerata un normale modello firewall, ma una piattaforma legacy da sostituire. Per domande su licenze e lifecycle è utile anche il calendario Sophos Product Lifecycle.
Cosa significa End of Life nell’operatività firewall
End of Life per l’hardware firewall non è una semplice voce formale in una tabella. Un firewall si trova al perimetro della rete, termina VPN, filtra traffico web e applicativo, protegge servizi pubblicati e contiene spesso configurazioni sensibili. Se questa piattaforma non viene più mantenuta, nasce un rischio operativo reale.
Per una XG produttiva sono critici soprattutto questi punti:
- Le nuove linee firmware SFOS non possono più essere usate.
- Aggiornamenti di sicurezza, Hotfixes e supporto del produttore sono limitati o non più disponibili.
- Nuove funzioni come feature VPN, logging, Health Check o sicurezza aggiornate arrivano sulle piattaforme supportate.
- Licenze, RMA, dispositivi sostitutivi e casi di supporto diventano più difficili da pianificare.
- Audit e cyberassicurazioni possono valutare criticamente il proseguimento dell’esercizio di un firewall EOL.
Questo è particolarmente critico per firewall con Remote Access VPN attivo, Site-to-Site VPN, WAF, TLS Inspection, Web Protection, server pubblicati o WebAdmin ampiamente raggiungibile. In questi ambienti, continuare a usare una XG dovrebbe valere solo come soluzione transitoria limitata nel tempo, con piano di migrazione documentato.
Le tre differenze più importanti
XG e XGS possono sembrare simili dall’esterno a seconda del modello, ma sono molto diverse dal punto di vista tecnico e operativo.
- Lifecycle e firmware: l’hardware XG è End of Life. SFOS 21.0, 21.5 e 22.0 non supportano più hardware XG e SG-Series. XGS è la piattaforma hardware supportata per le versioni SFOS attuali.
- Architettura e prestazioni: XGS usa l’architettura Xstream con funzioni di accelerazione dedicate. Questo offre più riserve per funzioni di sicurezza attuali, VPN, TLS Inspection, IPS, Web Protection e routing.
- Migrazione e operatività: il passaggio a XGS è un progetto di migrazione. Compatibilità del backup, port mapping, stato licenza, HA, SD-WAN, Central Reporting, RED, Access Points e ZTNA gateways devono essere verificati.
Architettura: Xstream invece della vecchia piattaforma XG
La serie XGS è stata costruita per l’architettura Xstream. Nell’uso quotidiano non è solo un termine marketing, ma è rilevante soprattutto quando le funzioni di protezione sono attive. Molte installazioni XG più vecchie erano state dimensionate quando c’erano meno TLS Inspection, meno traffico cloud, meno SD-WAN e meno carico Remote Access.
A seconda del modello, una XGS offre più riserve per:
- IPS, Web Protection e Application Control.
- TLS Inspection e rollout di certificati/CA più grandi.
- IPsec VPN, SSL VPN, SD-WAN e più uplink WAN.
- Più utenti, sessioni e regole simultanei.
- Nuove funzioni SFOS che su XG non sono più disponibili.
Non ogni percorso dati diventa automaticamente più veloce solo perché viene installata una XGS. Sizing errato, modelli troppo piccoli, TLS Inspection pianificata male o architettura VPN poco chiara possono rallentare anche un nuovo firewall. Per scegliere il modello di destinazione adatto, il Sophos Firewall Sizing Guide è più importante di un semplice confronto modello 1:1.
Quando una XG dovrebbe essere sostituita
La sostituzione di una XG non dovrebbe essere pianificata solo quando un upgrade firmware viene bloccato o un guasto hardware crea già pressione. Al più tardi con questi segnali serve un progetto di migrazione:
- Il firewall deve essere aggiornato a SFOS 21.0, 21.5, 22.0 o più recente.
- Sono presenti Remote Access VPN, WAF, servizi raggiungibili pubblicamente o più Site-to-Site VPN.
- Supporto, audit, RMA o rinnovo licenza non sono più rappresentabili in modo pulito.
- La XG esistente è al limite sotto IPS, Web Protection, TLS Inspection o carico VPN.
- RED, Access Points, SD-WAN, Central Reporting o ZTNA dipendono dal firewall esistente.
- Sono comunque previsti un cluster HA, un redesign delle porte o un cambio provider.
Se una XG è ancora produttiva, vanno prima documentati un backup attuale, il Secure Storage Master Key e la versione firmware usata. La procedura è descritta in modo più dettagliato nell’articolo Creare o ripristinare un backup Sophos Firewall.
Pianificare la migrazione da XG a XGS
In una migrazione da XG a XGS non conviene scegliere solo il modello apparentemente più vicino. È più utile una breve rilevazione dello stato prima della finestra di manutenzione:
- Quali porte WAN, LAN e DMZ vengono effettivamente usate?
- Esistono casi particolari HA, stack VLAN, RED, SD-WAN o VPN?
- Quali funzioni di sicurezza sono attive oggi e quali dovranno essere attivate in futuro?
- Quali scenari IPsec, SSL VPN, Sophos Connect o ZTNA sono produttivi?
- Esistono Central Firewall Reporting, Sophos Central Management o SD-WAN Connection Groups?
- Access Points o dispositivi SD-RED sono associati a questo firewall?
- Esistono route statiche, indirizzi Alias-IP, regole DNAT o pubblicazioni WAF che devono essere raggiungibili subito dopo il passaggio?
- La piattaforma di destinazione deve essere ancora hardware oppure una appliance virtuale o cloud?
Backup-Restore Assistant e port mapping
Il Migration Center per migrazioni da XG a XGS è il riferimento esterno più importante per port mapping e Backup-Restore Assistant. Questo è importante perché nomi porta, numero di porte, moduli Flexi Port, modelli wireless e modelli di destinazione non coincidono sempre 1:1.
Nella pratica, prima del restore conviene preparare una tabella porte:
- Port1: Port1. LAN. VLAN, DHCP, DNS.
- Port2: Port2. WAN. Gateway, Alias-IP, NAT.
- Port3: Port4. DMZ. Firewall Rules, WAF, DNAT.
- Flexi Port: nuovo modulo. Uplink o trunk. compatibilità modulo.
Se cambia l’indirizzo MAC WAN, router a monte o CPE del provider possono mantenere ancora vecchie voci ARP. In presenza di questi sintomi aiuta l’articolo Risolvere un problema ARP su Sophos Firewall dopo una migrazione.
Gestire HA separatamente
Un cluster HA XG non viene semplicemente sostituito tramite restore su due nuovi dispositivi XGS. HA va pianificato consapevolmente: stesso modello, versione firmware, licenze, porta HA, monitoring, passphrase, cambio ruoli e finestra di test. I dettagli rientrano nella pianificazione HA, per esempio con Configurare Sophos Firewall High Availability.
Riallineare Central, Reporting, SD-WAN e ZTNA
Dopo il restore, la nuova XGS non è automaticamente integrata allo stesso modo in ogni funzione Sophos Central. A seconda dell’ambiente, bisogna:
- registrare il nuovo firewall in Sophos Central,
- verificare Firewall Management e Central Reporting,
- controllare licenza Central Firewall Reporting e assegnazione dati,
- riassegnare SD-WAN Connection Groups,
- spostare ZTNA gateways sul nuovo firewall,
- testare associazione RED e Access Points,
- ricontrollare notifiche, backup e report pianificati.
Per setup di reporting è utile anche Attivare Central Firewall Reporting. Per evidenze operative dopo la migrazione, Testare una regola Sophos Firewall con Log Viewer e Packet Capture e Analizzare pacchetti scartati su Sophos Firewall sono più utili di un semplice test ping.
Errori tipici nelle migrazioni da XG a XGS
Modello di destinazione troppo piccolo
Un modello successivo apparentemente adatto può essere troppo piccolo se, dalla prima acquisizione della XG, sono aumentati utenti, VPN, TLS Inspection, Web Protection o banda. Per questo non bisogna confrontare solo modello XG contro modello XGS, ma considerare carico reale, funzioni di protezione attive e crescita.
Port mapping verificato solo superficialmente
Se LAN, WAN, DMZ, VLAN trunks, porte HA o connessioni provider vengono cablate diversamente, un restore riuscito non è sufficiente. Dopo il restore vanno verificate in modo mirato interface zones, gateways, SD-WAN routes, regole NAT, regole WAF e Firewall Rules.
Firmware vecchio o backup non aggiornato
Uno stato backup molto vecchio aumenta il rischio che interface mapping, certificati, VPN o configurazioni speciali migrino in modo inatteso. Prima del cambio, il vecchio firewall dovrebbe essere portato, per quanto ancora sensato e supportato, a una versione adatta e va creato un backup fresco.
Sistemi a valle dimenticati
Molte migrazioni non falliscono sul restore, ma sui sistemi dipendenti: monitoring, Syslog, SIEM, e-mail di backup, VPN clients, ARP provider, DNS, DHCP, RED, Access Points o Sophos Central. Questi punti appartengono alla checklist, non alla ricerca errori dopo la commutazione.
Checklist prima del cambio
- Firmware attuale della XG e firmware di destinazione della XGS documentati.
- Backup attuale creato e password di restore conservata in modo sicuro.
- Secure Storage Master Key noto e documentato.
- Port mapping per WAN, LAN, DMZ, VLAN trunks e HA preparato.
- Trasferimento licenza, registrazione Central e stato supporto verificati.
- VPN, NAT, WAF, SD-WAN, DHCP, DNS e routing preparati come lista di test.
- RED, Access Points, ZTNA, Central Reporting e monitoring considerati.
- Piano di rollback definito con vecchio dispositivo, piano cavi e finestra di manutenzione.
- Referenti per provider, DNS, monitoring e applicazioni raggiungibili.
Verifica dopo la migrazione
Dopo la commutazione non va verificato solo se Internet funziona. Una migrazione pulita è conclusa solo quando le funzioni operative più importanti sono validate:
- Verificare dashboard, stato licenza, registrazione Central e e-mail di backup.
- Testare WAN gateway, indirizzi Alias-IP, NAT e servizi pubblicati.
- Verificare Site-to-Site VPN, Remote Access VPN e profili Sophos Connect.
- Controllare SD-WAN routes, route statiche e Route Precedence.
- Testare Firewall Rules con logging.
- Verificare a campione IPS, Web Protection, TLS Inspection e Application Control.
- Controllare connessioni RED e Access Points.
- Testare Syslog, Central Reporting, notifiche e monitoring.
- Mettere fuori servizio la vecchia XG solo dopo una fase operativa stabile.
Se subito dopo la migrazione alcune destinazioni non sono raggiungibili, conviene procedere sistematicamente con Log Viewer, Packet Capture e controlli di routing. Per la diagnosi di base aiutano Usare Sophos Firewall Packet Capture nel WebAdmin e Modificare in sicurezza Route Precedence su Sophos Firewall.