Controleer Sophos Firewall vóór SFOS 22-upgrade

SFOS 22 brengt belangrijke architectuurwijzigingen naar de Sophos Firewall. Voor beheerders is het daarom niet alleen interessant welke nieuwe functies na de update beschikbaar zijn. Belangrijker is eerst de vraag of de eigen firewall probleemloos naar SFOS 22 kan worden bijgewerkt.

Deze handleiding dient als pre-upgrade-check. Het artikel vervangt niet de algemene handleiding voor de Sophos Firewall Firmware Update, maar vult deze aan met de punten die bij SFOS 22 bijzonder snel tot problemen kunnen leiden: ondersteund platform, interface-namen, opslagruimte, back-up, HA-status, Legacy Remote Access IPsec, policy-based IPsec, NAT en rollback-plan.

Videohandleiding

Wanneer deze check zinvol is

De check moet worden uitgevoerd vóór elke geplande upgrade naar SFOS 22 of hoger. Het is vooral belangrijk als een van de volgende situaties van toepassing is:

• de firewall draait nog op XG- of SG-hardware
• het apparaat is al over meerdere grote releases bijgewerkt
• er zijn veel VLAN’s, aliassen, bridges, LAG’s, RED- of XFRM-interfaces
• het betreft een kleine desktop-appliance, virtuele firewall of software-appliance
• de firewall draait in een HA-cluster
• Remote Access IPsec VPN wordt of werd in het verleden gebruikt
• policy-based Site-to-Site IPsec, speciale SNAT-regels of VPN-NAT-regels zijn in gebruik
• STAS of andere gebruikersgebaseerde authenticatie stuurt productieve firewallregels aan
• de firewall wordt beheerd via Sophos Central of moet daarover worden bijgewerkt

Als de firewall al in het dagelijks gebruik instabiel is, diensten regelmatig opnieuw moeten worden gestart of partities sterk gevuld zijn, moet de upgrade niet als reparatiepoging worden gezien. In dit geval eerst de huidige toestand stabiliseren en de oorzaak achterhalen.

1. Controleer platform en upgradepad

SFOS 22.0 en nieuwere versies ondersteunen geen XG- en SG-hardware-appliances meer. Wie nog dergelijke apparaten gebruikt, moet eerst de migratie naar XGS, virtuele firewall, software-appliance of cloudimplementatie plannen. Voor de beslissing tussen oude en nieuwe hardwaregeneraties helpt het artikel Wat is het verschil tussen een XG en XGS Firewall?.

Op ondersteunde platforms moet daarnaast worden gecontroleerd vanaf welke versie wordt bijgewerkt. De SFOS 22 Release Notes tonen welke versies direct naar SFOS 22 kunnen worden gemigreerd. Als een niet-ondersteund pad wordt gekozen, kan de firewall na bevestiging met fabrieksconfiguratie starten. Precies dit risico moet vóór een onderhoudsvenster worden uitgesloten.

Praktische stappen:

1. Noteer de huidige firmwareversie onder Backup & Firmware > Firmware.
2. Documenteer model, serienummer en platformtype.
3. Controleer in de officiële Sophos Release Notes of het directe upgradepad wordt ondersteund.
4. Behandel bij XG- of SG-hardware geen SFOS-22-planning meer als normale update, maar als migratieproject.

2. Controleer interface-namen vóór de upgrade

Een gemakkelijk over het hoofd te zien upgradepunt betreft de namen van interfaces. Fysieke of logische interfaces kunnen in de WebAdmin-weergave onder Network > Interfaces niet zichtbaar of niet uitklapbaar zijn als een interface-naam, hardware-naam of branch-naam eindigt met tien of meer cijfers.

Dit is ongemakkelijk, omdat het verkeer verder kan worden verwerkt, maar de administratie in WebAdmin plotseling lijkt alsof interfaces ontbreken. Vooral bij migraties, geautomatiseerde naamgevingsschema’s, geïmporteerde configuraties of VLAN-namen met locatie-, klant- of inventarisnummers moet men dit punt vóór de upgrade controleren.

