Sophos Firewall SFOS 22-upgradecheck: blokkers vinden

Vóór een upgrade naar SFOS 22 moet duidelijk zijn of het platform, het upgradepad en de configuratie de doelrelease ondersteunen. Deze controle houdt rekening met SFOS 22.0 MR2 Build 546 van 14 juli 2026 en vormt een aanvulling op de algemene handleiding voor een Sophos Firewall-firmware-update.

Harde blokkers voor upgrade en herstel

• XG- of SG-hardware: SFOS 22 wordt niet ondersteund. In plaats van een upgrade is migratie naar XGS of naar een virtueel, software- of cloudplatform vereist.
• Legacy Remote Access IPsec: Vanaf SFOS 22.0 MR1 moet de configuratie vóór de upgrade worden gemigreerd of verwijderd.
• Legacy CLI VLAN Tagging op een bridge-interface: Vanaf SFOS 22.0 MR2 moet system vlan-tag worden vervangen door ondersteunde VLAN-interfaces.
• Back-up met Legacy VLAN Tagging: Voor herstel naar SFOS 22.0 GA of nieuwer moet de bronconfiguratie worden opgeschoond en een nieuwe back-up worden gemaakt.
• Opslag of upgradepad: Als de firmwarepagina onvoldoende opslagruimte of een ongeldig upgradepad meldt, moet eerst de oorzaak worden verholpen.

Als een blokker van toepassing is of een punt onduidelijk blijft, mag de upgrade niet worden gestart.

Direct upgradepad naar SFOS 22.0 MR2

Voor de hier behandelde doelversie SFOS 22.0 MR2 Build 546 ondersteunt Sophos een directe upgrade vanuit de volgende versies:

• SFOS 22.0: MR1 Build 490 en GA Build 411 of 365
• SFOS 21.5: MR2 Build 323, MR1 Build 261 of GA Build 171
• SFOS 21.0: MR2 Build 349, MR1 Build 277, 272 of 237 en GA Build 169
• Oudere versies: elke SFOS 20.0-, 19.5- of 19.0-versie

⚠️ Staat de huidige versie niet in deze lijst, dan mag de waarschuwing voor een niet-ondersteunde migratie niet worden bevestigd. De firewall wordt anders opnieuw opgestart met fabrieksinstellingen en de huidige configuratie gaat verloren. Een back-up kan eveneens alleen worden hersteld vanuit een versie waarvan de configuratiemigratie wordt ondersteund.

Voor een oudere of niet-vermelde versie moet eerst een ondersteund tussenpad worden gepland. De versielijst vervangt bovendien geen van de overige controles: platform, opslag, verouderde afhankelijkheden en herstelplan moeten eveneens kloppen.

Controleren vóór het onderhoudsvenster

Platform en verouderde afhankelijkheden

• Het model en de huidige firmware worden gedocumenteerd, zodat het hierboven vermelde upgradepad en een eventueel herstel traceerbaar blijven.
• XG- en SG-hardware worden als een migratie behandeld, niet als een normale upgrade.
• UTM9 SSL VPN-tunnels en RED 15, RED 15w en RED 50 worden vóór de upgrade vervangen.
• Onder Network > Interfaces worden namen gecorrigeerd die eindigen op tien of meer cijfers. Dergelijke namen kunnen interfaces na de upgrade in WebAdmin verbergen.

Opslag, back-up en toegang

De bezetting van partities kan globaal worden gecontroleerd in de Advanced Shell:

df -kh

Bij een waarschuwing op de firmwarepagina mag de upgrade nog niet worden gestart. De referentiecode geeft de oorzaak en de volgende stap aan:

• FWDS501: de Primary Disk of een van de systeempartities is te klein voor SFOS 22. Bij een VM die vóór SFOS 18 is geïmplementeerd, kan dezelfde oude situatie tijdens een upgrade naar SFOS 21.5 of nieuwer aanvankelijk alleen als een algemene firmwarefout verschijnen (NC-151465); de melding alleen bewijst de schijffout echter niet. Voor een virtuele firewall laat Primary Disk vóór SFOS 22 vergroten zien hoe Hard disk 1 wordt gecontroleerd en vergroot en hoe het resultaat daarna wordt geverifieerd. Hetzelfde artikel bevat de juiste grenswaarden en oplossingen voor een Software Appliance.
• FWDS502: in /var is onvoldoende vrije ruimte. In 4. Device Console toont system firmware check-disk-space de benodigde ruimte en de betrokken datagebieden. Reports of logs mogen pas gecontroleerd worden opgeschoond nadat benodigde gegevens zijn veiliggesteld; de procedure staat in Opslagruimte controleren en reports beheren.
• FWDS503: de /content-partitie is te klein. Sophos vereist een fabrieksreset met uitval en verlies van de huidige configuratie. Eerst worden een recente back-up en de SSMK veiliggesteld. Daarna wordt via de seriële console RESET in hoofdletters ingevoerd en optie 2 gekozen; hiermee worden de eigen configuraties verwijderd en de pattern-signatures teruggezet naar de stand van de actieve firmware. Vervolgens worden de back-up hersteld en de functies gecontroleerd; pas daarna wordt de update uitgevoerd. Lokale reports worden niet hersteld.
• FWDS504: de SSD-firmware is verouderd en moet vóór de SFOS-upgrade worden bijgewerkt.
• FWDS505: Sophos Support moet de SSD-gezondheid controleren. Een lokale SMART-check kan waarden voor Support documenteren, maar heft de blokkering niet op.

