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. Sophos XG-hårdvara är End of Life sedan 31 mars 2025. 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 rent, 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: End of Life. aktivt stödd hårdvaruplattform.
- Firmware: ingen SFOS 21.0/21.5/22.0-support. aktuella SFOS-versioner.
- Prestanda: äldre plattform, mindre marginal för modern Inspection. Xstream-arkitektur med större marginal.
- Drift: migrationsrisk och supportgräns. standardplattform för nya projekt.
- Planering: ersättning krävs. planera sizing, Port Mapping och licensöverföring rent.
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.
- Säkerhetsuppdateringar, Hotfixes och tillverkarens support är begränsade eller inte längre tillgängliga.
- 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 med dedikerade accelerationsfunktioner. Det ger större marginal för aktuella säkerhetsfunktioner, VPN, TLS Inspection, IPS, Web Protection och routing.
- 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. I vardagen är det inte bara ett marknadsföringsbegrepp, utan framför allt relevant när skyddsfunktioner är aktiverade. Många äldre XG-installationer dimensionerades ursprungligen när det fanns mindre TLS Inspection, mindre molntrafik, mindre SD-WAN och mindre Remote Access-belastning.
En XGS 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 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?
Backup-Restore Assistant och Port Mapping
Migration Center för XG-till-XGS-migreringar är den viktigaste externa referensen för Port Mapping och Backup-Restore Assistant. Det är viktigt eftersom portnamn, portantal, Flexi-Port-moduler, Wireless-modeller och målmodeller inte alltid passar 1:1.
I praktiken bör man förbereda en porttabell före restore:
- Port1: Port1. LAN. VLAN, DHCP, DNS.
- Port2: Port2. WAN. Gateway, Alias-IP, NAT.
- Port3: Port4. DMZ. Firewall Rules, WAF, DNAT.
- Flexi Port: ny modul. Uplink eller Trunk. modulkompatibilitet.
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-enheter. Man måste planera HA medvetet på nytt: modelllikhet, firmwarestatus, licenser, HA-port, monitoring, passphrase, rollbyte och testfönster. Detaljerna hör hemma i HA-planeringen, till exempel med Konfigurera Sophos Firewall High Availability.
Följa upp Central, Reporting, SD-WAN och ZTNA
Efter restore är den nya XGS 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,
- kontrollera Central Firewall Reporting-licens och datatilldelning,
- tilldela SD-WAN Connection Groups på nytt,
- flytta ZTNA Gateways till den nya firewallen,
- testa RED- och Access Point-tilldelning,
- 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 är dokumenterade.
- Aktuell backup är skapad och restore-lösenordet säkert sparat.
- Secure Storage Master Key är känd och dokumenterad.
- Port Mapping för WAN, LAN, DMZ, VLAN Trunks och HA är förberett.
- Licensöverföring, Central-registrering och supportstatus är 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.
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.