Kritische voorbeelden:

Praktische stappen:

1. Open Network > Interfaces.
2. Controleer fysieke interfaces, VLAN’s, aliassen, bridges, LAG’s, RED-interfaces en XFRM-interfaces.
3. Zoek naar namen die eindigen met tien of meer cijfers.
4. Wijzig getroffen namen vóór de upgrade naar een kortere of duidelijk gescheiden schrijfwijze.
5. Controleer na de wijziging of firewallregels, NAT-regels, SD-WAN-routes, DHCP, VPN en documentatie nog begrijpelijk zijn.

Beter zijn namen waarbij cijfers niet als lange blok aan het einde staan. In plaats van VLAN_1234567890 is bijvoorbeeld VLAN-1234567890-Client of een vaknaam zoals Client-VLAN-100 leesbaarder en operationeel robuuster.

Als na een upgrade interfaces in de WebAdmin-weergave ontbreken, moet men niet meteen aannemen dat de netwerkconfiguratie verloren is. Controleer eerst of het gedrag overeenkomt met de interface-naamproblematiek, of verkeer nog steeds loopt en of de getroffen namen moeten worden aangepast. Voor de algemene interfaceplanning past Sophos Firewall Zonen en Interfaces configureren.

3. Controleer opslagruimte en firmware-waarschuwingen

SFOS 22 vereist extra opslagruimte voor nieuwe functies en architectuurwijzigingen. De meeste appliances voldoen aan de vereisten, maar sommige desktop-, virtuele en software-implementaties kunnen een handmatige controle of correctie nodig hebben. Als de firewall op de Control Center- of Firmware-pagina een melding over opslagvereisten toont, mag deze niet worden genegeerd.

Via SSH kan de vullingsgraad van de partities grof worden gecontroleerd:

df -kh

De uitvoer vervangt geen Sophos-compatibiliteitscontrole, maar helpt bij de inschatting of /, /var, /content of andere partities opvallend vol zijn. Als een partitie erg krap is, moet niet zomaar blind worden bijgewerkt. Eerst nagaan welke gegevens daar liggen, of logs of oude bestanden kunnen worden opgeschoond en of er een Sophos-waarschuwing voor het betreffende apparaat bestaat.

Belangrijk is ook de tijdsplanning: als de firewall tijdens de upgrade partities moet aanpassen, kan de update langer duren dan een normaal onderhoudsrelease. Het onderhoudsvenster moet daarom niet te krap worden gepland.

4. Back-up en herstel voorbereiden

Voor de upgrade is een verse back-up nodig. Dat klinkt banaal, maar is bij grote releases cruciaal. De back-up moet niet alleen worden gemaakt, maar ook vindbaar, ontsleutelbaar en aan een specifiek apparaat toewijsbaar zijn. Het artikel Sophos Firewall Back-up maken of herstellen legt de belangrijkste punten uit rond back-up, herstel en Secure Storage Master Key.

Voor SFOS 22 moeten ten minste deze punten zijn afgehandeld:

• maak een actuele configuratieback-up en sla deze extern op
• documenteer de Secure Storage Master Key als versleutelde back-ups worden gebruikt
• controleer lokale en onderhoudsnetwerktoegang voor de beheerder
• controleer licentiestatus en Sophos Central-toegang
• houd het huidige firmware-image en doel-firmware bij de hand
• definieer een rollback-beslissing: wanneer wordt gewacht, wanneer wordt teruggerold

Bij kritieke locaties moet ook duidelijk zijn wie ter plaatse toegang heeft tot het apparaat en hoe men indien nodig een herinstallatie zou uitvoeren. De herinstallatie is een andere procedure dan een normale firmware-update. Daarvoor is de aparte handleiding Sophos Firewall OS opnieuw installeren.

5. Go/No-Go vóór het onderhoudsvenster vaststellen

