Naar de inhoud
Avanet

Sophos XG vs. XGS: verschillen, EOL en migratie

De XGS-serie is sinds 2021 de opvolger van de XG-serie. De oorspronkelijke vergelijking tussen oude en nieuwe hardware is vandaag echter niet meer alleen een prestatievraag. Sophos XG-hardware is sinds 31 maart 2025 End of Life. Bovendien ondersteunen SFOS 21.0 en latere firmwarelijnen geen XG- en SG-Series-hardware meer.

Daarmee is de eigenlijke vraag niet meer Is XGS de moeite waard?, maar Hoe plant men de overstap van XG netjes, zonder routing, VPN, Central Reporting of externe locaties over het hoofd te zien?

Kort antwoord

XG en XGS draaien allebei op Sophos Firewall OS, maar zijn niet langer gelijkwaardige platformen.

  • Lifecycle: End of Life. actief ondersteund hardwareplatform.
  • Firmware: geen ondersteuning voor SFOS 21.0/21.5/22.0. actuele SFOS-versies.
  • Prestaties: ouder platform, minder reserve voor moderne Inspection. Xstream-architectuur met meer reserve.
  • Beheer: migratierisico en supportgrens. standaardplatform voor nieuwe projecten.
  • Planning: vervanging nodig. sizing, port-mapping en licentieoverdracht netjes plannen.

Een XG moet daarom niet meer als normaal firewallmodel worden gezien, maar als oud platform dat moet worden vervangen. Voor licentie- en lifecycle-vragen past aanvullend de Sophos Product Lifecycle Kalender.

Wat End of Life in firewallbeheer betekent

End of Life is bij firewallhardware geen formele vermelding in een tabel. Een firewall staat aan de netwerkrand, termineert VPN’s, filtert web- en applicatieverkeer, beschermt gepubliceerde diensten en bevat vaak gevoelige configuraties. Als dit platform niet meer wordt onderhouden, ontstaat een echt operationeel risico.

Voor een productieve XG zijn vooral deze punten kritisch:

  • Nieuwe SFOS-firmwarelijnen kunnen niet meer worden gebruikt.
  • Security updates, Hotfixes en fabrikantensupport zijn beperkt of niet meer beschikbaar.
  • Nieuwe functies zoals actuele VPN-, logging-, Health Check- of beveiligingsfeatures landen op ondersteunde platformen.
  • Licenties, RMA, vervangende apparaten en supportcases worden moeilijker planbaar.
  • Audits en cyberverzekeringen kunnen de verdere werking van een EOL-firewall kritisch beoordelen.

Bijzonder kritisch is dit bij firewalls met actief Remote Access VPN, Site-to-Site VPN, WAF, TLS Inspection, Web Protection, gepubliceerde servers of breed bereikbaar WebAdmin. In zulke omgevingen moet het verder gebruiken van een XG alleen nog als tijdelijke overgangsoplossing met gedocumenteerd migratieplan gelden.

De drie belangrijkste verschillen

XG en XGS lijken afhankelijk van het model aan de buitenkant op elkaar, maar verschillen technisch en operationeel duidelijk.

  • Lifecycle en Firmware: XG-hardware is End of Life. SFOS 21.0, 21.5 en 22.0 ondersteunen XG- en SG-Series-hardware niet meer. XGS is het ondersteunde hardwareplatform voor actuele SFOS-versies.
  • Architectuur en prestaties: XGS gebruikt de Xstream-architectuur met dedicated versnellingsfuncties. Daardoor is er meer reserve voor actuele beveiligingsfuncties, VPN, TLS Inspection, IPS, Web Protection en routing.
  • Migratie en beheer: De overstap naar XGS is een migratieproject. Backup-compatibiliteit, Port-Mapping, licentiestatus, HA, SD-WAN, Central Reporting, RED, Access Points en ZTNA Gateways moeten worden gecontroleerd.
Belangrijkste vernieuwingen van de XGS-hardwareserie

Architectuur: Xstream in plaats van het oude XG-platform

De XGS-serie is gebouwd voor de Xstream-architectuur. In het dagelijks beheer is dat niet alleen een marketingterm, maar vooral relevant wanneer beveiligingsfuncties actief zijn. Veel oudere XG-installaties werden oorspronkelijk gedimensioneerd toen er minder TLS Inspection, minder cloudtraffic, minder SD-WAN en minder Remote Access-belasting was.

Een XGS biedt afhankelijk van het model meer reserve voor:

  • IPS, Web Protection en Application Control.
  • TLS Inspection en grotere certificaat-/CA-rollouts.
  • IPsec VPN, SSL VPN, SD-WAN en meerdere WAN-uplinks.
  • Meer gelijktijdige gebruikers, sessies en regels.
  • Nieuwe SFOS-functies die op XG helemaal niet meer beschikbaar zijn.

