Sophos XG vs. XGS: skillnader, EOL och migrering

XGS-serien är efterföljaren till XG-serien sedan 2021. Den ursprungliga jämförelsen mellan gammal och ny hårdvara är idag inte längre bara en prestandafråga. De sista XG Series-modellerna nådde End of Life den 31 mars 2025; vissa äldre modeller var EOL redan tidigare. Dessutom stöder SFOS 21.0 och senare firmwarelinjer inte längre XG- och SG-Series-hårdvara.

Därmed är den egentliga frågan inte längre Lönar sig XGS?, utan Hur planerar man övergången från XG på ett kontrollerat sätt, utan att missa routing, VPN, Central Reporting eller fjärrplatser?

Kort svar

XG och XGS kör båda Sophos Firewall OS, men de är inte längre likvärdiga plattformar.

• Lifecycle: XG: End of Life. XGS: aktivt stödd hårdvaruplattform.
• Firmware: XG: ingen SFOS-version från 21.0 och framåt. XGS: aktuella SFOS-linjer, inklusive 22.0.
• Prestanda: XG: äldre plattform med mindre marginal för modern Inspection. XGS: Xstream-arkitektur; tillgänglig acceleration beror på modell, firmware och dataväg.
• Drift: XG: migrations- och supportgräns. XGS: standardplattform för nya hårdvaruprojekt.
• Planering: XG: ersättning krävs. XGS: sizing, Port Mapping och licensöverföring måste vara fastställda före cutover.

En XG bör därför inte längre betraktas som en normal firewallmodell, utan som en äldre plattform som ska ersättas. För licens- och Lifecycle-frågor passar dessutom Sophos Product Lifecycle-kalendern.

Vad End of Life betyder i firewalldrift

End of Life är för firewallhårdvara inte en formell rad i en tabell. En firewall står vid nätkanten, terminerar VPN:er, filtrerar webb- och applikationstrafik, skyddar publicerade tjänster och innehåller ofta känsliga konfigurationer. Om den plattformen inte längre underhålls uppstår en verklig driftrisk.

För en produktiv XG är framför allt dessa punkter kritiska:

• Nya SFOS-firmwarelinjer kan inte längre användas.
• Sophos varnar för att programuppdateringar upphör kort efter EOL; tillverkarsupport och hårdvaruersättning kan därför inte längre planeras tillförlitligt.
• Nya funktioner som aktuella VPN-, logging-, Health Check- eller säkerhetsfunktioner hamnar på stödda plattformar.
• Licenser, RMA, ersättningsenheter och supportärenden blir svårare att planera.
• Revisioner och cyberförsäkringar kan bedöma fortsatt drift av en EOL-firewall kritiskt.

Detta är särskilt kritiskt för firewalls med aktiv Remote Access VPN, Site-to-Site VPN, WAF, TLS Inspection, Web Protection, publicerade servrar eller brett åtkomlig WebAdmin. I sådana miljöer bör fortsatt drift av en XG endast gälla som en tidsbegränsad övergångslösning med dokumenterad migrationsplan.

De tre viktigaste skillnaderna

XG och XGS kan se liknande ut från utsidan beroende på modell, men tekniskt och operativt skiljer de sig tydligt.

• Lifecycle och Firmware: XG-hårdvara är End of Life. SFOS 21.0, 21.5 och 22.0 stöder inte längre XG- och SG-Series-hårdvara. XGS är den stödda hårdvaruplattformen för aktuella SFOS-versioner.
• Arkitektur och prestanda: XGS använder Xstream-arkitekturen och modellberoende acceleration. Det ger större marginal för aktuella säkerhetsfunktioner, VPN, TLS Inspection, IPS, Web Protection och routing. Databladet för den konkreta modellen är fortsatt avgörande.
• Migrering och drift: Övergången till XGS är ett migrationsprojekt. Backup-kompatibilitet, Port Mapping, licensstatus, HA, SD-WAN, Central Reporting, RED, Access Points och ZTNA Gateways måste kontrolleras.

Arkitektur: Xstream i stället för gammal XG-plattform

XGS-serien byggdes för Xstream-arkitekturen, vilket är särskilt relevant när skyddsfunktioner är aktiverade. Accelererade datavägar och tillgängliga resurser skiljer sig dock mellan desktop-, 1U- och 2U-modeller; serienamnet ensamt anger ingen throughput. Många äldre XG-installationer dimensionerades dessutom med mindre TLS Inspection, molntrafik, SD-WAN och Remote Access-belastning.