Een SFOS-22-upgrade moet niet pas tijdens het onderhoudsvenster worden beslist. Van tevoren moet duidelijk zijn onder welke voorwaarden wordt gestart, gewacht, afgebroken of teruggerold. Dit vermindert hectische beslissingen als de firewall langer nodig heeft, een HA-node niet synchroniseert of een kritieke dienst na de herstart niet werkt.

Zinvolle Go/No-Go-punten:

Voor verspreide locaties moet bovendien duidelijk zijn wie tijdens het onderhoudsvenster bereikbaar is: technische contactpersoon, locatiecontact, persoon met fysieke toegang en beslisser voor rollback. Als de upgrade op afstand wordt uitgevoerd, moet men bovendien controleren of er een alternatieve toegang is, voor het geval VPN, WAN of Central Management tijdelijk niet werkt.

Een terugvalplan is geen zwakte van de wijziging. Het voorkomt dat bij een storing tegelijkertijd firmware, routing, VPN, HA en switching worden gewijzigd. Als na de upgrade een kritieke dienst uitvalt, moet eerst het gedefinieerde validatieplan worden afgewerkt. Pas daarna wordt beslist of een rollback, een herstel, een herinstallatie of een gerichte probleemoplossing zinvoller is.

6. HA-cluster goed voorbereiden

Bij HA-clusters mag niet alleen de actieve firewall worden bekeken. Beide nodes moeten worden ondersteund, dezelfde zinvolle uitgangstoestand hebben en goed synchroniseren. Een upgrade op een al aangetast HA-cluster verhoogt het risico op onnodige uitval.

Vóór het onderhoudsvenster controleren:

• System services > High availability toont een gezonde HA-status.
• Beide apparaten zijn hetzelfde model of een ondersteunde HA-combinatie.
• Firmwarestatus, licentiestatus en abonnement zijn plausibel.
• HA-link, gemonitorde poorten en aangesloten switchpoorten zijn stabiel.
• Het is gedocumenteerd welk apparaat vóór de upgrade actief was.

Voor de algemene HA-planning en de bijzonderheden van Active-Passive, Active-Active, licentieverlening en onderhoud past het artikel Sophos Firewall HA-cluster varianten.

7. Zoek naar Legacy Remote Access IPsec

Vanaf SFOS 22.0 MR1 wordt Legacy Remote Access IPsec VPN niet meer ondersteund. Firewalls met deze legacy-configuratie kunnen niet worden bijgewerkt naar SFOS 22.0 MR1 of nieuwer. Dit is een typische upgrade-blokker, omdat Remote Access IPsec in oudere omgevingen vaak eenmaal is ingesteld en daarna lange tijd niet meer is aangeraakt.

Vóór de upgrade moet men daarom controleren of er oude Remote-Access-IPsec-configuraties aanwezig zijn. Zo ja, dan moet eerst worden gemigreerd naar de huidige Remote-Access-IPsec-configuratie, SSL VPN, ZTNA of een ander passend Remote-Access-ontwerp. De concrete procedure staat in Legacy Remote Access IPsec vóór SFOS 22 MR1 migreren. Voor algemeen IPsec-probleemoplossing helpt daarnaast Sophos Firewall IPsec VPN Troubleshooting.

Praktische stappen:

1. Open in WebAdmin het gedeelte Remote access VPN.
2. Controleer of er een Legacy-Remote-Access-IPsec-configuratie aanwezig is.
3. Documenteer getroffen gebruikers, profielen, pools, authenticatie en verspreide Sophos-Connect-configuraties.
4. Plan een vervangende configuratie en test deze met enkele testgebruikers.
5. Verwijder pas na succesvolle migratie de legacy-configuratie en controleer de firmware-upgrade opnieuw.

Als Sophos Connect wordt gebruikt, moeten ook de bestaande handleidingen voor de Sophos Connect Firewall-configuratie, de Windows-installatie en de macOS-installatie worden meegenomen.

