Sophos XG vs. XGS: Unterschiede, EOL und Migration

Die XGS-Serie ist seit 2021 der Nachfolger der XG-Serie. Der ursprüngliche Vergleich zwischen alter und neuer Hardware ist heute aber nicht mehr nur eine Leistungsfrage. Die letzten XG-Series-Modelle erreichten am 31. März 2025 ihr End of Life; einzelne ältere Modelle waren bereits vorher EOL. Ausserdem unterstützen SFOS 21.0 und spätere Firmwarelinien keine XG- und SG-Series-Hardware mehr.

Damit ist die eigentliche Frage nicht mehr Lohnt sich XGS?, sondern Wie plant man den Umstieg von XG sauber, ohne Routing, VPN, Central Firewall Reporting oder Remote-Standorte zu übersehen?

Kurzantwort

XG und XGS laufen beide mit Sophos Firewall OS, sind aber nicht mehr gleichwertige Plattformen.

Die wichtigsten Unterschiede:

• Lifecycle: XG: End of Life. XGS: aktiv unterstützte Hardwareplattform.
• Firmware: XG: keine SFOS-Version ab 21.0. XGS: aktuelle SFOS-Linien einschliesslich 22.0.
• Leistung: XG: ältere Plattform mit weniger Reserven für moderne Inspection. XGS: Xstream-Architektur; die tatsächlich nutzbare Beschleunigung hängt von Modell, Firmware und Datenpfad ab.
• Betrieb: XG: Migrations- und Supportgrenze. XGS: Standardplattform für neue Hardwareprojekte.
• Planung: XG: Ablösung nötig. XGS: Sizing, Port-Mapping und Lizenztransfer müssen vor dem Cutover feststehen.

Eine XG sollte deshalb nicht mehr als normales Firewall-Modell betrachtet werden, sondern als abzulösende Altplattform. Für Lizenz- und Lifecycle-Fragen passt zusätzlich der Sophos Product Lifecycle Kalender.

Was End of Life im Firewall-Betrieb bedeutet

End of Life ist bei Firewall-Hardware kein formaler Eintrag in einer Tabelle. Eine Firewall steht am Netzrand, terminiert VPNs, filtert Web- und Applikationsverkehr, schützt veröffentlichte Dienste und enthält oft sensible Konfigurationen. Wenn diese Plattform nicht mehr gepflegt wird, entsteht ein echtes Betriebsrisiko.

Für eine produktive XG sind vor allem diese Punkte kritisch:

• Neue SFOS-Firmwarelinien können nicht mehr genutzt werden.
• Sophos warnt, dass Softwareupdates kurz nach dem EOL enden; Hersteller-Support und Hardwareersatz sind damit nicht mehr verlässlich planbar.
• Neue Funktionen wie aktuelle VPN-, Logging-, Health-Check- oder Sicherheitsfeatures landen auf unterstützten Plattformen.
• Lizenzen, RMA, Ersatzgeräte und Supportfälle werden schwieriger planbar.
• Audits und Cyberversicherungen können den Weiterbetrieb einer EOL-Firewall kritisch bewerten.

Besonders kritisch ist das bei Firewalls mit aktivem Remote Access VPN, Site-to-Site VPN, WAF, TLS Inspection, Web Protection, veröffentlichten Servern oder breit erreichbarem WebAdmin. In solchen Umgebungen sollte der Weiterbetrieb einer XG nur noch als befristete Übergangslösung mit dokumentiertem Migrationsplan gelten.

Die drei wichtigsten Unterschiede

XG und XGS sehen von aussen je nach Modell ähnlich aus, unterscheiden sich aber technisch und operativ deutlich.