Niet ieder datapad wordt automatisch sneller alleen omdat er een XGS wordt geplaatst. Verkeerde sizing, te kleine modellen, slecht geplande TLS Inspection of onduidelijke VPN-architectuur kunnen ook een nieuwe firewall afremmen. Voor de keuze van het passende doelmodel is de Sophos Firewall Sizing Guide belangrijker dan een eenvoudige 1:1-modelvergelijking.

Wanneer een XG moet worden vervangen

Een XG-vervanging moet niet pas worden gepland wanneer een firmware-upgrade blokkeert of een hardwaredefect al druk veroorzaakt. Uiterlijk bij deze signalen is een migratieproject nodig:

  • De firewall moet naar SFOS 21.0, 21.5, 22.0 of nieuwer worden bijgewerkt.
  • Er is Remote Access VPN, WAF, publiek bereikbare diensten of meerdere Site-to-Site VPN’s.
  • Support, audit, RMA of licentieverlenging zijn niet meer netjes af te beelden.
  • De bestaande XG zit onder IPS, Web Protection, TLS Inspection of VPN-belasting aan de limiet.
  • RED, Access Points, SD-WAN, Central Reporting of ZTNA hangen aan de bestaande firewall.
  • Er staat toch al een HA-cluster, port-redesign of providerwissel op de planning.

Als een XG nog productief draait, moeten eerst een actuele back-up, de Secure Storage Master Key en de gebruikte firmwareversie worden gedocumenteerd. De werkwijze is in het artikel Sophos Firewall back-up maken of herstellen gedetailleerder beschreven.

Migratie van XG naar XGS plannen

Bij een migratie van XG naar XGS moet men niet alleen het ogenschijnlijk dichtstbijzijnde model kiezen. Zinvoller is een korte inventarisatie voor het onderhoudsvenster:

  • Welke WAN-, LAN- en DMZ-poorten worden effectief gebruikt?
  • Zijn er HA, VLAN-stacks, RED-, SD-WAN- of VPN-bijzonderheden?
  • Welke beveiligingsfuncties zijn vandaag actief en welke moeten in de toekomst aanvullend worden geactiveerd?
  • Welke IPsec-, SSL-VPN-, Sophos Connect- of ZTNA-scenario’s zijn productief?
  • Is er Central Firewall Reporting, Sophos Central Management of SD-WAN Connection Groups?
  • Zijn Access Points of SD-RED-apparaten aan deze firewall gekoppeld?
  • Zijn er statische routes, Alias IP Addresses, DNAT-regels of WAF-publicaties die na de wissel direct bereikbaar moeten zijn?
  • Moet het doelplatform opnieuw hardware zijn of een virtuele of Cloud Appliance?

Backup-Restore Assistant en Port-Mapping

Het Migration Center voor XG-naar-XGS-migraties is voor Port-Mapping en Backup-Restore Assistant het belangrijkste externe referentiepunt. Dat is belangrijk omdat poortnamen, poortaantal, Flexi-Port Modules, Wireless-modellen en doelmodellen niet altijd 1:1 passen.

In de praktijk moet men voor de restore een poorttabel voorbereiden:

  • Port1: Port1. LAN. VLANs, DHCP, DNS.
  • Port2: Port2. WAN. Gateway, Alias-IP, NAT.
  • Port3: Port4. DMZ. Firewall Rules, WAF, DNAT.
  • Flexi Port: nieuwe module. Uplink of Trunk. Modulecompatibiliteit.

Als het WAN-MAC-adres verandert, kunnen voorgeschakelde routers of Provider CPE’s nog oude ARP-vermeldingen vasthouden. Bij zulke symptomen helpt het artikel Sophos Firewall ARP-probleem na migratie oplossen.

HA apart behandelen

Een XG-HA-cluster wordt niet simpelweg door restore op twee nieuwe XGS-apparaten vervangen. HA moet bewust opnieuw worden gepland: modelgelijkheid, firmwarestand, licenties, HA-poort, monitoring, passphrase, rolwisseling en testvenster. De details horen in de HA-planning, bijvoorbeeld met Sophos Firewall High Availability instellen.

Central, Reporting, SD-WAN en ZTNA bijwerken

Na de restore is de nieuwe XGS niet automatisch in elke Sophos Central-functie gelijk ingebonden. Afhankelijk van de omgeving moet men:

  • de nieuwe firewall in Sophos Central registreren,
  • Firewall Management en Central Reporting controleren,
  • Central Firewall Reporting-licentie en datatoewijzing controleren,
  • SD-WAN Connection Groups opnieuw toewijzen,
  • ZTNA Gateways naar de nieuwe firewall omzetten,
  • RED- en Access Point-toewijzing testen,
  • meldingen, backups en geplande reports opnieuw controleren.

Voor Reporting-setups past aanvullend Central Firewall Reporting activeren. Voor operationeel bewijs na de migratie zijn Sophos Firewall-regel testen met Log Viewer en Packet Capture en Verworpen pakketten op Sophos Firewall analyseren nuttiger dan alleen een ping-test.

