Sophos XG vs. XGS: differenze, EOL e migrazione

La serie XGS succede alla serie XG dal 2021. Il confronto tra il vecchio e il nuovo hardware non riguarda più soltanto le prestazioni. Gli ultimi modelli XG Series hanno raggiunto l’End of Life il 31 marzo 2025; alcuni modelli precedenti erano già EOL. 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 Firewall Reporting o sedi remote?

Risposta breve

XG e XGS eseguono entrambe Sophos Firewall OS, ma non sono più piattaforme equivalenti.

• Lifecycle: XG: End of Life. XGS: piattaforma hardware supportata attivamente.
• Firmware: XG: nessuna versione SFOS dalla 21.0 in poi. XGS: linee SFOS attuali, inclusa la 22.0.
• Prestazioni: XG: piattaforma più vecchia, con meno margine per l’inspection moderna. XGS: architettura Xstream; l’accelerazione utilizzabile dipende da modello, firmware e percorso dati.
• Operatività: XG: limite di migrazione e supporto. XGS: piattaforma standard per nuovi progetti hardware.
• Pianificazione: XG: sostituzione necessaria. XGS: sizing, port mapping e trasferimento licenza devono essere definiti prima del cutover.

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.
• Sophos avverte che gli aggiornamenti software terminano poco dopo l’EOL; supporto del produttore e sostituzione hardware non sono quindi più pianificabili in modo affidabile.
• 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 e un’accelerazione che dipende dal modello. Offre così più margine per funzioni di sicurezza attuali, VPN, TLS Inspection, IPS, Web Protection e routing. Fa fede il datasheet del modello specifico.
• Migrazione e operatività: il passaggio a XGS è un progetto di migrazione. Compatibilità del backup, port mapping, stato licenza, HA, SD-WAN, Central Firewall 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, particolarmente rilevante con le funzioni di protezione attive. Percorsi dati accelerati e risorse disponibili variano però tra modelli desktop, 1U e 2U; il nome della serie da solo non indica il throughput. Molte vecchie installazioni XG erano inoltre state dimensionate con meno TLS Inspection, traffico cloud, SD-WAN e carico Remote Access.

A seconda del modello, una XGS Appliance 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 Appliance. 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 Firewall 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, la gestione tramite Sophos Fusion (in precedenza Sophos Central) 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?

Stabilire il percorso firmware prima del backup

La XG non può essere aggiornata a SFOS 21.0 o 22.0. Sophos distingue quindi il restore in base alla versione della XG sorgente; sulla XGS Appliance di destinazione, Backup-Restore Assistant richiede SFOS 20.0 MR2 o successivo:

• Con 19.5 MR4 o qualsiasi versione 20.0, creare direttamente il backup e mappare le interfacce durante il restore con Backup-Restore Assistant.
• Con 19.5 MR3 o precedente, la migrazione è possibile ma l’assistente non appare. Sophos consiglia prima l’aggiornamento a 19.5 MR4 o 20.0 MR2 e successive, purché questo passaggio intermedio sia ancora supportato e operativamente accettabile.

Il Setup Assistant della nuova XGS Appliance aggiorna la destinazione all’ultima versione proposta. Se il passaggio introduce anche SFOS 22, consultare la guida all’aggiornamento firmware di Sophos Firewall prima della finestra di manutenzione. Una configurazione legacy Remote Access IPsec blocca gli aggiornamenti a 22.0 MR1 e successive; il legacy CLI VLAN tagging su bridge interfaces blocca 22.0 MR2 e successive, e i backup che lo contengono non si possono ripristinare nemmeno su 22.0 GA o successive. SFOS 22 può inoltre richiedere spazio disco aggiuntivo e modifica il comportamento delle VPN IPsec policy-based.

Raccomandazione Avanet: combinare cambio hardware e major firmware change nella stessa finestra solo dopo questi controlli. Altrimenti un guasto lascia irrisolto se la causa sia backup, port mapping o firmware.

Backup-Restore Assistant e port mapping

Port mapping e Backup-Restore Assistant devono essere pianificati per le appliance esatte di origine e destinazione: nomi e numero delle porte, moduli Flexi Port, varianti wireless e modelli di destinazione non coincidono sempre 1:1. I moduli Flexi Port XG non sono compatibili con XGS e devono essere sostituiti con moduli XGS adeguati.

Nella pratica, prima del restore conviene preparare una tabella porte:

• Da Port1 a Port1 per la LAN: verificare VLAN, DHCP e DNS.
• Da Port2 a Port2 per la WAN: verificare gateway, Alias-IP e NAT.
• Da Port3 a Port4 per la DMZ: verificare Firewall Rules, WAF e DNAT.
• Da Flexi Port a un nuovo modulo: verificare uplink, trunk e compatibilità del modulo.

L’assistente mostra solo porte fisiche. Le interfacce VLAN e alias seguono la Parent Interface; LAG e bridge vengono ricreati dai membri fisici mappati. Le interfacce vincolate non mappate possono diventare pseudo ports. Verificare quindi anche Zone, IP Assignment, Link Mode, Parent Interface e appartenenza, non solo il numero porta.

I modelli wireless hanno limiti aggiuntivi. Per il restore di un backup XG Wireless o XGS Wireless Gen.1 su un modello XGS Wireless Gen.2, Sophos richiede, tra l’altro, WPA2 o successivo, nessun TKIP, nessuna interfaccia wireless in bridge fisici e al massimo otto SSID univoci su LocalWiFi0 e LocalWiFi1. Il restore su un modello senza WLAN integrata richiede di rimuovere le reti wireless prima del backup. Trattare questa modifica come passaggio separato e verificato, non improvvisato durante il cutover.

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 nuove XGS Appliances. Se un backup HA viene ripristinato su una nuova XGS Appliance senza HA, il restore non ricrea la configurazione HA, che va configurata manualmente. Stesso modello, versione firmware, licenze, porta HA, monitoring, passphrase, cambio ruoli e finestra di test richiedono quindi un flusso separato, per esempio Configurare Sophos Firewall High Availability.

Riallineare Sophos Fusion, Reporting, SD-WAN e ZTNA

Dopo il restore, la nuova XGS Appliance non è automaticamente integrata allo stesso modo in ogni funzione Sophos Fusion. A seconda dell’ambiente, bisogna:

• registrare il nuovo firewall in Sophos Fusion,
• verificare Firewall Management e Central Firewall Reporting,
• assegnare al dispositivo sostitutivo la licenza Central Firewall Reporting separata e i relativi dati; i report locali XG non vengono trasferiti,
• per SD-WAN Connection Groups, eliminare prima sulla XGS Appliance regole e tunnel creati da Sophos Fusion con prefisso Central_, poi aggiungerla al gruppo,
• spostare ZTNA gateways sul nuovo firewall,
• testare associazione SD-RED e Access Points; se la XG resta collegata in parallelo, eliminarvi la configurazione SD-RED e accettare gli Access Points sulla XGS Appliance,
• 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 Fusion. 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 Appliance documentati.
• Compatibilità di restore degli esatti modelli sorgente e destinazione verificata nello strumento Sophos.
• Backup attuale creato e password di restore conservata in modo sicuro.
• Secure Storage Master Key attuale ed eventualmente precedente, oltre alla password del backup, disponibili separatamente e in sicurezza.
• Port mapping per WAN, LAN, DMZ, VLAN trunks e HA preparato.
• Flexi Ports XG sostituite con moduli XGS compatibili; limiti wireless verificati.
• Trasferimento licenza, registrazione in Sophos Fusion e stato supporto verificati.
• Per SFOS 22: legacy IPsec, CLI VLAN tagging, spazio disco e VPN IPsec policy-based verificati.
• VPN, NAT, WAF, SD-WAN, DHCP, DNS e routing preparati come lista di test.
• RED, Access Points, ZTNA, Central Firewall 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.

Rollback con soglia di interruzione chiara

Mantenere la vecchia XG invariata, spenta o fisicamente isolata, e disponibile con un piano cavi etichettato fino all’accettazione. Prima del cutover definire un orario e criteri misurabili di interruzione, ad esempio WAN Gateway irraggiungibile, pubblicazione DNAT critica non disponibile o tunnel VPN business-critical ancora down dopo il tempo di diagnosi riservato.

Per il rollback isolare la XGS Appliance, ripristinare il cablaggio sulla XG secondo il piano e solo allora accendere la XG. Ricontrollare WAN, routing, VPN e servizi pubblicati. Le modifiche eseguite durante il test della XGS Appliance non sono automaticamente presenti sulla vecchia XG: registrarle e valutarle dopo il rollback. Non resettare né dismettere la XG prima che la XGS Appliance sia accettata come stabile, sottoposta a backup e documentata.

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 in Sophos Fusion 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 Firewall 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.

FAQ