• Lifecycle und Firmware: XG-Hardware ist End of Life. SFOS 21.0, 21.5 und 22.0 unterstützen XG- und SG-Series-Hardware nicht mehr. XGS ist die unterstützte Hardwareplattform für aktuelle SFOS-Versionen.
• Architektur und Leistung: XGS nutzt die Xstream-Architektur und modellabhängige Beschleunigungsfunktionen. Dadurch gibt es mehr Reserven für aktuelle Sicherheitsfunktionen, VPN, TLS Inspection, IPS, Web Protection und Routing. Das Datenblatt des konkreten Modells bleibt für die Beschleunigung massgeblich.
• Migration und Betrieb: Der Wechsel auf XGS ist ein Migrationsprojekt. Backup-Kompatibilität, Port-Mapping, Lizenzstand, HA, SD-WAN, Central Firewall Reporting, RED, Access Points und ZTNA-Gateways müssen geprüft werden.

Architektur: Xstream statt alter XG-Plattform

Die XGS-Serie wurde für die Xstream-Architektur gebaut. Das ist im Alltag vor allem bei aktivierten Schutzfunktionen relevant. Beschleunigte Datenpfade und verfügbare Ressourcen unterscheiden sich jedoch zwischen Desktop-, 1U- und 2U-Modellen; aus dem Seriennamen allein lässt sich kein Durchsatz ableiten. Viele ältere XG-Installationen wurden zudem dimensioniert, als weniger TLS Inspection, Cloud-Traffic, SD-WAN und Remote-Access-Last vorhanden war.

Eine XGS Appliance bringt je nach Modell mehr Reserven für:

• IPS, Web Protection und Application Control.
• TLS Inspection und grössere Zertifikats-/CA-Rollouts.
• IPsec VPN, SSL VPN, SD-WAN und mehrere WAN-Uplinks.
• Mehr gleichzeitige Benutzer, Sitzungen und Regeln.
• Neue SFOS-Funktionen, die auf XG gar nicht mehr verfügbar sind.

Nicht jeder Datenpfad wird automatisch schneller, nur weil eine XGS Appliance eingebaut wird. Falsches Sizing, zu kleine Modelle, schlecht geplante TLS Inspection oder unklare VPN-Architektur können auch eine neue Firewall ausbremsen. Für die Auswahl des passenden Zielmodells ist der Sophos Firewall Sizing Guide wichtiger als ein einfacher 1:1-Modellvergleich.

Wann eine XG abgelöst werden sollte

Eine XG-Ablösung sollte nicht erst geplant werden, wenn ein Firmware-Upgrade blockiert oder ein Hardwaredefekt bereits Druck erzeugt. Spätestens bei diesen Signalen ist ein Migrationsprojekt fällig:

• Die Firewall soll auf SFOS 21.0, 21.5, 22.0 oder neuer aktualisiert werden.
• Es gibt Remote Access VPN, WAF, öffentlich erreichbare Dienste oder mehrere Site-to-Site VPNs.
• Support, Audit, RMA oder Lizenzverlängerung sind nicht mehr sauber abbildbar.
• Die bestehende XG ist unter IPS, Web Protection, TLS Inspection oder VPN-Last am Limit.
• RED, Access Points, SD-WAN, Central Firewall Reporting oder ZTNA hängen an der bestehenden Firewall.
• Ein HA-Cluster, Port-Redesign oder Providerwechsel steht ohnehin an.

Wenn eine XG noch produktiv läuft, sollte zuerst ein aktuelles Backup, der Secure Storage Master Key und die verwendete Firmware-Version dokumentiert werden. Der Ablauf ist im Artikel Sophos Firewall Backup erstellen oder wiederherstellen detaillierter beschrieben.

Migration von XG auf XGS planen

Bei einer Migration von XG auf XGS sollte man nicht nur das vermeintlich nächstgelegene Modell auswählen. Sinnvoller ist eine kurze Bestandsaufnahme vor dem Wartungsfenster:

• Welche WAN-, LAN- und DMZ-Ports werden effektiv genutzt?
• Gibt es HA, VLAN-Stacks, RED-, SD-WAN- oder VPN-Sonderfälle?
• Welche Sicherheitsfunktionen sind heute aktiv und welche sollen in Zukunft zusätzlich aktiviert werden?
• Welche IPsec-, SSL-VPN-, Sophos-Connect- oder ZTNA-Szenarien sind produktiv?
• Gibt es Central Firewall Reporting, Verwaltung über Sophos Fusion oder SD-WAN Connection Groups?
• Sind Access Points oder SD-RED Geräte an diese Firewall gebunden?
• Gibt es statische Routen, Alias-IP-Adressen, DNAT-Regeln oder WAF-Veröffentlichungen, die nach dem Wechsel sofort erreichbar sein müssen?
• Soll die Zielplattform wieder Hardware sein oder eine virtuelle oder Cloud-Appliance?