Prestatieverschillen tussen Sophos XG en XGS Appliance

Typische fouten bij XG-naar-XGS-migraties

Te klein doelmodel

Een ogenschijnlijk passend opvolgmodel kan te klein zijn wanneer sinds de oorspronkelijke XG-aanschaf meer gebruikers, meer VPN’s, meer TLS Inspection, meer Web Protection of meer bandbreedte zijn toegevoegd. Daarom moet men niet alleen XG-model met XGS-model vergelijken, maar reele belasting, actieve beveiligingsfuncties en groei meenemen.

Port-Mapping alleen grof gecontroleerd

Als LAN, WAN, DMZ, VLAN Trunks, HA Ports of provideraansluitingen anders worden aangesloten, is een succesvolle restore niet voldoende. Na de restore moeten Interface Zones, Gateways, SD-WAN Routes, NAT Rules, WAF Rules en Firewall Rules gericht worden gecontroleerd.

Oude firmware of oude backupstand

Een zeer oude back-upstand verhoogt het risico dat Interface Mapping, certificaten, VPN’s of speciale configuraties onverwacht migreren. Voor de wissel moet men de oude firewall, voor zover nog zinvol en ondersteund, naar een geschikte stand brengen en een nieuwe back-up maken.

Nageschakelde systemen vergeten

Veel migraties mislukken niet op de restore, maar op afhankelijke systemen: Monitoring, Syslog, SIEM, back-upmails, VPN-clients, Provider ARP, DNS, DHCP, RED, Access Points of Sophos Central. Deze punten horen in de checklist, niet in de foutanalyse na het omschakelen.

Checklist voor de wissel

  • Actuele firmware van de XG en doelfirmware van de XGS gedocumenteerd.
  • Actuele back-up gemaakt en restorewachtwoord veilig bewaard.
  • Secure Storage Master Key bekend en gedocumenteerd.
  • Port-Mapping voor WAN, LAN, DMZ, VLAN Trunks en HA voorbereid.
  • Licentieoverdracht, Central-registratie en supportstatus gecontroleerd.
  • VPN’s, NAT, WAF, SD-WAN, DHCP, DNS en routing als testlijst voorbereid.
  • RED, Access Points, ZTNA, Central Reporting en Monitoring meegenomen.
  • Rollback-plan met oud apparaat, kabelplan en onderhoudsvenster gedefinieerd.
  • Contactpersonen voor provider, DNS, Monitoring en applicaties bereikbaar.

Controle na de migratie

Na het omschakelen moet men niet alleen controleren of internet werkt. Een nette migratie is pas afgerond wanneer de belangrijkste beheerfuncties zijn gevalideerd:

  • Dashboard, licentiestatus, Central-registratie en back-upmail controleren.
  • WAN Gateway, Alias IP Addresses, NAT en gepubliceerde diensten testen.
  • Site-to-Site VPN, Remote Access VPN en Sophos Connect-profielen controleren.
  • SD-WAN Routes, statische routes en Route Precedence controleren.
  • Firewall Rules met logging testen.
  • IPS, Web Protection, TLS Inspection en Application Control steekproefsgewijs controleren.
  • RED- en Access Point-verbindingen controleren.
  • Syslog, Central Reporting, meldingen en Monitoring testen.
  • Oude XG pas na stabiele bedrijfsfase buiten gebruik nemen.

Als direct na de migratie afzonderlijke doelen niet bereikbaar zijn, moet systematisch met Log Viewer, Packet Capture en routingchecks worden gewerkt. Voor de basisdiagnose helpen Sophos Firewall Packet Capture in WebAdmin gebruiken en Sophos Firewall Route Precedence veilig wijzigen.

FAQ

Kan men een XG na End of Life blijven gebruiken?

Technisch kan een bestaande XG nog draaien. Operationeel is dat echter alleen als tijdelijke overgangsoplossing verdedigbaar, omdat actuele SFOS-versies, support, security updates en lifecycle-zekerheid ontbreken.

Kan men een XG-backup op een XGS herstellen?

Ja, in principe is een XG-naar-XGS-migratie via Backup-Restore voorzien. Doorslaggevend zijn firmwarestand, back-upversie, Port-Mapping, doelmodel en nageschakelde functies zoals HA, Central Reporting, RED, Access Points, SD-WAN en ZTNA.

Is XGS automatisch sneller dan XG?

Meestal biedt XGS duidelijk meer reserve, vooral met actuele beveiligingsfuncties. Toch moet het doelmodel passend worden gedimensioneerd. Een te kleine XGS, ongunstige TLS Inspection of slecht geplande VPN-architectuur kan nog steeds tot knelpunten leiden.

Moet men bij een XG-migratie ook de regels controleren?

Ja. Een restore vervangt geen regel- en NAT-controle. Na de migratie moet men Firewall Rules, NAT Rules, WAF-publicaties, logging, Route Precedence en Packet Capture gericht testen.