En XGS Appliance ger, beroende på modell, större marginal för:

• IPS, Web Protection och Application Control.
• TLS Inspection och större certifikat-/CA-utrullningar.
• IPsec VPN, SSL VPN, SD-WAN och flera WAN-uplinks.
• Fler samtidiga användare, sessioner och regler.
• Nya SFOS-funktioner som inte längre är tillgängliga på XG.

Alla datavägar blir inte automatiskt snabbare bara för att en XGS Appliance installeras. Fel sizing, för små modeller, dåligt planerad TLS Inspection eller oklar VPN-arkitektur kan också bromsa en ny firewall. För valet av rätt målmodell är Sophos Firewall Sizing Guide viktigare än en enkel 1:1-modelljämförelse.

När en XG bör ersättas

En XG-ersättning bör inte planeras först när en firmwareuppgradering blockeras eller ett hårdvarufel redan skapar press. Senast vid dessa signaler är ett migrationsprojekt nödvändigt:

• Firewallen ska uppdateras till SFOS 21.0, 21.5, 22.0 eller senare.
• Det finns Remote Access VPN, WAF, publikt åtkomliga tjänster eller flera Site-to-Site VPN:er.
• Support, revision, RMA eller licensförlängning kan inte längre hanteras rent.
• Den befintliga XG:n ligger på gränsen under IPS, Web Protection, TLS Inspection eller VPN-belastning.
• RED, Access Points, SD-WAN, Central Reporting eller ZTNA hänger på den befintliga firewallen.
• Ett HA-kluster, Port Redesign eller leverantörsbyte står ändå på tur.

Om en XG fortfarande körs produktivt bör först en aktuell backup, Secure Storage Master Key och den använda firmwareversionen dokumenteras. Förloppet beskrivs mer detaljerat i artikeln Skapa eller återställa Sophos Firewall-backup.

Planera migrering från XG till XGS

Vid migrering från XG till XGS bör man inte bara välja den till synes närmaste modellen. Mer meningsfullt är en kort inventering före servicefönstret:

• Vilka WAN-, LAN- och DMZ-portar används faktiskt?
• Finns HA, VLAN-stacks, RED-, SD-WAN- eller VPN-specialfall?
• Vilka säkerhetsfunktioner är aktiva idag och vilka ska aktiveras ytterligare i framtiden?
• Vilka IPsec-, SSL-VPN-, Sophos Connect- eller ZTNA-scenarier är produktiva?
• Finns Central Firewall Reporting, Sophos Central Management eller SD-WAN Connection Groups?
• Är Access Points eller SD-RED-enheter bundna till den här firewallen?
• Finns statiska rutter, Alias-IP-adresser, DNAT-regler eller WAF-publiceringar som måste vara åtkomliga direkt efter bytet?
• Ska målplattformen åter vara hårdvara eller en virtuell eller Cloud Appliance?

Bestäm firmwarevägen före backup

XG kan inte uppgraderas till SFOS 21.0 eller 22.0. Sophos skiljer därför restore utifrån versionen på käll-XG; på mål-XGS Appliance kräver Backup-Restore Assistant SFOS 20.0 MR2 eller senare:

• Med 19.5 MR4 eller valfri 20.0-version tar man backup direkt och mappar interfaces under restore med Backup-Restore Assistant.
• Med 19.5 MR3 eller äldre är migrering möjlig, men assistant visas inte. Sophos rekommenderar först en uppgradering till 19.5 MR4 eller 20.0 MR2 och senare, förutsatt att mellansteget fortfarande stöds och är operativt rimligt.

Setup Assistant på den nya XGS Appliance uppgraderar målet till den senaste version som erbjuds. Om bytet även inför SFOS 22 ska guiden för uppdatering av Sophos Firewall-firmware läsas före servicefönstret. En legacy Remote Access IPsec-konfiguration blockerar uppgradering till 22.0 MR1 och senare; legacy CLI VLAN tagging på bridge interfaces blockerar 22.0 MR2 och senare, och backups som innehåller detta kan inte heller återställas till 22.0 GA eller senare. SFOS 22 kan dessutom kräva extra diskutrymme och ändrar beteendet för policy-based IPsec VPNs.