Firmwarepfad vor dem Backup festlegen

Die XG kann nicht auf SFOS 21.0 oder 22.0 aktualisiert werden. Sophos unterscheidet beim Restore deshalb nach dem Stand der Quell-XG; auf der Ziel-XGS Appliance setzt der Backup-Restore Assistant SFOS 20.0 MR2 oder neuer voraus:

• Mit 19.5 MR4 oder einer 20.0-Version erstellt man das Backup direkt und ordnet die Interfaces beim Restore mit dem Backup-Restore Assistant zu.
• Mit 19.5 MR3 oder älter kann man zwar migrieren, der Assistant erscheint aber nicht. Sophos empfiehlt, die XG vorher auf 19.5 MR4 beziehungsweise 20.0 MR2 oder neuer zu bringen, sofern dieser Zwischenschritt noch unterstützt und betrieblich vertretbar ist.

Der Setup Assistant der neuen XGS Appliance aktualisiert das Ziel auf die neueste angebotene Version. Wer gleichzeitig auf SFOS 22 wechselt, muss deshalb vor dem Wartungsfenster den Leitfaden zum Sophos Firewall Firmware Update prüfen. Insbesondere verhindern eine alte Remote-Access-IPsec-Konfiguration ab 22.0 MR1 und altes CLI-VLAN-Tagging auf Bridge-Interfaces ab 22.0 MR2 ein Upgrade; Backups mit letzterer Konfiguration lassen sich auch nicht auf 22.0 GA oder neuer wiederherstellen. SFOS 22 kann ausserdem zusätzlichen Speicherplatz verlangen und ändert das Verhalten policy-basierter IPsec-VPNs.

Avanet-Empfehlung: Hardwarewechsel und grossen Firmwarewechsel nur dann im selben Fenster durchführen, wenn diese Prüfungen abgeschlossen sind. Sonst entsteht bei einem Fehler unnötig die Frage, ob Backup, Port-Mapping oder Firmwareänderung die Ursache ist.

Backup-Restore Assistant und Port-Mapping

Port-Mapping und Backup-Restore Assistant müssen für das genaue Quell- und Zielgerät geplant werden: Portnamen und Portanzahl, Flexi-Port-Module, Wireless-Varianten und Zielmodelle passen nicht immer 1:1. XG-Flexi-Port-Module sind mit XGS nicht kompatibel und müssen durch passende XGS-Module ersetzt werden.

In der Praxis sollte man vor dem Restore ein Port-Mapping vorbereiten:

• Port1 zu Port1 für LAN: VLANs, DHCP und DNS prüfen.
• Port2 zu Port2 für WAN: Gateway, Alias-IP und NAT prüfen.
• Port3 zu Port4 für DMZ: Firewall Rules, WAF und DNAT prüfen.
• Flexi Port zu neuem Modul: Uplink, Trunk und Modulkompatibilität prüfen.

Der Assistant zeigt nur physische Ports. VLAN- und Alias-Interfaces folgen ihrem Parent-Interface; LAGs und Bridges werden aus den zugeordneten physischen Mitgliedern neu gebildet. Nicht zugeordnete gebundene Interfaces können als Pseudo-Ports entstehen. Deshalb ist nicht allein die Portnummer zu kontrollieren, sondern auch Zone, IP-Zuweisung, Link Mode, Parent-Interface und Mitgliedschaft.

Bei Wireless-Modellen gelten zusätzliche Restore-Grenzen. Beim Restore einer XG Wireless oder Gen.1 XGS Wireless auf ein Gen.2-XGS-Wireless-Modell nennt Sophos unter anderem WPA2 oder neuer, kein TKIP, keine Wireless-Interfaces in physischen Bridges und höchstens acht eindeutige SSIDs auf LocalWiFi0 und LocalWiFi1. Ein Backup auf ein Modell ohne integriertes WLAN setzt voraus, dass die Wireless-Netzwerke vor dem Backup entfernt wurden. Diese Änderung gehört in einen separaten, geprüften Konfigurationsschritt und nicht spontan in das Cutover.

