Sophos Firewall SFOS 22: verifica dei blocchi prima dell'upgrade

Prima di un upgrade a SFOS 22 occorre verificare se piattaforma, percorso di upgrade e configurazione supportano la release di destinazione. Questa verifica tiene conto di SFOS 22.0 MR2 Build 546 del 14 luglio 2026 e integra la guida generale all’aggiornamento del firmware di Sophos Firewall.

Blocchi rigidi per upgrade e restore

• Hardware XG o SG: SFOS 22 non è supportato. Invece di un upgrade, è necessaria una migrazione a XGS o a una piattaforma virtuale, software o cloud.
• Legacy Remote Access IPsec: A partire da SFOS 22.0 MR1, la configurazione deve essere migrata o rimossa prima dell’upgrade.
• Legacy CLI VLAN Tagging su un’interfaccia bridge: A partire da SFOS 22.0 MR2, system vlan-tag deve essere sostituito con interfacce VLAN supportate.
• Backup con Legacy VLAN Tagging: Per un restore su SFOS 22.0 GA o versioni successive, occorre correggere la configurazione di origine e creare un nuovo backup.
• Storage o percorso di upgrade: Se la pagina del firmware segnala storage insufficiente o un percorso di upgrade non valido, occorre prima risolvere la causa.

Se è presente un blocco o un punto resta incerto, l’upgrade non dovrebbe essere avviato.

Percorso di upgrade diretto a SFOS 22.0 MR2

Per la destinazione trattata qui, SFOS 22.0 MR2 Build 546, Sophos supporta un upgrade diretto dalle versioni seguenti:

• SFOS 22.0: MR1 Build 490 e GA Build 411 o 365
• SFOS 21.5: MR2 Build 323, MR1 Build 261 o GA Build 171
• SFOS 21.0: MR2 Build 349, MR1 Build 277, 272 o 237 e GA Build 169
• Versioni precedenti: qualsiasi versione SFOS 20.0, 19.5 o 19.0

⚠️ Se la versione attuale non è presente in questo elenco, l’avviso relativo a una migrazione non supportata non deve essere confermato. In caso contrario, il firewall si riavvia con le impostazioni di fabbrica e la configurazione attuale viene persa. Anche un backup può essere ripristinato soltanto da una versione per la quale è supportata la migrazione della configurazione.

Per una versione precedente o non elencata occorre innanzitutto pianificare un percorso intermedio supportato. L’elenco delle versioni non sostituisce inoltre gli altri controlli: anche piattaforma, storage, dipendenze legacy e piano di ripristino devono essere idonei.

Verifiche prima della finestra di manutenzione

Piattaforma e dipendenze legacy

• Documentare il modello e il firmware attuale affinché il percorso di upgrade indicato sopra e un eventuale ripristino rimangano tracciabili.
• Trattare l’hardware XG e SG come una migrazione, non come un normale upgrade.
• Sostituire prima dell’upgrade i tunnel UTM9 SSL VPN e i dispositivi RED 15, RED 15w e RED 50.
• In Network > Interfaces, correggere i nomi che terminano con dieci o più cifre. Dopo l’upgrade, questi nomi possono nascondere le interfacce in WebAdmin.

Storage, backup e accesso

Il riempimento delle partizioni può essere verificato in modo approssimativo nella Advanced Shell:

df -kh

Se nella pagina del firmware compare un avviso, l’upgrade non deve ancora essere avviato. Il codice di riferimento indica la causa e il passaggio successivo:

• FWDS501: il Primary Disk o una delle relative partizioni di sistema è troppo piccolo per SFOS 22. In una VM distribuita prima di SFOS 18, la stessa condizione preesistente può inizialmente comparire soltanto come errore generico del firmware durante l’upgrade a SFOS 21.5 o versione successiva (NC-151465); tuttavia, il messaggio da solo non dimostra un problema del disco. Per un firewall virtuale, ampliare il Primary Disk prima di SFOS 22 mostra come controllare ed espandere Hard disk 1, quindi verificare il risultato. Lo stesso articolo indica le soglie e le soluzioni appropriate per una Software Appliance.
• FWDS502: lo spazio libero in /var non è sufficiente. In 4. Device Console, system firmware check-disk-space mostra lo spazio necessario e le aree dati coinvolte. Reports o logs devono essere eliminati in modo controllato solo dopo aver salvato i dati necessari; la procedura è descritta in Controllare lo spazio e gestire i reports.
• FWDS503: la partizione /content è troppo piccola. Sophos richiede un factory reset con interruzione del servizio e perdita della configurazione attuale. Dopo aver creato un backup recente e salvato il SSMK, inserire RESET in maiuscolo tramite la console seriale e selezionare l’opzione 2; in questo modo vengono eliminate le configurazioni personalizzate e le firme dei pattern vengono ripristinate allo stato del firmware attivo. Successivamente, ripristinare il backup, verificare le funzioni e solo allora eseguire l’upgrade. I reports locali non vengono ripristinati.
• FWDS504: il firmware dell’SSD è obsoleto e deve essere aggiornato prima dell’upgrade di SFOS.
• FWDS505: Sophos Support deve verificare lo stato dell’SSD. Un controllo SMART locale può documentare i valori per il supporto, ma non rimuove il blocco.