Avanet-rekommendation: kombinera hårdvarubyte och en stor firmwareändring i samma fönster först när dessa kontroller är klara. Annars blir det vid fel onödigt oklart om orsaken är backup, Port Mapping eller firmware.

Backup-Restore Assistant och Port Mapping

Port Mapping och Backup-Restore Assistant måste planeras för de exakta käll- och målenheterna: portnamn och portantal, Flexi Port-moduler, wireless-varianter och målmodeller passar inte alltid 1:1. XG Flexi Port-moduler är inte kompatibla med XGS och måste ersättas med lämpliga XGS-moduler.

I praktiken bör man förbereda en porttabell före restore:

• Port1 till Port1 för LAN: kontrollera VLAN, DHCP och DNS.
• Port2 till Port2 för WAN: kontrollera Gateway, Alias-IP och NAT.
• Port3 till Port4 för DMZ: kontrollera Firewall Rules, WAF och DNAT.
• Flexi Port till en ny modul: kontrollera Uplink, Trunk och modulkompatibilitet.

Assistant visar endast fysiska portar. VLAN- och aliasinterfaces följer sin Parent Interface; LAGs och bridges återskapas från de mappade fysiska medlemmarna. Omappade bundna interfaces kan bli pseudo ports. Kontrollera därför även Zone, IP Assignment, Link Mode, Parent Interface och medlemskap, inte bara portnumret.

Wireless-modeller har ytterligare restoregränser. Vid restore av en XG Wireless- eller Gen.1 XGS Wireless-backup till en Gen.2 XGS Wireless-modell anger Sophos bland annat WPA2 eller senare, ingen TKIP, inga wireless-interfaces i fysiska bridges och högst åtta unika SSIDs på LocalWiFi0 och LocalWiFi1. Restore till en modell utan integrerad WLAN kräver att wireless-nätverken tas bort före backup. Behandla ändringen som ett separat, verifierat konfigurationssteg och improvisera inte under cutover.

Om WAN-MAC-adressen ändras kan framförvarande routrar eller leverantörens CPE:er fortfarande hålla gamla ARP-poster. Vid sådana symptom hjälper artikeln Åtgärda Sophos Firewall ARP-problem efter migrering.

Hantera HA separat

Ett XG-HA-kluster ersätts inte bara genom restore på två nya XGS Appliances. Om en HA-backup återställs till en ny XGS Appliance utan HA återskapar restore inte HA-konfigurationen; den måste konfigureras manuellt. Modelllikhet, firmwarestatus, licenser, HA-port, monitoring, passphrase, rollbyte och testfönster kräver därför en separat procedur, till exempel Konfigurera Sophos Firewall High Availability.

Följa upp Central, Reporting, SD-WAN och ZTNA

Efter restore är den nya XGS Appliance inte automatiskt lika integrerad i varje Sophos Central-funktion. Beroende på miljö måste man:

• registrera den nya firewallen i Sophos Central,
• kontrollera Firewall Management och Central Reporting,
• tilldela den separata Central Firewall Reporting-licensen och dess data till ersättningsenheten; lokala XG-rapporter överförs inte,
• för SD-WAN Connection Groups först radera regler och tunnlar som Central skapat med prefixet Central_ på XGS Appliance och sedan lägga till den i gruppen,
• flytta ZTNA Gateways till den nya firewallen,
• testa SD-RED- och Access Point-tilldelning; om XG förblir parallellt ansluten, radera dess SD-RED-konfiguration och acceptera Access Points på XGS Appliance,
• kontrollera notifieringar, backups och schemalagda rapporter på nytt.

För Reporting-upplägg passar dessutom Aktivera Central Firewall Reporting. För operativa bevis efter migreringen är Testa Sophos Firewall-regel med Log Viewer och Packet Capture och Analysera tappade paket på Sophos Firewall mer hjälpsamma än ett enkelt ping-test.

Typiska fel vid XG-till-XGS-migreringar

För liten målmodell

En till synes passande efterföljarmodell kan vara för liten om fler användare, fler VPN:er, mer TLS Inspection, mer Web Protection eller mer bandbredd har tillkommit sedan den ursprungliga XG-anskaffningen. Därför bör man inte bara jämföra XG-modell mot XGS-modell, utan även ta hänsyn till verklig belastning, aktiva skyddsfunktioner och tillväxt.

Port Mapping bara grovt kontrollerad