8. Controleer policy-based IPsec en NAT

SFOS 22.0 GA en nieuwere versies veranderen het gedrag van policy-based Site-to-Site IPsec VPN. Daarnaast is in de SFOS-22-release-opmerkingen een opgelost probleem gedocumenteerd waarbij policy-based IPsec-verkeer kon mislukken als de standaard-SNAT-regel was geconfigureerd met een statisch IP-adres in plaats van MASQ.

Dit is geen reden om elke IPsec-setup vooraf om te bouwen. Het is echter een goede reden om policy-based IPsec vóór en na de upgrade bewust te testen. Dit is vooral belangrijk als de firewall meerdere VPN’s, overlappende netwerken, specifieke SNAT-regels, een aangepaste standaard-SNAT-regel of partnernetwerken met vaste bron-IP-verwachtingen gebruikt.

Vóór de upgrade controleren:

1. Identificeer policy-based Site-to-Site-tunnels.
2. Documenteer lokale en externe netwerken of Traffic Selectors.
3. Controleer NAT-regels voor VPN-verkeer, vooral standaard-SNAT, MASQ, specifieke SNAT-regels en regelvolgorde.
4. Definieer per belangrijke tunnel een testgeval met bron, bestemming, service en verwachte richting.
5. Documenteer tegenpartij en retourweg, zodat een post-upgrade-test niet alleen “Ping werkt niet” betekent.

Na de upgrade moet men deze tests niet vermengen met brede verzamelchecks. Beter is een gerichte test per tunnel: Log Viewer, Packet Capture, Firewall Rule ID, NAT Rule ID en byte-teller in ipsec statusall vergelijken. Als de tunnel groen is, maar geen gebruiksverkeer stroomt, past Sophos Firewall IPsec VPN Troubleshooting. Voor de NAT-inzicht helpt NAT op Sophos Firewall begrijpen.

9. Controleer STAS en gebruikersgebaseerde regels

Als STAS actief is, moet het vóór SFOS 22.0 MR1 of nieuwer niet alleen als “werkt in het dagelijks leven” worden afgevinkt. In de lijst met bekende problemen is een probleem gedocumenteerd waarbij de optie Restrict client traffic during identity probe een upgrade naar SFOS 22.0 MR1 kan blokkeren of na de upgrade kan leiden tot herhaalde Identity Probes met kortstondige verkeersonderbrekingen.

Dit betreft vooral omgevingen waarin STAS niet alleen voor rapportage, maar voor productieve gebruikersgebaseerde firewallregels wordt gebruikt. Als de gebruikers-IP-toewijzing kort uitvalt, lijkt dit in de praktijk snel op een regel-, DNS- of applicatieprobleem.

Vóór de upgrade controleren:

1. Open Authentication > STAS.
2. Controleer STAS-status en gebruikte collectors.
3. Controleer of Restrict client traffic during identity probe actief is.
4. Identificeer gebruikersgebaseerde regels die afhankelijk zijn van STAS.
5. Meld een testgebruiker aan en controleer Live Users en Log Viewer.

Als deze optie actief is of al korte onderbrekingen opvallen, moet dit punt vóór het onderhoudsvenster worden opgehelderd. De gedetailleerde procedure staat in STAS op Sophos Firewall instellen.

10. Na de upgrade gericht valideren

Na de herstart is de upgrade niet automatisch voltooid. Pas als de belangrijkste bedrijfsfuncties zijn gecontroleerd, is het onderhoudsvenster netjes afgesloten.

Minimaal controleren:

• juiste firmwareversie is actief
• Network > Interfaces toont fysieke en logische interfaces plausibel aan
• internettoegang en centrale firewallregels werken
• Site-to-Site VPN en Remote Access VPN werken
• policy-based IPsec-tests tonen de verwachte bron-IP en passende NAT-regel
• HA-status is weer gesynchroniseerd
• STAS, AD SSO of andere gebruikerskoppeling werkt, indien productief gebruikt
• Sophos Central Management en Reporting verzenden gegevens
• Log Viewer toont geen nieuwe kritieke fouten
• belangrijke diensten zoals DNS, DHCP, Web Protection, IPS en authenticatie werken zoals verwacht