In un cluster HA ogni nodo deve essere controllato separatamente, perché le due appliance possono mostrare codici di riferimento differenti.

Prima di iniziare devono inoltre essere disponibili:

• un backup recente salvato esternamente e il relativo Secure Storage Master Key
• un accesso amministrativo locale o un accesso alternativo al di fuori del normale percorso VPN
• un percorso di fallback definito, con responsabile e punto decisionale
• per HA, un cluster integro e sincronizzato con link HA e Monitored Ports stabili

I dettagli su backup e restore sono descritti in Creare o ripristinare un backup di Sophos Firewall.

Configurazioni particolarmente rischiose

Legacy Remote Access IPsec

Da SFOS 22.0 MR1, una configurazione Legacy Remote Access IPsec esistente blocca l’upgrade. Gli utenti, i pool e i profili interessati devono essere prima migrati alla configurazione Remote Access IPsec attuale, a SSL VPN, ZTNA o a un altro design adatto. La procedura è descritta in Migrare Legacy Remote Access IPsec prima di SFOS 22 MR1.

Microsoft Entra ID SSO con Same as firewall

SFOS 22.0 o successivo attiva automaticamente Microsoft Entra ID SSO per VPN Portal, Remote Access IPsec e SSL VPN quando il relativo metodo di autenticazione è impostato su Same as firewall prima dell’upgrade. Prima della finestra di manutenzione vanno quindi documentate le impostazioni in Authentication > Services e l’Identity Provider realmente previsto.

Dopo l’upgrade si controlla separatamente ogni metodo effettivo. Se Entra SSO è previsto, l’esatta VPN portal and remote access URL dell’oggetto server Entra deve essere configurata come Redirect URI nell’app Entra; l’URL reverse SSO di Sophos Central non è corretto per questo scopo. Un login pilota reale verifica portale, client e MFA. Se SSO non è previsto, si imposta espressamente il metodo desiderato. La procedura completa è descritta in Configurare Microsoft Entra ID SSO per la VPN Sophos Firewall.

Policy-based IPsec e NAT

I tunnel policy-based Site-to-Site in produzione dovrebbero essere verificati prima e dopo l’upgrade con un flusso di test concreto. Il test deve includere source, destination, service, Traffic Selectors, controparte e regole firewall e NAT previste. In caso di problemi sono utili Troubleshooting IPsec VPN e Comprendere il NAT su Sophos Firewall.

Prima dell’upgrade, occorre inoltre determinare se OSPF o BGP annunciava in precedenza le reti VPN remote policy-based tramite redistribute kernel. A partire da SFOS 22, queste reti non sono più disponibili come normali route del kernel; SFOS 22: route IPsec e redistribute kernel mostra quali prefissi verificare prima e dopo l’upgrade e perché un design XFRM route-based è più adatto al routing dinamico.

SMTP tramite DNAT

Se un mail server interno viene pubblicato tramite DNAT, il piano di manutenzione dovrebbe includere più messaggi di test reali in ingresso e non soltanto un test della porta. Per NC-184583, Sophos segnala connessioni SMTP interrotte sporadicamente dopo un upgrade a SFOS 22.x; la versione espressamente indicata come interessata è GA Respin Build 411 e non è disponibile un workaround pubblico. La precisa delimitazione delle versioni, la raccolta delle evidenze e l’escalation al supporto sono descritte in Pubblicare un server tramite DNAT su Sophos Firewall.

Let’s Encrypt e rollback della migrazione MR2

MR2 Build 546 supporta le nuove CA Let’s Encrypt YE Root, YE1, YE2, YR Root, YR1 e YR2. Indipendentemente da questo, in due upgrade documentati pubblicamente da MR1 Build 490 a MR2 Build 546 la migrazione della configurazione si è interrotta in relazione a un certificato Let’s Encrypt in uso. Il firewall è tornato automaticamente a MR1. Dopo una verifica tramite Support Access, Sophos ha confermato un blocco della migrazione noto per certificati emessi in un periodo specifico, ma non delimitato pubblicamente. Al 9 agosto 2026 non sono ancora disponibili un issue ID pubblico, un test preliminare affidabile o una versione con la correzione confermata.

