Sophos Firewall SFOS 22: kontrollera uppgraderingsblockerare

Före en uppgradering till SFOS 22 måste det vara klarlagt om plattform, uppgraderingsväg och konfiguration stöder målversionen. Denna kontroll kompletterar den tidigare statusen SFOS 22.0 MR2 Build 546 från den 14 juli 2026 med versionsinformationen för 22.0 MR3 Build 576 från den 16 oktober 2026 och används tillsammans med den allmänna guiden om Sophos Firewall Firmware Update.

Hårda blockerare för uppgradering och återställning

• XG- eller SG-hårdvara: SFOS 22 stöds inte. I stället för en uppgradering krävs en migrering till en XGS Appliance eller en virtuell, programvarubaserad eller molnbaserad plattform.
• Legacy Remote Access IPsec: Från och med SFOS 22.0 MR1 måste konfigurationen migreras eller tas bort före uppgraderingen.
• Legacy CLI VLAN Tagging på ett bridge-gränssnitt: Från och med SFOS 22.0 MR2 måste system vlan-tag ersättas med VLAN-gränssnitt som stöds.
• Säkerhetskopia med Legacy VLAN Tagging: En återställning till SFOS 22.0 GA eller senare kräver att källkonfigurationen rensas och en ny säkerhetskopia skapas.
• Lagringsutrymme eller uppgraderingsväg: Om Firmware-sidan rapporterar för lite lagringsutrymme eller en ogiltig uppgraderingsväg måste orsaken åtgärdas först.

Om en blockerare gäller eller någon punkt förblir oklar bör uppgraderingen inte startas.

Blockerarna ovan ska skiljas från följande meddelanden: NC-177529, NC-181885 och NC-184583 gäller bara den angivna versionen eller funktionen. Let’s Encrypt-fallet nedan är en obekräftad rapport, inte en allmän blockerare publicerad av Sophos.

Fastställ målversion och uppgraderingsväg

Status den 21 oktober 2026: SFOS 22.0 MR3 Build 576 har släppts. Från denna build är en uppgradering till SFOS 23.0 EAP1 uttryckligen inte möjlig. Den som planerar en v23-pilot måste därför klargöra den fortsatta versionsvägen före bytet till MR3; ett generellt ”först senaste v22, sedan v23” är fel för EAP1. Detta innebär ingen rekommendation att hoppa över nödvändiga produktionskorrigeringar till förmån för ett EAP-test.

Följande lista dokumenterar fortfarande enbart den direkta vägen till MR2 Build 546. För MR3 eller en senare målversion måste uppgraderingsmatrisen för exakt målbuild kontrolleras; denna MR2-lista utgör inget godkännande för det.

Direkt uppgraderingsväg till SFOS 22.0 MR2

För målversionen som behandlas här, SFOS 22.0 MR2 Build 546, stöder Sophos en direkt uppgradering från följande versioner:

• SFOS 22.0: MR1 Build 490 samt GA Build 411 eller 365
• SFOS 21.5: MR2 Build 323, MR1 Build 261 eller GA Build 171
• SFOS 21.0: MR2 Build 349, MR1 Build 277, 272 eller 237 samt GA Build 169
• Äldre versioner: alla versioner av SFOS 20.0, 19.5 eller 19.0

⚠️ Om den aktuella versionen inte finns med i listan får varningen om en migrering som inte stöds inte bekräftas. Annars startas brandväggen om med fabriksinställningar och den aktuella konfigurationen går förlorad. En säkerhetskopia kan också endast återställas från en version vars konfigurationsmigrering stöds.

För en äldre version eller en version som inte finns med i listan måste först en uppgraderingsväg med ett mellansteg som stöds planeras. Versionslistan ersätter inte heller de andra kontrollerna: plattform, lagring, äldre beroenden och återställningsplan måste också vara lämpliga.

Kontrollera före underhållsfönstret

Plattform och äldre beroenden