Als VPN, routing of regels niet zoals verwacht werken, niet meteen op meerdere plaatsen tegelijk wijzigen. Eerst met Log Viewer, Policy Test, Packet Capture en de betrokken service-logs afbakenen. Voor gestructureerde probleemoplossing zijn Firewall-regel testen met Log Viewer, Policy Test en Packet Capture en Sophos Firewall Troubleshooting: Services en Logs nuttige aanvullingen.

11. Bewijs en bedrijfsdocumentatie veiligstellen

Een upgrade is pas netjes afgerond als het resultaat navolgbaar is gedocumenteerd. Dit helpt bij latere storingen, audits, supportgevallen en bij het volgende onderhoudsvenster. Direct na de upgrade moet men daarom niet alleen “werkt weer” noteren, maar concrete bewijzen veiligstellen.

Zinvolle bewijzen:

Als wijzigingen aan regels, interfaces, hosts of services zijn aangebracht, moet men bovendien de Audit Trail Logs controleren. Bij omgevingen met langere logbewaring hoort ook een controle van Central Firewall Reporting of Syslog bij de afsluiting.

Bij meerdere firewalls is het bovendien belangrijk dat back-ups eenduidig kunnen worden toegewezen. In nieuwere SFOS-versies bevatten back-up-e-mails meer identificatiegegevens zoals hostnaam, firmwareversie, serienummer en model. Toch moet men intern nog steeds een eenvoudige upgrade-notitie bijhouden: firewall, locatie, oude versie, nieuwe versie, tijdvenster, verantwoordelijke persoon, testresultaat en openstaande punten.

Als na de upgrade opslag-, hardware- of SSD-waarschuwingen opvallen, moet dit niet in het firmware-ticket ondergaan. Voor deze controle past SSD-gezondheidstoestand op Sophos Firewall controleren.

Checklist voor het onderhoudsvenster

Vóór de upgrade

• Platform en upgradepad gecontroleerd
• Release Notes en bekende waarschuwingen gelezen
• Interface-namen met tien of meer afsluitende cijfers uitgesloten
• Opslagruimte en firmware-waarschuwingen gecontroleerd
• Back-up gemaakt en extern opgeslagen
• Secure Storage Master Key beschikbaar
• Go/No-Go-beslissing, terugvalroute en verantwoordelijken vastgesteld
• HA-status gedocumenteerd
• Policy-based IPsec, VPN-NAT en testverkeer gedocumenteerd, indien gebruikt
• STAS en gebruikersgebaseerde regels gecontroleerd, indien gebruikt
• Legacy Remote Access IPsec uitgesloten of gemigreerd
• Rollback-plan gedefinieerd

Tijdens de upgrade

• Statusmeldingen gedocumenteerd
• Geen parallelle wijzigingen aan routing, VPN of switching uitvoeren
• Bij HA-clusters failover en synchronisatie observeren
• Beslissingspunt voor wachten, foutenanalyse of rollback naleven
• Bij onverwachte meldingen niet blind bevestigen, maar oorzaak onderzoeken

Na de upgrade

• Firmwareversie en licentiestatus controleren
• VPN, routing, DNS, DHCP en centrale firewallregels testen
• Policy-based IPsec met gedefinieerde bron-/bestemmingstest controleren, indien gebruikt
• STAS, AD SSO en gebruikersgebaseerde regels met testgebruiker controleren
• HA-synchronisatie en Sophos Central-verbinding controleren
• Log Viewer en relevante service-logs controleren
• Firmware-, HA- en auditbewijzen veiligstellen
• Resultaat en openstaande punten in het bedrijfsjournaal documenteren

FAQ