Prima di eseguire l’upgrade di un firewall MR1 con un certificato Let’s Encrypt emesso o rinnovato di recente, documentare l’Issuer e l’assegnazione al servizio in Certificates > Certificates. Un Issuer YE/YR o la sola presenza di queste CA in Certificate authorities non dimostra l’errore di migrazione e, da sola, non costituisce un blocco generale dell’upgrade. Per un firewall critico è comunque opportuno concordare preventivamente il caso con Sophos Support o rinviare l’upgrade finché non viene confermato un test preliminare pubblico o una correzione. Certificati e CA non devono essere eliminati o rinominati per precauzione: un tentativo di eliminazione documentato nella Community non ha risolto l’errore in modo affidabile e il certificato può proteggere WAF, WebAdmin, portali, Hotspot o SMTP TLS. Gestire i certificati su Sophos Firewall spiega come verificare le assegnazioni e preparare una sostituzione sicura con un percorso di rollback.

Questo rollback della migrazione non è lo stesso errore di una catena di certificati incompleta fornita dopo il rinnovo. Certificati Let’s Encrypt su Sophos Firewall descrive la verifica di questo secondo problema e l’hotfix distribuito a tale scopo.

Dopo un rollback automatico, il comportamento corrisponde al problema noto se dbv22.004 e tblvpncertificate_caid_fkey compaiono in migration.log e l’istruzione di eliminazione circostante menziona oggetti YE/YR. Questi termini di ricerca aiutano a individuare le righe pertinenti:

dbv22.004
tblvpncertificate_caid_fkey
Lets_Encrypt_YE
Lets_Encrypt_YR

Se compaiono, salvare migration.log, migrationhash.log, il messaggio del firmware, l’ora e le build di origine e destinazione senza ripetere invariato l’upgrade. Verificare quindi firmware di origine, HA, WAN, routing, VPN, connessione a Central e tutti i servizi dipendenti dai certificati. Raccogliere i log di Sophos Firewall per il supporto mostra come conservare le evidenze; con questi dati Sophos Support può circoscrivere l’errore di migrazione.

Legacy VLAN Tagging sui bridge

Il Legacy CLI VLAN Tagging sulle interfacce bridge ha tre conseguenze:

• Con GA e MR1, il traffico da o verso il firewall può interrompersi mentre il traffico di transito continua a funzionare.
• Da MR2, l’upgrade viene bloccato.
• Un backup interessato non può essere ripristinato su SFOS 22.0 GA o versioni successive.

Prima della correzione occorre documentare bridge, ID VLAN, indirizzi IP, zone, trunk degli switch e servizi dipendenti. Successivamente si creano interfacce VLAN supportate con il bridge come parent e si genera un nuovo backup. Il caso specifico è descritto in Verificare i bridge VLAN di Sophos Firewall prima di SFOS 22.

STAS

Per un upgrade a MR1, in Authentication > STAS l’opzione Restrict client traffic during identity probe deve essere impostata su No. MR2 corregge l’errore di MR1 e usa No come valore predefinito per le nuove configurazioni; i valori esistenti e le regole basate su utente dovrebbero comunque essere verificati. Per maggiori dettagli, vedere Configurare STAS su Sophos Firewall.

Scansione malware durante l’upgrade a GA Build 411

Solo durante un upgrade mirato a SFOS 22.0 GA Respin Build 411, NC-177529 può segnalare temporaneamente Malware Unscannable durante la migrazione, spesso per www.msftconnecttest.com, perché il nuovo motore di scansione Sophos non è ancora disponibile. Prima di questo upgrade a GA, passare da Single engine a Dual engine in Web > General settings e tornare al Single Engine utilizzato in precedenza una volta completato l’upgrade. Questa misura non si applica in generale a MR1, MR2 o release successive; Configurare e testare la scansione malware di Sophos Firewall spiega il contesto e la selezione del motore di scansione.

Finestra di manutenzione e controlli

• Prima: Escludere i blocchi, rendere disponibili backup e SSMK, verificare la sincronizzazione HA e documentare i flussi VPN, i test e il percorso di fallback.
• Durante: Non apportare modifiche parallele a routing, VPN o switching; osservare lo stato e il failover HA.
• Dopo: Verificare firmware, interfacce, Internet, regole firewall, VPN, NAT, HA, STAS, DNS, DHCP, Central e Log Viewer.

Un tunnel verde o un Policy Test riuscito non dimostra ancora che il traffico utile funzioni. Verificare quindi le connessioni critiche con pacchetti reali, Log Viewer, Packet Capture e Firewall e NAT Rule ID. In caso di problemi, non modificare più aree contemporaneamente.

L’upgrade è concluso quando i test definiti hanno avuto esito positivo e sono stati documentati versione di destinazione, stato HA, risultati dei test e attività ancora aperte.

FAQ