In een HA-cluster moet elke node afzonderlijk worden gecontroleerd, omdat beide appliances verschillende referentiecodes kunnen tonen.

Vóór de start moeten bovendien de volgende zaken beschikbaar zijn:

• een recente, extern opgeslagen back-up en de bijbehorende Secure Storage Master Key
• lokale beheerderstoegang of alternatieve toegang buiten het normale VPN-pad
• een gedefinieerd terugvalpad met een verantwoordelijke en beslismoment
• bij HA een gezond, synchroon cluster met stabiele HA-links en Monitored Ports

Details over back-up en herstel staan in Een Sophos Firewall-back-up maken of herstellen.

Configuraties met een bijzonder risico

Legacy Remote Access IPsec

Vanaf SFOS 22.0 MR1 blokkeert een bestaande Legacy Remote Access IPsec-configuratie de upgrade. Betrokken gebruikers, pools en profielen moeten eerst worden gemigreerd naar de huidige Remote Access IPsec-configuratie, SSL VPN, ZTNA of een ander passend ontwerp. De procedure staat in Legacy Remote Access IPsec vóór SFOS 22 MR1 migreren.

Microsoft Entra ID SSO met Same as firewall

SFOS 22.0 of nieuwer schakelt Microsoft Entra ID SSO voor VPN Portal, Remote Access IPsec en SSL VPN automatisch in wanneer hun authenticatiemethode vóór de upgrade op Same as firewall staat. Leg daarom vóór het onderhoudsvenster de instellingen onder Authentication > Services en de werkelijk verwachte Identity Provider vast.

Controleer na de upgrade elke effectieve methode afzonderlijk. Als Entra SSO bedoeld is, moet de exacte VPN portal and remote access URL uit het Entra-serverobject als Redirect URI in de Entra-app staan; de Sophos Central reverse SSO-URL is hiervoor onjuist. Een echte pilotaanmelding controleert portal, client en MFA. Als SSO niet bedoeld is, wordt de gewenste methode expliciet ingesteld. De volledige procedure staat in Microsoft Entra ID SSO voor Sophos Firewall VPN instellen.

Policy-based IPsec en NAT

Productieve policy-based Site-to-Site-tunnels moeten vóór en na de upgrade met een concrete testflow worden gecontroleerd. Daaronder vallen Source, Destination, Service, Traffic Selectors, de peer en de verwachte firewall- en NAT-regel. Bij problemen helpen IPsec VPN-troubleshooting en NAT op Sophos Firewall begrijpen.

Vóór de upgrade moet bovendien worden nagegaan of OSPF of BGP externe policy-based VPN-netwerken tot nu toe via redistribute kernel aankondigde. Vanaf SFOS 22 zijn deze netwerken niet meer als gewone kernelroutes beschikbaar; SFOS 22: IPsec-routes en redistribute kernel toont welke prefixen vóór en na de upgrade moeten worden gecontroleerd en waarom een route-based XFRM-ontwerp beter geschikt is voor dynamische routing.

SMTP via DNAT

Als een interne mailserver via DNAT wordt gepubliceerd, moet het onderhoudsplan meerdere echte inkomende testberichten bevatten en niet alleen een poorttest. Sophos vermeldt onder NC-184583 sporadisch verbroken SMTP-verbindingen na een upgrade naar SFOS 22.x; GA Respin Build 411 wordt expliciet als getroffen versie genoemd en er is geen openbare workaround. De exacte versieafbakening, bewijsverzameling en supportescalatie staan in Server publiceren via DNAT op Sophos Firewall.

Let’s Encrypt en MR2-migratierollback

MR2 Build 546 ondersteunt de nieuwe Let’s Encrypt-CA’s YE Root, YE1, YE2, YR Root, YR1 en YR2. Los daarvan mislukte bij twee publiek gedocumenteerde upgrades van MR1 Build 490 naar MR2 Build 546 de configuratiemigratie in verband met een Let’s Encrypt-certificaat dat in gebruik was. De firewall keerde automatisch terug naar MR1. Na een controle via Support Access bevestigde Sophos een bekende migratieblokkade voor certificaten uit een bepaalde, maar niet publiek afgebakende uitgifteperiode. Op 9 augustus 2026 ontbreken nog steeds een openbare Issue ID, een betrouwbare voorafgaande test en een bevestigde fixversie.