Wenn sich die WAN-MAC-Adresse ändert, können vorgeschaltete Router oder Provider-CPEs noch alte ARP-Einträge halten. Bei solchen Symptomen hilft der Artikel Sophos Firewall ARP-Problem nach Migration beheben.

HA separat behandeln

Ein XG-HA-Cluster wird nicht einfach durch Restore auf zwei neue XGS Appliances ersetzt. Wird ein HA-Backup auf eine neue XGS Appliance ohne bestehendes HA restauriert, stellt der Restore die HA-Konfiguration nicht wieder her; HA muss manuell eingerichtet werden. Modellgleichheit, Firmwarestand, Lizenzen, HA-Port, Monitoring, Passphrase, Rollenwechsel und Testfenster gehören deshalb in einen eigenen Ablauf, etwa mit Sophos Firewall High Availability einrichten.

Sophos Fusion, Reporting, SD-WAN und ZTNA nachziehen

Nach dem Restore ist die neue XGS Appliance nicht automatisch in jeder Sophos-Fusion-Funktion gleich eingebunden. Je nach Umgebung muss man:

• die neue Firewall in Sophos Fusion registrieren,
• Firewall Management und Central Firewall Reporting prüfen,
• die separate Central-Firewall-Reporting-Lizenz samt Daten dem Ersatzgerät zuordnen; lokale XG-Reports werden nicht übertragen,
• bei SD-WAN Connection Groups zuerst die von Sophos Fusion erzeugten Regeln und Tunnel mit Präfix Central_ auf der XGS Appliance löschen und sie danach der Gruppe zuordnen,
• ZTNA-Gateways auf die neue Firewall umstellen,
• SD-RED- und Access-Point-Zuordnung testen; bei parallel verbundener XG die SD-RED-Konfiguration dort löschen und Access Points auf der XGS Appliance akzeptieren,
• Benachrichtigungen, Backups und geplante Reports neu prüfen.

Für Reporting-Setups passt zusätzlich Central Firewall Reporting aktivieren. Für operative Nachweise nach der Migration sind Sophos Firewall Regel testen mit Log Viewer und Packet Capture und Sophos Firewall verworfene Pakete analysieren hilfreicher als ein blosser Ping-Test.

Typische Fehler bei XG-zu-XGS-Migrationen

Zu kleines Zielmodell

Ein scheinbar passendes Nachfolgemodell kann zu klein sein, wenn seit der ursprünglichen XG-Beschaffung mehr Benutzer, mehr VPNs, mehr TLS Inspection, mehr Web Protection oder mehr Bandbreite dazugekommen sind. Deshalb sollte man nicht nur XG-Modell gegen XGS-Modell vergleichen, sondern reale Last, aktive Schutzfunktionen und Wachstum berücksichtigen.

Port-Mapping nur grob geprüft

Wenn LAN, WAN, DMZ, VLAN-Trunks, HA-Ports oder Provideranschlüsse anders gesteckt werden, reicht ein erfolgreicher Restore nicht aus. Nach dem Restore müssen Interface-Zonen, Gateways, SD-WAN-Routen, NAT-Regeln, WAF-Regeln und Firewall Rules gezielt geprüft werden.

Alte Firmware oder alter Backup-Stand

Ein sehr alter Backup-Stand erhöht das Risiko, dass Interface-Mapping, Zertifikate, VPNs oder Sonderkonfigurationen unerwartet migrieren. Vor dem Wechsel sollte man die alte Firewall, soweit noch sinnvoll und unterstützt, auf einen geeigneten Stand bringen und ein frisches Backup erstellen.

Nachgelagerte Systeme vergessen