Om LAN, WAN, DMZ, VLAN Trunks, HA-portar eller leverantörsanslutningar kopplas annorlunda räcker en lyckad restore inte. Efter restore måste Interface Zones, Gateways, SD-WAN-rutter, NAT-regler, WAF-regler och Firewall Rules kontrolleras målinriktat.

Gammal firmware eller gammalt backup-läge

Ett mycket gammalt backupläge ökar risken för att Interface Mapping, certifikat, VPN:er eller specialkonfigurationer migreras oväntat. Före bytet bör den gamla firewallen, så långt det fortfarande är meningsfullt och stöds, föras till en lämplig version och en färsk backup skapas.

Efterföljande system glömda

Många migreringar misslyckas inte på restore, utan på beroende system: Monitoring, Syslog, SIEM, backup-e-post, VPN-klienter, leverantörs-ARP, DNS, DHCP, RED, Access Points eller Sophos Central. Dessa punkter hör hemma i checklistan, inte i felsökningen efter omkopplingen.

Checklista före bytet

• Aktuell firmware för XG och målfirmware för XGS Appliance är dokumenterade.
• Restorekompatibilitet för de exakta käll- och målmodellerna är kontrollerad i Sophos-verktyget.
• Aktuell backup är skapad och restore-lösenordet säkert sparat.
• Aktuell och vid behov tidigare Secure Storage Master Key samt backuplösenord är säkert och separat tillgängliga.
• Port Mapping för WAN, LAN, DMZ, VLAN Trunks och HA är förberett.
• XG Flexi Ports är ersatta med kompatibla XGS-moduler; wireless-begränsningar är kontrollerade.
• Licensöverföring, Central-registrering och supportstatus är kontrollerade.
• För SFOS 22 är legacy IPsec, CLI VLAN tagging, diskutrymme och policy-based IPsec VPNs kontrollerade.
• VPN:er, NAT, WAF, SD-WAN, DHCP, DNS och routing är förberedda som testlista.
• RED, Access Points, ZTNA, Central Reporting och Monitoring är beaktade.
• Rollback-plan med gammal enhet, kabelplan och servicefönster är definierad.
• Kontaktpersoner för leverantör, DNS, Monitoring och applikationer är nåbara.

Rollback med en tydlig avbrytningsgräns

Behåll den gamla XG oförändrad, avstängd eller fysiskt isolerad, och tillgänglig med en märkt kabelplan fram till godkännandet. Definiera före cutover en tidpunkt och mätbara avbrytningskriterier, exempelvis en oåtkomlig WAN Gateway, en kritisk DNAT-publicering som inte fungerar eller en affärskritisk VPN-tunnel som fortfarande är down efter den avsatta diagnostiden.

Vid rollback isoleras XGS Appliance, kablaget återställs till XG enligt planen och först därefter slås XG på. Kontrollera WAN, routing, VPN och publicerade tjänster igen. Ändringar som görs under testet av XGS Appliance finns inte automatiskt på den gamla XG; dokumentera och bedöm dem efter rollback. Återställ eller avveckla inte XG förrän XGS Appliance har godkänts som stabil, säkerhetskopierats och dokumenterats.

Kontroll efter migreringen

Efter omkopplingen bör man inte bara kontrollera om internet fungerar. En ren migrering är först klar när de viktigaste driftfunktionerna har validerats:

• Kontrollera Dashboard, licensstatus, Central-registrering och backup-e-post.
• Testa WAN Gateway, Alias-IP-adresser, NAT och publicerade tjänster.
• Kontrollera Site-to-Site VPN, Remote Access VPN och Sophos Connect-profiler.
• Kontrollera SD-WAN-rutter, statiska rutter och Route Precedence.
• Testa Firewall Rules med loggning.
• Stickprovskontrollera IPS, Web Protection, TLS Inspection och Application Control.
• Kontrollera RED- och Access Point-anslutningar.
• Testa Syslog, Central Reporting, notifieringar och Monitoring.
• Ta den gamla XG:n ur drift först efter en stabil driftfas.

Om enskilda mål inte är åtkomliga direkt efter migreringen bör man arbeta systematiskt med Log Viewer, Packet Capture och routingkontroller. För grunddiagnosen hjälper Använda Sophos Firewall Packet Capture i WebAdmin och Ändra Sophos Firewall Route Precedence säkert.

FAQ