• Modell och aktuell firmware dokumenteras så att uppgraderingsvägen ovan och en eventuell återställning kan följas upp.
• XG- och SG-hårdvara behandlas som en migrering, inte som en vanlig uppgradering.
• UTM9 SSL VPN-tunnlar samt RED 15, RED 15w och RED 50 ersätts före uppgraderingen.
• Under Network > Interfaces korrigeras namn som slutar med tio eller fler siffror. Sådana namn kan dölja gränssnitt i WebAdmin efter uppgraderingen.

Lagring, backup och åtkomst

Under Backup & Firmware > Firmware dokumenteras först Current firmware samt version och build i den aktiva slotten. Under Latest available firmware, eller för en manuellt uppladdad image, måste exakt den tidigare godkända målbuilden anges. Om den tidigare dokumenterade MR2-vägen uttryckligen ska användas är detta SFOS 22.0 MR2 Build 546; för MR3 måste dess egen uppgraderingsmatris vara godkänd. Download hämtar bara imagen; Install startar versionsbytet. Upload Firmware placerar en manuell image i den inaktiva slotten, medan Upload & Boot startar om direkt. Kontrollera målbuild, åtgärd och aktiv slot igen innan du klickar. En varning på samma sida visar fältet Reference code.

Partitionernas fyllnadsgrad kan dessutom kontrolleras översiktligt i Advanced Shell:

df -kh

Om en varning visas på Firmware-sidan ska uppgraderingen inte startas ännu. Referenskoden visar orsaken och nästa steg:

• FWDS501: Primary Disk eller någon av dess systempartitioner är för liten för SFOS 22. På en VM som driftsattes före SFOS 18 kan samma äldre layout vid en uppgradering till SFOS 21.5 eller senare till en början endast visa sig som ett allmänt firmwarefel (NC-151465); meddelandet i sig bevisar dock inte diskfelet. För en virtuell brandvägg visar Utöka Primary Disk före SFOS 22 hur Hard disk 1 kontrolleras och utökas och hur resultatet sedan verifieras. Samma artikel innehåller rätt gränsvärden och lösningar för en programvaruappliance.
• FWDS502: det finns inte tillräckligt med ledigt utrymme i /var. I 4. Device Console visar system firmware check-disk-space hur mycket utrymme som behövs och vilka dataområden som berörs. Reports eller logs bör rensas kontrollerat först efter att nödvändiga data har säkrats; proceduren beskrivs i Kontrollera lagringsutrymme och hantera reports.
• FWDS503: partitionen /content är för liten. Sophos kräver en fabriksåterställning med driftstopp och förlust av den aktuella konfigurationen. Först skapas en aktuell säkerhetskopia och SSMK säkras. Därefter anges RESET med versaler i seriekonsolen och alternativ 2 väljs; det tar bort de egna konfigurationerna och återställer mönstersignaturerna till den aktiva firmwareversionens status. Sedan återställs säkerhetskopian och funktionerna kontrolleras; först därefter genomförs uppgraderingen. Lokala reports återställs inte.
• FWDS504: SSD-firmware är föråldrad och måste uppdateras före SFOS-uppgraderingen.
• FWDS505: Sophos Support måste kontrollera SSD-hälsan. En lokal SMART-kontroll kan dokumentera värden för supporten, men tar inte bort blockeringen.

I ett HA-kluster måste varje node kontrolleras separat, eftersom de två appliances kan visa olika referenskoder.

Före start måste dessutom följande finnas:

• en aktuell säkerhetskopia som sparats externt och tillhörande Secure Storage Master Key
• lokal administratörsåtkomst eller alternativ åtkomst utanför den normala VPN-vägen
• en definierad återgångsväg med ansvarig person och beslutspunkt
• för HA ett friskt, synkroniserat kluster med stabila HA-länkar och Monitored Ports

Detaljer om backup och återställning finns i Skapa eller återställ en Sophos Firewall-säkerhetskopia.

Konfigurationer med särskild risk

Legacy Remote Access IPsec

