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

Varningar på Firmware-sidan måste åtgärdas före uppgraderingen. Referenskoden visar vad som blockerar uppgraderingen:

• FWDS501: Primary Disk eller någon av dess partitioner är för liten för SFOS 22. FWDS501: utöka Primary Disk före SFOS 22 förklarar hur den berörda partitionen identifieras och om den befintliga installationen kan utökas eller om brandväggen måste driftsättas på nytt.
• 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.

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.

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.

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.

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