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. Sophos XG-Hardware ist seit dem 31. März 2025 End of Life. 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 Reporting oder Remote-Standorte zu übersehen?

Kurzantwort

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

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.
• Sicherheitsupdates, Hotfixes und Hersteller-Support sind eingeschränkt oder nicht mehr verfügbar.
• 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 mit dedizierten Beschleunigungsfunktionen. Dadurch gibt es mehr Reserven für aktuelle Sicherheitsfunktionen, VPN, TLS Inspection, IPS, Web Protection und Routing.
• Migration und Betrieb: Der Wechsel auf XGS ist ein Migrationsprojekt. Backup-Kompatibilität, Port-Mapping, Lizenzstand, HA, SD-WAN, Central 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 nicht nur ein Marketingbegriff, sondern vor allem bei aktivierten Schutzfunktionen relevant. Viele ältere XG-Installationen wurden ursprünglich dimensioniert, als weniger TLS Inspection, weniger Cloud-Traffic, weniger SD-WAN und weniger Remote Access Last vorhanden war.

Eine XGS 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 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 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, Sophos Central Management 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?

Backup-Restore Assistant und Port-Mapping

Das Migration Center für XG-zu-XGS-Migrationen ist für Port-Mapping und Backup-Restore Assistant der wichtigste externe Bezugspunkt. Das ist wichtig, weil Portnamen, Portanzahl, Flexi-Port-Module, Wireless-Modelle und Zielmodelle nicht immer 1:1 passen.

In der Praxis sollte man vor dem Restore eine Port-Tabelle vorbereiten:

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-Geräte ersetzt. Man muss HA bewusst neu planen: Modellgleichheit, Firmwarestand, Lizenzen, HA-Port, Monitoring, Passphrase, Rollenwechsel und Testfenster. Die Details gehören in die HA-Planung, etwa mit Sophos Firewall High Availability einrichten.

Central, Reporting, SD-WAN und ZTNA nachziehen

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

• die neue Firewall in Sophos Central registrieren,
• Firewall Management und Central Reporting prüfen,
• Central Firewall Reporting Lizenz und Datenzuordnung kontrollieren,
• SD-WAN Connection Groups neu zuordnen,
• ZTNA-Gateways auf die neue Firewall umstellen,
• RED- und Access-Point-Zuordnung testen,
• 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 Central. 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 dokumentiert.
• Aktuelles Backup erstellt und Restore-Passwort sicher abgelegt.
• Secure Storage Master Key bekannt und dokumentiert.
• Port-Mapping für WAN, LAN, DMZ, VLAN-Trunks und HA vorbereitet.
• Lizenztransfer, Central-Registrierung und Supportstatus geprüft.
• VPNs, NAT, WAF, SD-WAN, DHCP, DNS und Routing als Testliste vorbereitet.
• RED, Access Points, ZTNA, Central Reporting und Monitoring berücksichtigt.
• Rollback-Plan mit altem Gerät, Kabelplan und Wartungsfenster definiert.
• Ansprechpartner für Provider, DNS, Monitoring und Applikationen erreichbar.

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, Central-Registrierung 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 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