Från SFOS 22.0 MR1 blockerar en befintlig Legacy Remote Access IPsec-konfiguration uppgraderingen. Berörda användare, pooler och profiler måste först migreras till den aktuella Remote Access IPsec-konfigurationen, SSL VPN, ZTNA eller en annan lämplig lösning. Förfarandet beskrivs i Migrera Legacy Remote Access IPsec före SFOS 22 MR1.

Microsoft Entra ID SSO med Same as firewall

SFOS 22.0 eller senare aktiverar automatiskt Microsoft Entra ID SSO för VPN Portal, IPsec Remote Access och SSL VPN när deras autentiseringsmetod är inställd på Same as firewall före uppgraderingen. Därför dokumenteras inställningarna under Authentication > Services och den Identity Provider som faktiskt förväntas före underhållsfönstret.

Efter uppgraderingen kontrolleras varje effektiv metod separat. Om Entra SSO är avsett måste den exakta VPN portal and remote access URL från Entra-serverobjektet anges som Redirect URI i Entra-appen; Sophos Fusion (tidigare Sophos Central) reverse SSO-URL är fel för detta. En riktig pilotinloggning verifierar portal, klient och MFA. Om SSO inte är avsett anges den önskade metoden uttryckligen. Den fullständiga processen beskrivs i Konfigurera Microsoft Entra ID SSO för Sophos Firewall VPN.

Policy-baserad IPsec och NAT

Produktiva policy-baserade Site-to-Site-tunnlar bör testas före och efter uppgraderingen med ett konkret testflöde. Testet ska omfatta source, destination, service, Traffic Selectors, motpart samt förväntad brandväggs- och NAT-regel. Vid problem hjälper IPsec VPN-felsökning och Förstå NAT i Sophos Firewall.

Före uppgraderingen måste det dessutom klarläggas om OSPF eller BGP tidigare annonserade fjärranslutna policybaserade VPN-nät via redistribute kernel. Från SFOS 22 är dessa nät inte längre tillgängliga som vanliga kernelrutter; SFOS 22: IPsec-rutter och redistribute kernel visar vilka prefix som ska kontrolleras före och efter uppgraderingen och varför en design med route-based XFRM passar bättre för dynamisk routning.

SMTP via DNAT

Om en intern e-postserver publiceras via DNAT bör underhållsplanen omfatta flera verkliga inkommande testmeddelanden, inte bara ett porttest. Under NC-184583 beskriver Sophos sporadiskt avbrutna SMTP-anslutningar efter en uppgradering till SFOS 22.x; GA Respin Build 411 anges uttryckligen som berörd version. Den officiella Known Issues List hänvisar till Sophos Support för workarounden men publicerar inte stegen. Den exakta versionsavgränsningen, insamlingen av diagnostiskt underlag och supporteskaleringen beskrivs i Publicera en server via DNAT i Sophos Firewall.

Let’s Encrypt och rollback av MR2-migrering

Enligt release notes stöder MR2 Build 546 de nya Let’s Encrypt-CA:erna YE Root, YE1, YE2, YR Root, YR1 och YR2. Separat beskriver två offentliga Community-rapporter en misslyckad migrering från MR1 Build 490 till MR2 Build 546 medan ett Let’s Encrypt-certifikat användes, följd av automatisk rollback till MR1. Offentliga release notes och Known Issues List bekräftar inte sambandet. Den 5 september 2026 saknas därför ett officiellt Issue ID, ett tillförlitligt förhandstest och en bekräftad fixversion.

Före uppgraderingen av en MR1-brandvägg med ett nyligen utfärdat eller förnyat Let’s Encrypt-certifikat ska Issued by och alla tjänstetilldelningar under Certificates > Certificates dokumenteras. En YE/YR-issuer eller enbart förekomsten av dessa CA:er under Certificates > Certificate authorities bevisar inte det rapporterade felet och är i sig ingen blockerare. Sophos Support kan bedöma en enskild kritisk brandvägg i förväg; utan officiell bekräftelse förblir även en uppskjuten uppgradering ett operativt riskbeslut. Certifikat och CA:er får inte raderas eller döpas om på grund av en misstanke: ett dokumenterat borttagningsförsök i Community åtgärdade inte felet på ett tillförlitligt sätt, och certifikatet kan skydda WAF, WebAdmin, portaler, Hotspot eller SMTP TLS. Hantera certifikat på Sophos Firewall förklarar hur tilldelningar kontrolleras och en säker ersättning med återställningsväg förbereds.

