Sophos Firewall v22 MR3: compatibilità IPsec e 16 fix

Il 16 ottobre 2026 Sophos ha rilasciato Sophos Firewall OS 22.0 MR3 Build 576. Dopo le nuove funzionalità di v22 MR2, l’attenzione si concentra su un aggiornamento di manutenzione più contenuto: le note di rilascio ufficiali elencano 16 problemi risolti. Si aggiunge una nuova impostazione per le connessioni IPsec site-to-site con dispositivi di altri produttori.

Per pianificare l’aggiornamento, conta soprattutto quali servizi vengono utilizzati sul singolo firewall. Una sede con più peer VPN richiede verifiche di accettazione diverse da quelle di un firewall con Mail Protection o di un cluster HA. MR3 va quindi valutato in base alla propria configurazione e installato durante una finestra di manutenzione pianificata.

IPsec con altri produttori: tunnel attivo, ma senza traffico

MR3 introduce un comando che consente di disattivare i controlli rigorosi delle policy per IPsec site-to-site. Il motivo riguarda i peer che utilizzano la stessa Security Association (SA) per più coppie di sottoreti. Questo comportamento poteva causare lo scarto del traffico in ingresso quando non corrispondeva alla SA prevista.

In termini semplici, una SA definisce i parametri di sicurezza di una connessione IPsec. Un tunnel attivo, da solo, non dimostra quindi che tutte le reti previste possano comunicare tra loro. Soprattutto in presenza di più reti locali e remote, la verifica di accettazione dovrebbe coprire ogni combinazione necessaria.

La nuova opzione non giustifica la disattivazione preventiva del controllo su tutti i sistemi. Per prima cosa, il troubleshooting IPsec dovrebbe chiarire se i sintomi riscontrati corrispondono effettivamente a un problema di associazione delle SA. Routing, regole firewall e NAT restano possibili cause di un tunnel senza traffico utile. Il nostro articolo KB Impostazioni VPN globali descrive sintassi, ambito di applicazione e uso controllato di ipsec-strict-policy-check nella sezione dedicata al controllo rigoroso delle policy IPsec.

Per un test attendibile, occorre avviare connessioni in entrambe le direzioni. Le acquisizioni dei pacchetti e i contatori dei tunnel coinvolti aiutano a distinguere tra traffico che non arriva, pacchetti scartati e assenza di un percorso di ritorno.

Le correzioni più rilevanti per l’operatività

I punti seguenti sono una selezione delle note di rilascio ufficiali:

• NC-186809, HA: la sincronizzazione dei certificati poteva rendere irraggiungibili WebAdmin e VPN Portal.
• NC-186075, rete: le porte RJ45 perdevano temporaneamente il collegamento con determinati switch.
• NC-182635, Application Control: gli aggiornamenti ripetuti dei percorsi delle applicazioni causavano un carico CPU elevato.
• NC-181808, RED: voci RED_DEVICE_DROP obsolete bloccavano il traffico dopo un nuovo provisioning.
• NC-183979, e-mail: uno spool di posta di grandi dimensioni prolungava il riavvio durante l’aggiornamento a MR2.
• NC-180464, DNAT: il traffico SMTP veniva erroneamente scartato dopo un aggiornamento.
• NC-184117, STAS: agli utenti già autenticati veniva nuovamente richiesto l’accesso tramite Captive Portal.
• NC-182222, SSL VPN: i nomi utente numerici impedivano le connessioni dopo l’aggiornamento a MR1.

Le altre voci riguardano filtri utente, errori Syslog, creazione di AP VXLAN, disattivazione HA, IPsec, database delle firme e report PDF.

Nella pratica, da questo elenco dovrebbe derivare una breve verifica di accettazione specifica per la sede. Per HA, vanno controllati la raggiungibilità dell’interfaccia di amministrazione e del VPN Portal, oltre allo stato della sincronizzazione. Nelle sedi RED, occorre testare un’applicazione reale attraverso la connessione. Per un gateway di posta, la consegna in ingresso e in uscita e la coda sono più significative di un ping riuscito.

Anche in caso di problemi di CPU, è utile confrontare la situazione prima e dopo l’aggiornamento con un carico simile. Una correzione pertinente nelle note di rilascio è un indizio, ma non dimostra ancora che sia stata individuata la causa di un problema specifico.

Config Studio 2.7 facilita le modifiche mirate

Parallelamente al firmware, Sophos presenta Config Studio 2.7. Questo strumento separato, utilizzabile nel browser, consente di visualizzare modifiche mirate ed esportarle in formato XML o TAR. Anche le richieste API possono essere limitate agli oggetti aggiunti, modificati e rimossi. Si aggiungono correzioni al confronto delle configurazioni, all’assistente per le Web Exception e al calcolo dei tunnel SD-WAN.

Il vantaggio emerge soprattutto durante la revisione: un insieme ridotto di modifiche è più facile da verificare rispetto a un’esportazione completa della configurazione. Prima di un’importazione, occorre comunque controllare quali oggetti dipendenti debbano essere già presenti sul sistema di destinazione. Un’esportazione ridotta non sostituisce né un backup né la successiva verifica del funzionamento. Il nostro articolo su Config Studio 2.6 illustra le funzionalità disponibili fino a quella versione.

Il nostro articolo KB Pianificare l’aggiornamento del firmware descrive la preparazione, dal percorso di aggiornamento al backup e alla finestra di manutenzione. I singoli passaggi in WebAdmin e tramite Sophos Fusion, insieme alle verifiche successive e al rollback, sono descritti in Eseguire l’aggiornamento del firmware di Sophos Firewall.