Vóór de upgrade van een MR1-firewall met een onlangs uitgegeven of vernieuwd Let’s Encrypt-certificaat moeten de Issuer en de servicetoewijzing onder Certificates > Certificates worden gedocumenteerd. Een YE/YR-Issuer of alleen de aanwezigheid van deze CA’s onder Certificate authorities bewijst de migratiefout niet en is op zichzelf geen algemene upgradeblokkade. Bij een kritieke firewall is het desondanks verstandig om het geval vooraf met Sophos Support af te stemmen of de upgrade uit te stellen zolang geen openbare voorafgaande test of fix is bevestigd. Certificaten en CA’s mogen niet op basis van een vermoeden worden verwijderd of hernoemd: een in de Community gedocumenteerde verwijderingspoging verhielp de fout niet betrouwbaar, en het certificaat kan WAF, WebAdmin, portals, Hotspot of SMTP TLS beveiligen. Certificaten op Sophos Firewall beheren legt uit hoe toewijzingen worden gecontroleerd en een veilige vervanging met een terugvalpad wordt voorbereid.

Deze migratierollback is niet dezelfde fout als een onvolledig geleverde certificaatketen na de vernieuwing. Let’s Encrypt-certificaten op Sophos Firewall beschrijft de controle van dit tweede foutbeeld en de daarvoor uitgerolde hotfix.

Na een automatische rollback past het foutbeeld bij het bekende probleem als dbv22.004 en tblvpncertificate_caid_fkey in migration.log verschijnen en de omringende verwijderingsinstructie YE/YR-objecten noemt. Deze zoektermen helpen de relevante regels te vinden:

dbv22.004
tblvpncertificate_caid_fkey
Lets_Encrypt_YE
Lets_Encrypt_YR

Als ze verschijnen, moeten migration.log, migrationhash.log, de firmwaremelding, het tijdstip en de bron- en doelbuilds worden opgeslagen en mag dezelfde upgradepoging niet ongewijzigd worden herhaald. Controleer daarna de bronfirmware, HA, WAN, routing, VPN, de Central-verbinding en alle certificaatafhankelijke services. Sophos Firewall-logs voor support opslaan beschrijft de juiste procedure voor bewijsverzameling; met deze gegevens kan Sophos Support de migratiefout afbakenen.

Legacy VLAN Tagging op bridges

Legacy CLI VLAN Tagging op bridge-interfaces heeft drie gevolgen:

• Onder GA en MR1 kan verkeer van of naar de firewall uitvallen, terwijl transitverkeer blijft werken.
• Vanaf MR2 wordt de upgrade geblokkeerd.
• Een getroffen back-up kan niet worden hersteld naar SFOS 22.0 GA of nieuwer.

Vóór het opschonen moeten de bridge, VLAN IDs, IP-adressen, zones, switchtrunks en afhankelijke services worden gedocumenteerd. Daarna worden ondersteunde VLAN-interfaces met de bridge als Parent gemaakt en wordt een nieuwe back-up gegenereerd. Dit bijzondere geval wordt beschreven in Sophos Firewall bridge-VLAN’s vóór SFOS 22 controleren.

STAS

Voor een upgrade naar MR1 moet onder Authentication > STAS de optie Restrict client traffic during identity probe op No staan. MR2 verhelpt de MR1-fout en gebruikt voor nieuwe configuraties standaard No; bestaande waarden en gebruikersgebaseerde regels moeten toch worden gecontroleerd. Meer informatie staat in STAS op Sophos Firewall configureren.

Malware-scan bij de upgrade naar GA Build 411

Alleen bij een gerichte upgrade naar SFOS 22.0 GA Respin Build 411 kan NC-177529 tijdens de migratie tijdelijk Malware Unscannable melden, vaak voor www.msftconnecttest.com, omdat de nieuwe Sophos-scanengine nog niet beschikbaar is. Schakel vóór deze GA-upgrade onder Web > General settings over van Single engine naar Dual engine en stel na de voltooide upgrade de eerder gebruikte Single Engine weer in. Deze maatregel geldt niet algemeen voor MR1, MR2 of latere releases; de achtergrond en de keuze van de scan-engine worden uitgelegd in Sophos Firewall Malware-Scanning configureren en testen.

Onderhoudsvenster en controle

• Vooraf: Blokkers uitsluiten, back-up en SSMK beschikbaar stellen, de HA-synchronisatie controleren en VPN-, test- en terugvalpaden documenteren.
• Tijdens: Geen parallelle wijzigingen aan routing, VPN of switching uitvoeren; de status en HA-failover controleren.
• Achteraf: Firmware, interfaces, internet, firewallregels, VPN, NAT, HA, STAS, DNS, DHCP, Central en Log Viewer controleren.

Een groene tunnel of een geslaagde Policy Test bewijst nog niet dat productieverkeer werkt. Kritieke verbindingen moeten daarom worden getest met echte pakketten, Log Viewer, Packet Capture en de Firewall en NAT Rule ID. Bij problemen mogen niet meerdere gebieden tegelijk worden gewijzigd.

De upgrade is voltooid wanneer de gedefinieerde tests zijn geslaagd en de doelversie, HA-status, testresultaten en openstaande vervolgwerkzaamheden zijn gedocumenteerd.

FAQ