Denna migreringsrollback är inte samma fel som en ofullständigt levererad certifikatkedja efter förnyelsen. Let’s Encrypt-certifikat på Sophos Firewall beskriver kontrollen av detta andra fel.

Efter en automatisk rollback stämmer felmönstret med det rapporterade mönstret om dbv22.004 och tblvpncertificate_caid_fkey visas i migration.log och den omgivande raderingsinstruktionen nämner YE/YR-objekt. Dessa söktermer hjälper till att hitta de relevanta raderna:

dbv22.004
tblvpncertificate_caid_fkey
Lets_Encrypt_YE
Lets_Encrypt_YR

Om de visas ska migration.log, migrationhash.log, firmwaremeddelandet, tidpunkten samt käll- och målbuild sparas, och samma uppgraderingsförsök får inte upprepas oförändrat. Kontrollera därefter källfirmware, HA, WAN, routing, VPN, Central-anslutningen och alla certifikatberoende tjänster. Spara Sophos Firewall-loggar för support beskriver hur rätt underlag samlas in; med dessa uppgifter kan Sophos Support avgränsa migreringsfelet.

Legacy VLAN Tagging på bridge-gränssnitt

Legacy CLI VLAN Tagging på bridge-gränssnitt får tre konsekvenser:

• Under GA och MR1 kan trafik från eller till brandväggen sluta fungera medan transittrafiken fortsätter.
• Från MR2 blockeras uppgraderingen.
• En berörd säkerhetskopia kan inte återställas till SFOS 22.0 GA eller senare.

Före rensningen måste bridge, VLAN-ID:n, IP-adresser, zoner, switchtrunkar och beroende tjänster dokumenteras. Därefter skapas VLAN-gränssnitt som stöds med bridgen som parent och en ny säkerhetskopia genereras. Specialfallet beskrivs i Kontrollera Sophos Firewall bridge-VLAN före SFOS 22.

STAS

Vid en uppgradering till MR1 måste alternativet Restrict client traffic during identity probe under Authentication > STAS vara inställt på No. MR2 åtgärdar MR1-felet och använder No som standard för nya konfigurationer; befintliga värden och användarbaserade regler bör ändå kontrolleras. Mer information finns i Konfigurera STAS i Sophos Firewall.

Malware-skanning vid uppgradering till GA Build 411

Endast vid en riktad uppgradering till SFOS 22.0 GA Respin Build 411 kan NC-177529 tillfälligt rapportera Malware Unscannable under migreringen, ofta för www.msftconnecttest.com, eftersom Sophos nya skanningsmotor ännu inte är tillgänglig. Byt före denna GA-uppgradering under Web > General settings från Single engine till Dual engine och återställ tidigare använd Single Engine efter den slutförda uppgraderingen. Åtgärden gäller inte generellt för MR1, MR2 eller senare releaser; bakgrunden och valet av skanningsmotor förklaras i Konfigurera och testa malware-skanning i Sophos Firewall.

Underhållsfönster, godkännande och återgång

Planera avbrottet och HA-sekvensen

På en fristående brandvägg installeras den nya firmwareversionen och aktiveras genom en omstart; trafiken är avbruten tills omstarten är klar. HA garanterar inte heller en uppgradering utan avbrott. Båda noderna måste vara nåbara, friska och synkroniserade, och var och en måste uppfylla lagrings- och SSD-kraven. En enda nod som inte uppfyller kraven kan blockera hela uppgraderingen.

Starta HA-uppgraderingen endast på Primary, inte separat på Auxiliary. Klustret uppgraderar först Auxiliary, växlar över trafiken till den och uppgraderar sedan den tidigare Primary. Beroende på Preferred Primary kan därefter en failback ske. Räkna med korta avbrott vid båda växlingarna. Guiden för firmwareuppdatering beskriver installationen och manuell uppladdning i offlinemiljöer.

