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 tar hänsyn till SFOS 22.0 MR2 Build 546 från den 14 juli 2026 och kompletterar 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 XGS 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.

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

Partitionernas fyllnadsgrad kan 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 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 och det finns ingen offentlig workaround. 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

MR2 Build 546 stöder de nya Let’s Encrypt-CA:erna YE Root, YE1, YE2, YR Root, YR1 och YR2. Oberoende av detta avbröts konfigurationsmigreringen i samband med ett Let’s Encrypt-certifikat som användes vid två offentligt dokumenterade uppgraderingar från MR1 Build 490 till MR2 Build 546. Brandväggen återgick automatiskt till MR1. Efter en kontroll via Support Access bekräftade Sophos ett känt migreringshinder för certifikat från en viss, men inte offentligt avgränsad, utfärdandeperiod. Den 9 augusti 2026 saknas fortfarande ett offentligt 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 Issuer och tjänstetilldelningen under Certificates > Certificates dokumenteras. En YE/YR-Issuer eller enbart förekomsten av dessa CA:er under Certificate authorities bevisar inte migreringsfelet och är i sig inget allmänt uppgraderingshinder. För en kritisk brandvägg är det ändå lämpligt att stämma av fallet med Sophos Support i förväg eller skjuta upp uppgraderingen tills ett offentligt förhandstest eller en korrigering har bekräftats. 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 och den hotfix som rullats ut för det.

Efter en automatisk rollback stämmer felmönstret med det kända problemet 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 och kontroll

• Före: Blockerare utesluts, säkerhetskopia och SSMK görs tillgängliga, HA-synkroniseringen kontrolleras och VPN-, test- och återgångsvägar dokumenteras.
• Under: Inga parallella ändringar av routing, VPN eller switching genomförs; status och HA-failover övervakas.
• Efter: Firmware, gränssnitt, internet, brandväggsregler, VPN, NAT, HA, STAS, DNS, DHCP, Central och Log Viewer kontrolleras.

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.

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

FAQ