Viele Migrationen scheitern nicht am Restore, sondern an abhängigen Systemen: Monitoring, Syslog, SIEM, Backup-Mails, VPN-Clients, Provider-ARP, DNS, DHCP, RED, Access Points oder Sophos Fusion. Diese Punkte gehören in die Checkliste, nicht in die Fehlersuche nach dem Umschalten.

Checkliste vor dem Wechsel

• Aktuelle Firmware der XG und Ziel-Firmware der XGS Appliance dokumentiert.
• Restore-Kompatibilität des exakten Quell- und Zielmodells im Sophos-Tool geprüft.
• Aktuelles Backup erstellt und Restore-Passwort sicher abgelegt.
• Aktueller und gegebenenfalls früherer Secure Storage Master Key sowie Backup-Passwort getrennt sicher verfügbar.
• Port-Mapping für WAN, LAN, DMZ, VLAN-Trunks und HA vorbereitet.
• XG-Flexi-Ports durch kompatible XGS-Module ersetzt; Wireless-Einschränkungen geprüft.
• Lizenztransfer, Registrierung in Sophos Fusion und Supportstatus geprüft.
• Bei SFOS 22: Legacy-IPsec, CLI-VLAN-Tagging, Speicherplatz und policy-basierte IPsec-VPNs geprüft.
• VPNs, NAT, WAF, SD-WAN, DHCP, DNS und Routing als Testliste vorbereitet.
• RED, Access Points, ZTNA, Central Firewall Reporting und Monitoring berücksichtigt.
• Rollback-Plan mit altem Gerät, Kabelplan und Wartungsfenster definiert.
• Ansprechpartner für Provider, DNS, Monitoring und Applikationen erreichbar.

Rollback mit klarer Abbruchgrenze

Die alte XG bleibt bis zur Abnahme unverändert, ausgeschaltet oder physisch isoliert und mit beschriftetem Kabelplan verfügbar. Vor dem Cutover definiert man eine Uhrzeit und messbare Abbruchkriterien, beispielsweise: WAN-Gateway nicht erreichbar, zentrale DNAT-Publikation ausgefallen oder geschäftskritischer VPN-Tunnel nach der reservierten Diagnosezeit weiterhin down.

Beim Rollback wird die XGS Appliance isoliert, die Verkabelung gemäss Plan auf die XG zurückgesetzt und erst dann die XG gestartet. Danach prüft man WAN, Routing, VPN und veröffentlichte Dienste erneut. Änderungen, die Benutzer oder Administratoren während des Testbetriebs der XGS Appliance vorgenommen haben, befinden sich nicht automatisch auf der alten XG; sie müssen protokolliert und nach dem Rollback beurteilt werden. Die XG darf deshalb weder zurückgesetzt noch entsorgt werden, bevor die XGS Appliance stabil abgenommen, gesichert und dokumentiert ist.

Prüfung nach der Migration

Nach dem Umschalten sollte man nicht nur prüfen, ob das Internet funktioniert. Eine saubere Migration ist erst dann abgeschlossen, wenn die wichtigsten Betriebsfunktionen validiert sind:

• Dashboard, Lizenzstatus, Registrierung in Sophos Fusion und Backup-Mail prüfen.
• WAN-Gateway, Alias-IP-Adressen, NAT und veröffentlichte Dienste testen.
• Site-to-Site VPN, Remote Access VPN und Sophos Connect Profile prüfen.
• SD-WAN-Routen, statische Routen und Route Precedence kontrollieren.
• Firewall Rules mit Logging testen.
• IPS, Web Protection, TLS Inspection und Application Control stichprobenartig prüfen.
• RED- und Access-Point-Verbindungen kontrollieren.
• Syslog, Central Firewall Reporting, Benachrichtigungen und Monitoring testen.
• Alte XG erst nach stabiler Betriebsphase ausser Betrieb nehmen.

Wenn direkt nach der Migration einzelne Ziele nicht erreichbar sind, sollte man systematisch mit Log Viewer, Packet Capture und Routing-Checks arbeiten. Für die Grunddiagnose helfen Sophos Firewall Packet Capture im WebAdmin verwenden und Sophos Firewall Route Precedence sicher ändern.

FAQ