En extra omstart före uppgraderingen är bara ett valfritt sätt att tömma minnescachen, inte ett krav eller en lösning på oförklarad instabilitet. Den orsakar ytterligare ett avbrott; spara först relevanta loggar och kontrollera vägen för att återfå hanteringsåtkomst. Den allmänna uppdateringsförberedelsen förklarar kontrollerna av systemhälsan. Lagrings- och SSD-kontrollerna gäller även SFOS 22.0 och senare, men den direkta uppgraderingsvägen ovan gäller endast MR2 Build 546, inte SFOS 23 eller andra målbuilds.

Bedöm en misslyckad uppgradering säkert

Från SFOS 20.0 kan brandväggen automatiskt återgå till föregående firmware och konfiguration vid vissa fel i konfigurationsmigreringen. Det skyddar det fungerande tillståndet, men garanterar varken återgång vid alla fel eller att nästa försök lyckas. Vänta först tills processen eller en möjlig automatisk rollback är klar och kontrollera därefter aktiv version, systemhälsa, lagring och båda noderna vid HA. Spara migreringsloggarna, klarlägg orsaken och den uppgraderingsväg som stöds och planera först därefter ett nytt försök; kontakta Sophos Support om resultatet är oklart. Firmwareguiden beskriver begränsningarna för automatisk rollback och felsökning, även när firmware, patterns eller hotfixar inte kommer fram på grund av anslutningsproblem eller blockerade uppdateringstjänster.

Före en manuell HA-återgång måste båda noderna ha samma kompatibla inaktiva firmware. Om den saknas ska Boot firmware image inte väljas blint; planera i stället den separata HA-återställningen som beskrivs i firmwareguiden. Om HA inte var konfigurerat i det tidigare konfigurationstillståndet startar båda enheterna i fristående läge efter återgången och HA måste konfigureras igen.

Godkännande och beslut om återgång

• Före: Blockerare utesluts, säkerhetskopia och SSMK görs tillgängliga, HA-synkroniseringen kontrolleras och källversion, aktiv slot, målbuild, VPN-vägar, testflöden och återgångsväg dokumenteras.
• Under: Inga parallella ändringar av routing, VPN eller switching genomförs; status och HA-failover övervakas. Bekräfta efter den nya inloggningen under Backup & Firmware > Firmware att Current firmware visar den tidigare godkända målbuilden (Build 546 om MR2-vägen uttryckligen valdes); för HA kontrolleras även båda nodernas version, roll och synkronisering.
• Efter: Testa gränssnitt och WAN, internetåtkomst, DNS, DHCP, Central, HA, STAS, autentisering, brandväggsregler, VPN, NAT och publicerade tjänster med de fördefinierade flödena. Log Viewer och Packet Capture måste visa förväntade Firewall och NAT Rule IDs.

En grön tunnel eller ett lyckat Policy Test bevisar ännu inte att nyttotrafiken fungerar. Därför kontrolleras kritiska anslutningar med riktiga paket, Log Viewer, Packet Capture samt Firewall och NAT Rule ID. Vid problem bör inte flera områden ändras samtidigt.

Fastställ före underhållsfönstret hur länge ett avbrott får analyseras. Om WAN, HA, centrala VPN eller kritiska publiceringar fortfarande är instabila vid denna beslutspunkt väljer du Boot firmware image för föregående kompatibla slot under Backup & Firmware > Firmware. Denna manuella återgång aktiverar både firmware och den äldre konfigurationen för slotten, så ändringar efter uppgraderingen kan gå förlorade. Planera den inte för en uppgraderingsväg som inte stöds eller som ersättning för backup, SSMK och en reimage-väg. Efter återgången testas aktiv version, HA, WAN, routing, VPN, NAT, DNS, DHCP, Central och logging igen, och migreringsloggarna sparas före ett nytt försök.

Uppgraderingen är klar när de definierade testerna har lyckats och målversion, HA-status, testresultat samt öppna efterarbeten har dokumenterats.

FAQ