Configurare l'High Availability (HA) su Sophos Firewall

High Availability, abbreviato in HA, collega due Sophos Firewall in un cluster. Nella maggior parte degli ambienti, Active-Passive con QuickHA è la scelta migliore: un firewall elabora il traffico e il secondo subentra in caso di guasto o manutenzione. Prima di iniziare, verificare che entrambi i dispositivi, le build del firmware, le licenze, il cablaggio e l’accesso di gestione soddisfino i requisiti HA.

Questo articolo accompagna il lettore dalla scelta della modalità HA alla configurazione, al test di failover, all’operatività e all’RMA. HA non sostituisce né un buon design di rete né i backup.

Scegliere modalità HA e architettura

Raccomandazione operativa di Avanet: nella maggior parte degli ambienti produttivi, Active-Passive è la variante HA migliore. Un firewall gestisce tutto il traffico, mentre il secondo è pronto a subentrare in caso di guasto o manutenzione. Il design è più semplice, la licenza è più economica e il comportamento in caso di errore è più facile da comprendere. Si tratta di una raccomandazione progettuale, non di un requisito di Sophos.

Active-Active è utile solo se si accettano consapevolmente i limiti e le restrizioni. Non è un classico bilanciamento del carico simmetrico, in cui entrambi i firewall sono ugualmente posizionati in tutte le parti della rete. Il firewall primario continua a ricevere il traffico e distribuisce alcune connessioni al firewall ausiliario. Non tutti i servizi e non tutti i tipi di traffico vengono distribuiti.

Come orientamento rapido vale quanto segue:

• Massima stabilità e gestione semplice: Active-Passive.
• Usare il secondo firewall senza licenza di protezione separata: Active-Passive.
• Serve più throughput per determinate connessioni TCP: valutare Active-Active.
• Molti casi VPN, proxy, RED, NDR o speciali: preferire Active-Passive.
• Ambiente piccolo o medio senza chiaro problema di performance: Active-Passive.
• Requisito di performance chiaro e licenze adatte su entrambe le appliance: Active-Active dopo test.

I due Sophos Techvids mostrano visivamente la configurazione e il cambio di ruolo:

Cosa significa High Availability

Un cluster HA di Sophos Firewall è composto da due firewall. I dispositivi scambiano tramite un HA-Link dedicato heartbeat, stato del dispositivo, informazioni sulle connessioni e dati di configurazione. La configurazione viene sincronizzata dal firewall primario al firewall ausiliario.

HA protegge dai guasti tipici:

• Guasto del firewall primario
• Guasto di alimentazione o hardware
• Guasto di un’interfaccia monitorata
• Problema software o di servizio che rende un dispositivo non operativo
• Aggiornamenti firmware pianificati
• Cambio di ruolo pianificato durante la manutenzione

Tuttavia, HA non risolve ogni problema:

• Una regola firewall errata rimane errata anche nel cluster.
• Un guasto di uno switch comune può influenzare entrambi i firewall contemporaneamente.
• Un design VLAN difettoso o un’impostazione di routing errata non vengono corretti automaticamente.
• I log e i report non vengono sincronizzati tra i due firewall.
• Un backup rimane comunque obbligatorio.

Chi pianifica HA dovrebbe chiarire in anticipo le basi per zone, interfacce, VLAN, LAG e bridge. A tal fine, è utile la guida Pianificare e configurare zone e interfacce di Sophos Firewall.

Active-Passive o Active-Active

Active-Passive

In modalità Active-Passive, un firewall gestisce tutto il traffico produttivo. Il secondo firewall è passivo e subentra solo se il firewall attivo si guasta o se viene attivato un failover manualmente o tramite manutenzione.

Caratteristiche tipiche:

• Il firewall primario gestisce il traffico.
• Il firewall ausiliario rimane in standby.
• Le sessioni vengono sincronizzate, se supportato dal servizio.
• Solo il dispositivo con licenza necessita delle sottoscrizioni di protezione per le appliance hardware.
• Se viene usato il MAC virtuale del cluster, il firewall ausiliario subentra in caso di failover con lo stesso indirizzo MAC virtuale.
• In questo caso, i dispositivi di rete generalmente non devono apprendere nuovamente i propri vicini.

Active-Passive è generalmente la scelta migliore per ambienti aziendali classici, filiali, data center e ambienti in cui la stabilità è più importante di un possibile guadagno di prestazioni.

Active-Active

In modalità Active-Active, entrambi i firewall gestiscono il traffico. Tuttavia, l’architettura rimane asimmetrica: il firewall primario riceve il traffico e decide se gestire una connessione da solo o inoltrarla al firewall ausiliario.

Sophos utilizza l’indirizzo IP di origine per la distribuzione: le connessioni TCP idonee da indirizzi IP di origine pari vengono elaborate dal Primary, mentre quelle da indirizzi dispari passano all’Auxiliary. Vengono distribuiti il traffico TCP inoltrato e le connessioni TCP tradotte, inclusi SNAT e traffico Virtual Host, anche su interfacce VLAN. Dopo aver elaborato una connessione, l’Auxiliary invia i pacchetti direttamente alla destinazione, senza farli ripassare dal Primary. Questo metodo pari-dispari è fisso e non può essere modificato. Il supporto Layer 7 varia a seconda del servizio: secondo Sophos, DPI Engine, proxy trasparenti, diretti e Parent Proxies, nonché traffico SMTP Proxy e HTTPS, supportano il bilanciamento del carico. FTP sottoposto a scansione e H.323 non lo supportano. Sono esclusi anche il traffico non TCP come UDP, ICMP, multicast e broadcast, SD-RED e il traffico TCP e non TCP incapsulato in tunnel, incluse le VPN. I load balancer esterni non sono supportati per HA.

Entrambi i nodi richiedono licenze adeguate e registrano localmente i log del traffico che elaborano. Active-Active ha quindi senso solo con un obiettivo di prestazioni chiaro e quando il traffico rilevante viene effettivamente distribuito. Per la sola alta disponibilità, Active-Passive è generalmente più lineare.

Ruoli, stato e failover

Ruoli nel cluster HA

• Primary: dispositivo che gestisce la configurazione centrale del cluster. In entrambe le modalità HA, il Primary riceve il traffico.
• Auxiliary: secondo dispositivo del cluster. Sincronizza la configurazione dal Primary e subentra quando necessario.
• Initial primary: dispositivo avviato come Primary durante la configurazione. In Active-Passive è generalmente anche il dispositivo che detiene la licenza. Questa proprietà rimane invariata indipendentemente dal fatto che il nodo sia attualmente Active o Passive.
• Preferred primary: dispositivo preferito che deve tornare Primary dopo un failover non appena è nuovamente disponibile in modo stabile.

In modalità Active-Passive, WebAdmin sull’Auxiliary non mostra Live users, DHCP leases o connessioni IPsec attive. È il comportamento previsto e non dimostra un errore di sincronizzazione. Per questi dati di runtime fa fede il Primary attualmente attivo.

Valori di stato durante l’operatività

• Active: il dispositivo elabora il traffico.
• Passive: il dispositivo è pronto, ma in Active-Passive non elabora traffico produttivo.
• Standalone: il dispositivo non vede il peer oppure HA non è completamente attivo. In caso di problemi con il HA-Link, entrambi i dispositivi possono diventare Standalone.
• Faulty: il dispositivo non è sufficientemente integro per partecipare normalmente al cluster.

Indirizzo MAC virtuale

Se viene usato il MAC virtuale del cluster HA, SFOS assegna indirizzi MAC virtuali alle interfacce fisiche, ad eccezione del Dedicated HA Link e delle porte di amministrazione. Il Dedicated HA Link utilizza il proprio indirizzo MAC fisico. Solo il primario risponde alle richieste ARP per il cluster. In caso di failover, l’ausiliario assume l’indirizzo MAC virtuale della rispettiva interfaccia produttiva. Ciò mantiene più stabile la raggiungibilità per switch, router e client, poiché l’associazione IP e MAC non cambia radicalmente. L’opzione MAC dell’interfaccia descritta più avanti è una variante diversa; non presumere lo stesso comportamento di subentro del MAC virtuale.

Importante è l’ID del cluster. Questo ID viene utilizzato per l’indirizzo MAC virtuale. Se più cluster HA vengono eseguiti nello stesso ambiente Layer-2, ogni cluster deve avere un ID univoco. Altrimenti possono verificarsi conflitti MAC.

Cosa viene sincronizzato

• Regole firewall, policy, oggetti, routing e configurazione CLI vengono sincronizzati dal Primary all’Auxiliary.
• Sessioni attive vengono sincronizzate a seconda del protocollo e del servizio. In Active-Active, entrambi i dispositivi scambiano con il peer lo stato e i dettagli delle sessioni attive; la sincronizzazione della configurazione rimane invece diretta dal Primary all’Auxiliary.
• Secure Storage Master Key e credenziali WebAdmin vengono sincronizzati.
• Dedicated HA link e porte di amministrazione: la fonte ufficiale sulle modalità e sui ruoli HA li esclude esplicitamente dalla sincronizzazione. Le indicazioni discordanti sull’indirizzamento di management sono descritte nei requisiti di rete.
• Log e report non vengono sincronizzati tra i dispositivi.

Comportamento del failover

In Active-Passive, l’Auxiliary subentra nella gestione di tutto il traffico se il Primary si guasta. In Active-Active, invece, il guasto di uno dei due dispositivi attivi può far subentrare il peer sano. Se si guasta l’Auxiliary, il Primary elabora da solo tutto il traffico; ciò non comporta necessariamente un cambio di ruolo. Quando un peer non è più disponibile, il dispositivo rimanente opera come Standalone. Questo stato, da solo, non dimostra quindi un guasto dell’HA-Link su entrambi i lati; verificare ruoli e raggiungibilità di entrambi i nodi prima di applicare il runbook per lo split-brain.

Un failover può essere attivato da vari eventi:

• assenza di heartbeat sull’HA-Link
• guasto di una porta monitorata
• interruzione di corrente
• guasto hardware
• problema software o di servizio
• cambio di ruolo pianificato
• aggiornamento firmware

Se un singolo nodo si avvia in modalità Failsafe, documentare prima il suo ruolo e lo stato del peer. Verificare un Sophos Firewall in modalità Failsafe mostra la procedura diagnostica sicura e spiega perché non bisogna riavviare entrambi i nodi senza coordinamento né disattivare HA sulla base di semplici supposizioni.

Gli heartbeat sul Dedicated HA Link sono richieste VRRP. SFOS 22 usa per impostazione predefinita 250 ms e 16 heartbeat mancanti, con un timeout heartbeat di 4 secondi. SFOS 23 usa 100 ms e 3 tentativi, con un timeout di 300 ms; i link HA basati su LAG richiedono altri valori, come spiegato più avanti. Questi timeout non garantiscono il tempo di ripristino del traffico. Per le Monitored Ports, invece, è sufficiente il guasto di una sola porta perché il dispositivo sia considerato non disponibile e venga attivato il failover.

Indicazioni discordanti sugli heartbeat per SFOS 23: la descrizione generale del failover continua a indicare 250 ms e 16 tentativi, mentre le istruzioni dettagliate di configurazione per SFOS 23 indicano 100 ms e 3 tentativi. I valori predefiniti di SFOS 23 riportati qui provengono dalle istruzioni dettagliate di configurazione, non da una misurazione sul dispositivo. Prima di una modifica in System services > High availability, documentare i valori effettivamente configurati e la topologia dell’HA-Link su entrambi i nodi. Né l’indicazione precedente né il valore predefinito di configurazione più breve giustificano la modifica di un cluster esistente senza previa verifica; se i valori sono poco chiari o non soddisfano il requisito LAG, chiarire la pianificazione con Sophos Support.

Dopo il failover, WebAdmin sul precedente Auxiliary Firewall mostra la configurazione del Primary. Alle sessioni attive si applicano limiti diversi:

Quando torna l’Initial Primary, rimane nel cluster come Auxiliary se Preferred primary non è selezionato. Se è impostato come Preferred primary, SFOS sincronizza prima i servizi e poi esegue automaticamente il failback. Durante il processo, il dispositivo che fino a quel momento operava da solo si riavvia. Questo failback deve quindi essere pianificato in una finestra di manutenzione. I cambi di ruolo e i riavvii descritti non garantiscono l’elaborazione senza interruzioni delle connessioni esistenti.

Servizi supportati e limitati

Sophos HA supporta la maggior parte dei servizi firewall, ma i limiti operativi differiscono notevolmente:

Se la reportistica o la conservazione dei log è importante, si dovrebbe pianificare in anticipo se utilizzare un server Syslog esterno o Sophos Fusion Firewall Reporting. Maggiori dettagli sono disponibili in Attivare Central Firewall Reporting.

Per configurazione, limiti di sicurezza e test, utilizzare Configurare il mDNS reflector. Il rilevamento dei servizi non concede l’accesso alle applicazioni; il supporto HA non garantisce sessioni applicative senza interruzioni. Questa affermazione su mDNS si applica a SFOS 23, non a SFOS 22.

Requisiti e design di rete

Prima di implementare, è necessario verificare attentamente i requisiti HA rispetto al proprio ambiente. In particolare, l’uguaglianza del modello, la versione del firmware, le interfacce, il Cellular WAN e le piattaforme virtuali sono punti in cui piccole deviazioni possono avere grandi effetti in seguito.

Compatibilità hardware e modello

• Modello dell’appliance: entrambi i firewall devono essere dello stesso modello XGS Appliance, per esempio XGS 2100 con XGS 2100.
• Revisione hardware: con lo stesso modello XGS Appliance sono possibili revisioni hardware diverse.
• Modelli XGS Appliance Wi-Fi: non supportati. Esempi sono XGS 126w o XGS 136w.
• Moduli Flexi Port: se si usano moduli di espansione, il numero e il modello dei moduli Flexi Port devono essere uguali su entrambi i dispositivi.
• Firmware: entrambi i dispositivi devono usare la stessa versione SFOS, inclusi Maintenance Release e Build.
• Hardware più appliance virtuale: non è possibile come coppia HA.

Importante: i moduli Flexi Port non sono sostituibili a caldo. Per aggiungerli, spegnere in modo controllato entrambi i firewall, installare lo stesso modello di modulo su entrambi i dispositivi e riavviarli. Configurare quindi i nuovi Flexi Ports solo sul Primary corrente in Network > Interfaces. SFOS sincronizza questa configurazione delle porte con l’Auxiliary. Non modificare un solo nodo mentre il cluster è in funzione.

SFOS 22 non supporta più hardware XG o SG Series. Prima della migrazione a SFOS 22, questi dispositivi devono essere sostituiti con una XGS Appliance supportata o con una piattaforma virtuale adeguata.

Appliance virtuali e software

Le appliance virtuali o software devono anch’esse essere molto compatibili tra loro. Esempi di piattaforme virtuali sono Microsoft Hyper-V, VMware e Nutanix Prism; le appliance software vengono eseguite su hardware proprio. La menzione di una piattaforma non sostituisce la verifica dei seguenti requisiti HA.

• Piattaforma: stesso tipo di appliance e stessa piattaforma SFOS.
• Hypervisor: stesso tipo di hypervisor.
• Risorse: risorse hardware assegnate identiche, compresi lo stesso numero di core CPU e lo stesso numero di interfacce di rete.
• Firmware: stessa versione SFOS, incluso il Build.
• Indirizzi MAC: in ambienti virtuali, l’opzione per indirizzi MAC assegnati dall’hypervisor può essere rilevante per evitare Promiscuous Mode. Una modifica causa downtime.

Se il cluster usa l’indirizzo MAC virtuale generato da SFOS, la piattaforma di virtualizzazione deve accettare le variazioni MAC. In VMware ESXi, impostare MAC Address Changes e Forged Transmits su Accept nel vSwitch o nel port group; i port group devono ereditare i valori del vSwitch o essere configurati di conseguenza. In Hyper-V, attivare Enable MAC address spoofing su tutti gli adattatori di rete virtuali di entrambi i firewall, tranne quello del Dedicated HA Link. In alternativa, selezionare Use host or hypervisor-assigned MAC address in SFOS 22 o Use interface MAC address in SFOS 23; sulle appliance virtuali entrambe usano il MAC assegnato dall’hypervisor, quindi queste modifiche alla piattaforma non sono necessarie. L’opzione SFOS 23 usa anche il MAC dell’interfaccia sulle appliance hardware anziché il MAC virtuale del cluster. Attivarla o disattivarla aggiorna la configurazione delle interfacce e causa downtime.

Deployment in cloud

Negli ambienti cloud si applicano ulteriori requisiti di piattaforma. Routing, interfacce virtuali, indirizzi IP, Security Groups, UDR e meccanismi di failover specifici del cloud devono essere coerenti con l’architettura cloud adottata. L’approccio HA normale per le appliance non può essere trasferito senza verifica su Azure, AWS o altri ambienti cloud.

Se un Sophos Firewall viene eseguito nel cloud, si dovrebbe verificare la documentazione Sophos aggiornata per la piattaforma specifica e l’architettura di rete cloud prima di pianificare HA.

Gateway, Bridge e Discover/TAP

HA è disponibile nelle modalità gateway e bridge. La modalità Discover o TAP supporta solo Active-Passive. Se almeno un nodo opera in modalità discover, non è possibile creare un cluster Active-Active. Anche un’interfaccia TAP attiva impedisce la configurazione Active-Passive. Disattivare l’interfaccia TAP su entrambi i firewall tramite CLI, stabilire HA e riattivare TAP singolarmente su ciascun nodo. TAP rimane attivo anche sull’Auxiliary passivo.

Licenze e registrazione

La licenza HA varia a seconda della piattaforma e della modalità HA. Tre domande sono cruciali: si tratta di hardware o virtuale/software? Si utilizza Active-Passive o Active-Active? E quale dispositivo è l’Initial Primary, cioè il dispositivo che detiene la licenza per il cluster? Questi punti dovrebbero essere verificati prima dell’implementazione con lo stato della licenza, i numeri di serie e la modalità di destinazione.

I punti di licenza più importanti:

• Base Firewall: per HA è necessaria una licenza Base Firewall. Le appliance hardware la includono per default, ma termina quando il dispositivo raggiunge l’End of Life. Nelle appliance cloud, virtuali e software la licenza Base Firewall non scade, ma deve essere presente per HA.
• Active-Passive Hardware: solo il dispositivo Initial Primary necessita delle Subscription produttive. Il firewall Auxiliary riceve una copia delle Subscription e può gestire traffico dopo un failover.
• Active-Active Hardware: entrambi i firewall necessitano di licenze adatte. I tipi di licenza devono corrispondere, le date di scadenza possono essere diverse.
• Active-Passive Virtual/Software: solo il Primary necessita delle licenze necessarie, inclusa Base Firewall.
• Active-Active Virtual/Software: entrambi i dispositivi necessitano di una propria licenza Base Firewall e di ulteriori licenze di protezione con tipi corrispondenti.
• Registrazione Hardware: entrambi i dispositivi hardware devono essere claimati in Sophos Fusion (in precedenza Sophos Central) prima della configurazione HA e devono poter sincronizzare le licenze.
• Registrazione Virtual/Software Active-Passive: in Active-Passive Virtual/Software, secondo Sophos viene claimato solo il Primary.
• Sophos Central Management: sincronizzazione licenze e claiming non significano automaticamente che i firewall siano gestiti anche tramite Sophos Fusion Firewall Management. Serve una Subscription aggiuntiva adatta.
• RMA e supporto: Advance Hardware Replacement richiede Enhanced Plus Support sul Primary di un cluster hardware Active-Passive. In Active-Active, ogni dispositivo richiede Enhanced Support o Enhanced Plus Support.

Gestire la coppia HA in Sophos Fusion

Una coppia HA può essere collegata a switch del livello di accesso, inclusi Sophos Switches. Sophos Fusion, consente la gestione centralizzata dei firewall e dei Sophos Switches. Questo non sostituisce un design ridondante degli switch: un guasto di uno switch condiviso può comunque interessare entrambi i nodi. La panoramica precedente di SFOS 23 utilizza ancora il nome Sophos Fusion; ciò non implica un’architettura HA diversa.

Una coppia HA già configurata viene gestita in Sophos Fusion come una singola coppia, non come due firewall indipendenti. Entrambi i nodi devono avere la stessa versione firmware e, per Central Management, accesso Internet IPv4 funzionante e la sottoscrizione adeguata. Il claiming e la sincronizzazione delle licenze, da soli, non attivano la gestione.

Quando due firewall già gestiti singolarmente in Sophos Fusion vengono uniti in una coppia HA, Sophos consiglia di deregistrare prima entrambi. Stabilire HA localmente, registrare nuovamente la coppia completa per Central Management e, se necessario, spostarla in un altro gruppo Central.

Sul Primary attuale, aprire System > Sophos Central e selezionare Register both HA devices. Quindi attivare Central Management e, in Sophos Fusion sotto My Products > Firewall Management > Firewalls, aprire Approval Pending per il Primary e confermare accept-services. Dopo alcuni minuti la coppia dovrebbe comparire una sola volta con l’icona HA; le modifiche da Sophos Fusion vengono quindi applicate a entrambi i firewall.

Lo stato in Central non sostituisce la verifica locale. Dopo la registrazione, controllare localmente ruoli HA, sincronizzazione, stato delle licenze e un confronto di configurazione privo di impatto. Se compaiono due voci indipendenti o Approval Pending rimane, non deregistrare preventivamente nessuno dei firewall. Confrontare prima numeri di serie, tenant Central, percorso IPv4 e stato HA locale.

Importante: in Active-Passive, l’Initial Primary è particolarmente importante, poiché questo dispositivo detiene la licenza per il cluster. Nella vista HA, sul dispositivo corrispondente è indicato che detiene la licenza per il cluster. Identificare e documentare inequivocabilmente il dispositivo nel manuale operativo.

Licenza sul firewall errato – solo Active-Passive: se le Subscription Active-Passive sono state assegnate per errore all’Auxiliary anziché all’Initial Primary titolare delle licenze, la sincronizzazione non è sufficiente. Prima di qualsiasi modifica, documentare il numero di serie di origine dell’Auxiliary a cui sono state assegnate per errore le licenze e il numero di serie di destinazione previsto dell’Initial Primary, separatamente dai ruoli HA correnti, e verificarne la corrispondenza in SFOS e Sophos Fusion. Questa procedura di correzione abbreviata vale solo se il Primary corrente e l’Initial Primary sono lo stesso dispositivo fisico. Se sono diversi o l’associazione non è chiara, fermarsi prima di disattivare HA o trasferire le licenze e chiarire la procedura applicabile sulla base delle istruzioni Sophos o con Sophos Support; non improvvisare un ritorno ai ruoli precedenti. Solo quando l’associazione è inequivocabile, disattivare HA in modo pianificato sul Primary corrente, trasferire le Subscription in Sophos Fusion dal numero di serie di origine documentato al numero di serie di destinazione documentato dell’Initial Primary e configurare nuovamente il cluster Active-Passive. I trasferimenti di licenza sono rilevanti anche per RMA o cambi di modello, ma richiedono la procedura applicabile al caso specifico. Poiché i modelli HA devono essere identici, in caso di cambio modello devono essere sostituiti entrambi i dispositivi. In Active-Active anche l’Auxiliary deve possedere licenze proprie. Non è un errore e non va corretto con questo trasferimento. Non riutilizzare questa procedura Active-Passive per RMA Active-Active senza istruzioni Sophos applicabili.

Le licenze Active-Active scadute o non sincronizzate possono interrompere il load balancing e disattivare HA. Per hardware e Virtual/Software, Sophos descrive in modo contraddittorio l’inizio dell’interruzione: il riepilogo lo colloca alla fine di tre giorni, mentre i dettagli lo collocano nei primi tre giorni e la disattivazione HA successivamente. L’inizio esatto rimane irrisolto; non è garantito alcun periodo di tolleranza di tre giorni. Correggere tempestivamente i problemi di licenza e, se necessario, concordare con Sophos Support un piano operativo sicuro per il build installato. Durante la configurazione iniziale, Active-Active non viene attivato con licenze non corrispondenti.

In Active-Passive, sincronizzare le licenze del Primary. L’Initial Primary titolare delle licenze deve sincronizzarle almeno una volta ogni 90 giorni. Sulle appliance hardware, in caso contrario si interrompono le Subscription di protezione interessate, mentre Base Firewall ed Enhanced Support rimangono attivi. Sulle appliance Virtual/Software, la licenza Base Firewall viene disattivata, HA viene disabilitato e le altre funzioni di protezione diventano inattive. I cluster con licenze online richiedono quindi DNS, ora di sistema corretta, routing e accesso Internet ai servizi di licenza Sophos. I cluster isolati utilizzano invece il workflow manuale Air Gap documentato.

In Active-Active, su hardware e Virtual/Software, sincronizzare individualmente le licenze di entrambi i dispositivi con Sophos Fusion e verificare l’esito positivo sul Primary e sull’Auxiliary. Tipi di licenza corrispondenti e possesso delle licenze non sostituiscono questo passaggio. Sull’hardware, Base Firewall ed Enhanced Support restano attivi durante i problemi di licenza descritti; su Virtual/Software, una licenza Base Firewall disattivata disabilita HA e rende inattive le altre licenze. Non utilizzare l’indicazione irrisolta dei tre giorni come intervallo di sincronizzazione.

Per l’operatività, si dovrebbe documentare almeno:

• quale dispositivo è l’Initial Primary
• quali numeri di serie o ID delle appliance appartengono al cluster
• quali licenze sono attive su quale dispositivo
• quando le licenze sono state sincronizzate con successo l’ultima volta; in Active-Active, registrare stato e orario separatamente per entrambi i nodi
• quale livello di supporto è disponibile per RMA o Advance Replacement
• chi autorizza le modifiche alle licenze, i rinnovi e i processi RMA

Requisiti di rete

• HA-Link: connessione dedicata tra i due firewall, idealmente direttamente con cavo Ethernet.
• Zona HA-Link: zona DMZ con SSH attivato per la zona.
• Indirizzi IP HA-Link: indirizzi IP statici nella stessa subnet, ma indirizzi diversi.
• Qualità HA-Link: alta larghezza di banda, bassa latenza, nessuna perdita di pacchetti.
• Switch: attivare RSTP sugli switch collegati alle porte firewall.
• Monitored Ports: monitorare solo porte effettivamente collegate e critiche.
• Cellular WAN: disattivare per HA.
• Peer Admin Port: pianificare separatamente, in modo che il firewall Auxiliary rimanga raggiungibile.
• Indirizzi delle interfacce: Active-Active richiede indirizzi IP statici su tutte le interfacce. Active-Passive consente DHCP, DHCP Prefix Delegation o PPPoE. Per la connessione PPPoE è documentata l’assenza di failover della sessione.

In Active-Passive, le interfacce di produzione possono usare DHCP, DHCP Prefix Delegation o PPPoE, ma il Dedicated HA Link e le due porte di amministrazione richiedono comunque indirizzi statici. In Active-Active, tutte le interfacce devono avere indirizzi statici. Il limite documentato per PPPoE non dimostra un’eccezione generale al failover delle sessioni sulle interfacce DHCP: assegnazione degli indirizzi e traffico del protocollo DHCP sono distinti dalla conservazione delle sessioni TCP inoltrate. Applicare i limiti per protocollo e servizio riportati sopra, senza dedurne una garanzia generale di conservazione delle sessioni su DHCP.

Le interfacce breakout vengono configurate sul Primary. Per una nuova configurazione breakout, riavviare prima il Primary per applicare la modifica e poi l’Auxiliary. Se la configurazione breakout corrispondente è già presente sul Primary, dopo la sincronizzazione riavviare solo l’Auxiliary. Se sul Primary non esiste la configurazione breakout corrispondente, la sincronizzazione elimina una configurazione breakout presente solo sull’Auxiliary. I singoli casi sono spiegati in Configurare le interfacce breakout.

L’HA-Link non gestisce traffico normale di client o server. È solo rilevante per heartbeat, stato, sincronizzazione delle sessioni, sincronizzazione delle configurazioni e distribuzione Active-Active. Non può essere riutilizzato per HSRP, perché i messaggi hello HSRP non attraversano il Dedicated HA Link. Tuttavia, è estremamente critico. Se l’HA-Link si guasta, entrambi i firewall possono credere di essere primari. Proprio questo scenario di split-brain deve essere evitato.

Il Peer Admin Port consente l’accesso operativo al WebAdmin del firewall Auxiliary dalla stessa subnet della sua porta di amministrazione. QuickHA seleziona automaticamente l’interfaccia della sessione WebAdmin corrente. Indicazioni ufficiali discordanti sull’indirizzamento di management: la fonte sulle modalità e sui ruoli HA esclude dalla sincronizzazione sia il Dedicated HA link sia le porte di amministrazione; i requisiti HA specifici per le interfacce richiedono due indirizzi IP di amministrazione/management statici, diversi e nella stessa subnet. La guida iniziale alla porta di management vieta invece indirizzi PortMGMT diversi in HA, motivando il divieto con la sincronizzazione della configurazione. Queste istruzioni si contraddicono: un IP PortMGMT condiviso più un IP Peer Administration aggiuntivo non costituisce una riconciliazione accertata. Prima della configurazione o di modifiche agli indirizzi di management, documentare i ruoli Primary/Auxiliary correnti e quelli previsti per i nodi standalone, la build SFOS esatta installata, l’interfaccia di amministrazione selezionata e gli IP attuali; salvare un backup in modo sicuro e predisporre un accesso amministrativo separato tramite console o accesso locale. Verificare il comportamento applicabile alla build installata sulla base delle istruzioni pertinenti o chiarirlo con Sophos Support. Se il conflitto resta irrisolto, fermarsi prima di Initiate HA o di qualsiasi modifica agli indirizzi di management.

L’indirizzo predefinito delle porte normali è 172.16.16.16; il PortMGMT dedicato delle appliance più grandi usa 10.0.1.1. Il Primary è raggiungibile da qualsiasi zona in cui HTTPS è consentito in Administration > Device access. Per accedere al WebAdmin dell’Auxiliary, l’endpoint di amministrazione deve trovarsi nella stessa subnet della sua porta di amministrazione.

Porte e interfacce

• Dedicated HA link: serve per heartbeat, stato, sincronizzazione configurazione e sessioni. Collegarlo direttamente o tramite uno switch molto affidabile. Non usare per traffico produttivo.
• Monitored ports: monitorano link produttivi critici. Monitorare WAN, importanti uplink DMZ o core, ma non selezionare porte inutilizzate.
• Peer Admin Port: consente l’accesso al WebAdmin Auxiliary. Pianificarlo e documentarlo separatamente; il client deve trovarsi nella subnet adatta.
• Interfacce di produzione: LAN, WAN, DMZ, VLAN e LAG vanno cablati e progettati in modo identico su entrambi i firewall.

Come Dedicated HA link sono possibili interfacce fisiche, VLAN o LAG. Le interfacce bridge e gli indirizzi IP alias non possono essere utilizzati come HA-Link dedicato. QuickHA può raggruppare fino a quattro interfacce fisiche non associate in un HA redundant link; se si usa un LAG già configurato, le interfacce parent devono essere strutturate allo stesso modo su entrambe le appliance.

In SFOS 23, un Dedicated HA link con LAG o VLAN su LAG richiede Keepalive request interval × Keepalive attempts ≥ 2500 ms. Il valore predefinito di configurazione di SFOS 23, 100 ms × 3 = 300 ms, non soddisfa questo requisito LAG e non deve essere applicato qui senza modifiche. Un esempio consentito è 250 ms × 10 tentativi = 2500 ms, non un valore predefinito universale. QuickHA crea un HA redundant link come LAG quando si seleziona più di un’interfaccia fisica non associata; il requisito si applica quindi anche a questa topologia. Verificare la configurazione effettiva del link. Non presumere che QuickHA negozi automaticamente valori adeguati; verificare i valori configurati prima di fare affidamento sul cluster.

Porte ad alta velocità: per le porte 25, 50 e 100 GbE delle XGS 7500/8500 Series, selezionare su entrambi i lati lo stesso Link mode con velocità e duplex corrispondenti in Network > Interfaces > Advanced settings e salvare con Save. Quindi riaprire l’interfaccia in modifica, usare Show recommended settings > Load recommended configuration per la negoziazione e la Forward Error Correction (FEC) e salvare nuovamente con Save. Se le impostazioni consigliate rimangono vuote dopo il primo salvataggio e la riapertura, disattivare Auto-negotiation per Media Type e FEC e salvare la modifica. Per le altre porte usare Automatic o valori di velocità e duplex identici e mantenere MTU e MSS sui valori predefiniti. Quando QuickHA seleziona un’interfaccia non associata, SFOS ne reimposta gli Advanced settings; ricontrollare questi valori dopo la creazione di HA.

Importante: Dedicated HA link e Monitored Port non possono essere la stessa interfaccia. Se un’interfaccia è già usata in una configurazione produttiva e viene comunque selezionata come HA-Link, il firewall può modificare o rimuovere configurazioni dipendenti dell’interfaccia. Per questo l’HA-Link deve essere libero e documentato in anticipo.

Design di rete

Entrambi i firewall devono poter assumere la stessa posizione di rete in caso di guasto. Interfacce produttive, trunk VLAN, LAG, porte switch e connessioni del provider devono quindi essere cablati in modo equivalente su entrambi i lati. Ridondanza WAN, SD-WAN e failover del provider restano attività separate: HA non li sostituisce.

• Collegare il Dedicated HA link direttamente, se possibile. Se passa attraverso switch, il percorso deve essere stabile, a bassa latenza e senza perdita di pacchetti.
• Nodi HA geograficamente separati sono sensati solo attraverso una rete Layer 2 a bassa latenza nello stesso dominio broadcast. Il Dedicated HA Link rimane nella stessa subnet IP; latenza elevata o perdita di pacchetti rendono il design inadatto.
• Attivare RSTP sugli switch coinvolti e configurare VLAN, trunk e LAG in modo identico su entrambi i lati.
• Monitorare solo uplink WAN, core o DMZ collegati in modo permanente. Una Monitored Port volutamente scollegata causa altrimenti un failover.
• VLAN e LAG sono supportati, ma devono utilizzare le stesse interfacce parent su entrambi i nodi. Bridge Mode funziona, ma è più complesso da diagnosticare rispetto a Gateway Mode.
• Testare separatamente scenari VPN, RED e remoti, perché non tutte le sessioni vengono trasferite in modo trasparente.
• Limitare consapevolmente accesso di management e Device Access. Vedere Proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access.

Per Active-Active deve inoltre essere chiaro quale collo di bottiglia viene ridotto dal traffico TCP realmente distribuibile. Se licenze, servizi e troubleshooting su entrambi i nodi non sono definiti, Active-Passive resta la scelta migliore.

Attenzione: in caso di split-brain, entrambi i firewall si considerano responsabili. Ciò può causare un uso duplicato di indirizzi IP e MAC e un’interruzione della produzione. Se l’HA-Link si guasta, stabilire prima quale nodo deve restare attivo e arrestare l’altro in modo controllato o scollegarlo dalla rete di produzione.

Preparare la configurazione

Prima di configurare HA, non si dovrebbe improvvisare nella rete produttiva. Questa preparazione risparmia molto tempo in seguito.

Preparazione di entrambi i firewall

• Portare entrambi i firewall alla stessa versione SFOS, incluso il Build.
• Verificare lo stato della licenza e della registrazione.
• Disattivare il Cellular WAN.
• Assicurarsi che i modelli siano compatibili.
• Verificare l’equipaggiamento dei Flexi Port.
• Documentare le interfacce e le porte switch.
• Determinare la porta HA-Link.
• Collegare direttamente l’HA-Link o verificare il percorso switch.
• Pianificare la zona DMZ e l’accesso SSH per l’HA-Link.
• Documentare l’accesso amministrativo a entrambi i dispositivi.
• Creare un backup della configurazione esistente.
• Se LINCE è necessario, uniformare la modalità su entrambi i dispositivi prima di configurare HA.

FIPS segue una sequenza diversa da LINCE. La modalità FIPS 140-3 viene prima attivata sul Primary standalone, provocando un factory reset; durante il successivo setup HA, Sophos attiva automaticamente FIPS sull’Auxiliary.

I backup non sono opzionali in HA. Prima della configurazione, degli aggiornamenti firmware e delle modifiche maggiori alle interfacce, dovrebbe essere disponibile un backup. Le basi sono descritte in Creare o ripristinare un backup di Sophos Firewall.

Prima di fare clic su Initiate HA va verificato anche:

• Preflight degli indirizzi di amministrazione: documentare ruoli Primary/Auxiliary correnti e ruoli previsti per i nodi standalone, build SFOS esatta, interfaccia admin selezionata e IP attuali; avere un backup salvato in modo sicuro e un accesso console/locale separato. Chiarire le istruzioni discordanti sugli IP di management per la build installata, se necessario con Sophos Support. Se il conflitto resta irrisolto, non selezionare Initiate HA e non modificare gli indirizzi di management.
• Dedicated HA link senza dipendenze produttive: HA può modificare indirizzi IP e configurazioni dipendenti delle interfacce.
• Monitored Ports collegate su entrambi i dispositivi: una Monitored Port scollegata può impedire il cluster o causare subito failover.
• Cluster ID univoco: più cluster HA nello stesso dominio Layer-2 richiedono MAC virtuali diversi.
• Backup, SSMK e firmware build documentati: per restore, RMA o reimage il cluster deve essere riproducibile.

Definire LINCE prima di HA

A partire da SFOS 21.5 MR1, LINCE non può più essere attivato o disattivato dopo la creazione di un cluster HA. Se la certificazione è necessaria, eseguire il comando seguente nella Device Console su entrambi i firewall ancora autonomi.

Avvertenza: Prima assicurarsi che WebAdmin o la console locale siano disponibili come accesso amministrativo alternativo. Il comando attiva LINCE, riavvia il servizio SSH e interrompe le sessioni SSH esistenti.

system certification lince enable

Verificare quindi lo stato LINCE su entrambi i dispositivi e solo dopo configurare HA. In caso di restore, il backup e il cluster di destinazione devono avere lo stesso stato LINCE.

Comprendere e attivare la modalità LINCE su Sophos Firewall spiega perché la modalità non certifica automaticamente la build SFOS installata e quali algoritmi SSH devono essere verificati prima dell’attivazione.

QuickHA o Interactive mode

• QuickHA: caso standard. Veloce, robusto e sufficiente per la maggior parte delle configurazioni Active-Passive e Active-Active.
• Interactive mode: utile quando Admin Ports, indirizzi HA-Link, Cluster ID, Monitored Ports e valori dettagliati devono essere definiti prima della configurazione.

QuickHA richiede inizialmente solo ruolo, nome del nodo, passphrase e Dedicated HA link. La passphrase deve contenere da 10 a 20 caratteri, almeno una lettera maiuscola, una minuscola, un numero e un carattere speciale. Viene utilizzata una sola volta per generare le chiavi SSH e poi eliminata. Prima di sostituire un dispositivo in una coppia HA ancora funzionante, HA deve quindi essere disattivato e successivamente riconfigurato con il dispositivo sostitutivo. Le sezioni corrispondenti più avanti illustrano lo stato iniziale specifico dopo un RMA e le descrizioni divergenti del reimage.

I dispositivi QuickHA preparati continuano a cercare il peer finché non lo trovano. Possono quindi essere configurati in anticipo e collegati successivamente nella sede di destinazione. Quando un dispositivo ha scoperto il peer e la creazione HA è in corso, questo processo di discovery non può più essere interrotto. La selezione delle interfacce, la passphrase e il peer previsto devono quindi essere corretti prima che entrambi i link HA siano raggiungibili contemporaneamente.

I passaggi descritti qui si basano sulla configurazione HA ufficiale di Sophos, ma sono formulati come una checklist amministrativa pratica. Per modifiche in produzione, non limitarsi a seguire i passaggi dell’assistente: documentare in anticipo ruoli, HA-Link, accesso amministrativo, backup, stato delle licenze e percorso di rollback.

Nomi dei nodi in QuickHA: in SFOS 22 l’assegnazione del nome è facoltativa. Per SFOS 23, le istruzioni dettagliate richiedono un nome del nodo, mentre le istruzioni di esempio continuano a indicarlo come facoltativo. La checklist seguente assegna quindi ai due dispositivi nomi diversi e facilmente riconoscibili. Si tratta di un’indicazione prudenziale, non di una prova che la GUI rifiuti un campo del nome vuoto.

Configurare HA

Active-Passive con QuickHA

1. Preparare il firewall primario

1. Accedere al WebAdmin sul firewall che diventerà primario.
2. Passare a System services > High availability.
3. Selezionare la modalità Primary (active-passive).
4. Utilizzare QuickHA.
5. Assegnare un nome univoco al nodo, ad esempio FW01.
6. Impostare una passphrase HA da 10 a 20 caratteri con lettera maiuscola, lettera minuscola, numero e carattere speciale.
7. Memorizzare in modo sicuro la passphrase, poiché sarà necessaria subito sul firewall ausiliario.
8. Selezionare il Dedicated HA link.
9. Avviare Initiate HA.

Note:

• Se QuickHA utilizza un’interfaccia non associata, Sophos le assegna la zona DMZ e, per impostazione predefinita, 169.254.192.1. SSH viene attivato automaticamente per la zona.
• Il firewall rimuove le configurazioni dipendenti dell’interfaccia HA-Link selezionata. L’interfaccia deve quindi essere libera da dipendenze produttive.

2. Preparare il firewall ausiliario

1. Accedere al firewall che diventerà ausiliario.
2. Passare a System services > High availability.
3. Selezionare il ruolo Auxiliary.
4. Utilizzare QuickHA.
5. Assegnare al nodo un nome diverso da quello del Primary, ad esempio FW02.
6. Inserire la stessa passphrase HA.
7. Selezionare la stessa porta HA-Link usata sul lato primario.
8. Avviare Initiate HA.

Dopo la configurazione, il firewall primario sincronizza la configurazione sul firewall ausiliario. Sul firewall ausiliario, molte impostazioni locali vengono sovrascritte. Pertanto, il firewall ausiliario non dovrebbe essere configurato parallelamente come firewall produttivo autonomo prima della configurazione HA.

3. Verificare le impostazioni avanzate

Dopo la configurazione del cluster, non si dovrebbe semplicemente chiudere WebAdmin, ma verificare i seguenti punti:

• Stato HA di entrambi i nodi
• Ruolo e stato in alto a destra nel WebAdmin
• Dedicated HA link
• Porte monitorate
• Peer Admin Port
• Preferred primary
• Intervallo di keepalive e tentativi
• Titolare della licenza in Active-Passive
• Registrazione Sophos Fusion, se utilizzata

4. Impostare le porte monitorate

Le Monitored Ports determinano se il guasto di un’interfaccia attiva un failover. Il campo di selezione si chiama Select ports to be monitored in SFOS 22 e Monitored interfaces nelle istruzioni dettagliate di SFOS 23. Candidati tipici:

• Uplink WAN
• Uplink core LAN
• Uplink DMZ o server importanti

Non si dovrebbero monitorare porte che a volte sono intenzionalmente offline, non cablate o utilizzate solo per scenari opzionali. Una porta monitorata impostata in modo errato è una causa comune di failover inaspettati o di un cluster che non si avvia.

È possibile selezionare interfacce fisiche, LAG e interfacce non associate con una VLAN configurata. Un’interfaccia non associata senza VLAN non può essere selezionata come Monitored Port. Le Monitored Ports richiedono indirizzi IP statici in entrambe le modalità HA.

SFOS 23 consente al massimo 24 Monitored ports. Mantenere la selezione distinta dal Dedicated HA link e includere solo link produttivi realmente necessari.

HA funziona anche senza Monitored Ports selezionate. In questo caso, il solo guasto di una porta di produzione non attiva un failover; la mancata ricezione degli heartbeat o i guasti del dispositivo o dell’alimentazione possono comunque attivare un cambio di ruolo. Ogni porta effettivamente selezionata deve essere collegata su entrambi i nodi. Il monitoraggio dello stato delle porte non rileva tutti i guasti di un provider a monte.

Le impostazioni HA avanzate, come Monitored interfaces, Peer administration, Preferred primary e i valori di keepalive, vengono modificate sul Primary corrente dopo la creazione del cluster con QuickHA. Prima verificare la disponibilità di un backup, di una finestra di manutenzione e di un accesso amministrativo garantito; la modifica del MAC descritta sopra causa downtime. Per Peer administration e gli indirizzi di management, ripetere il preflight sul conflitto delle fonti descritto nei requisiti di rete, documentando anche i ruoli previsti per i nodi standalone; se resta irrisolto, non modificare gli indirizzi e non selezionare Initiate HA. Per un HA-Link basato su LAG, rispettare il requisito di keepalive e non modificare i valori nello stato Standalone o Faulty. Dopo aver effettuato la selezione desiderata, tornare all’inizio della pagina e selezionare Initiate HA. Il Primary sincronizza così le modifiche con l’Auxiliary. Verificare quindi su entrambi i nodi ruoli HA, stato, sincronizzazione e valori modificati; in caso di discrepanze, confrontare prima l’HA-Link e i log di entrambi i dispositivi. Questo passaggio conclusivo vale anche per la variante Active-Active descritta di seguito e va distinto dall’adesione iniziale dei due dispositivi al cluster.

Active-Active con QuickHA

Active-Active viene configurato in modo simile, ma con un obiettivo diverso. Prima, entrambi i firewall devono essere adeguatamente licenziati.

La procedura corrisponde ad Active-Passive, ma su FW01 si seleziona Primary (active-active). Prima della configurazione, entrambi i dispositivi devono essere claimati, utilizzare lo stesso Build SFOS e avere tipi di licenza corrispondenti; tutte le interfacce richiedono indirizzi IP statici. Monitoraggio e troubleshooting devono coprire entrambi i nodi e il traffico rilevante deve beneficiare della distribuzione TCP descritta sopra.

Test dopo la configurazione

In Active-Active, è necessario testare più del semplice stato HA:

• Le connessioni vengono distribuite su entrambi i nodi?
• Le licenze di entrambi i nodi sono state sincronizzate individualmente con successo, registrando stato e orario separatamente?
• I log sono visibili su entrambi i dispositivi?
• Le connessioni VPN funzionano dopo un cambio di ruolo?
• Funzionano Web Protection, IPS, Application Control e le funzionalità di sicurezza rilevanti?
• Ci sono applicazioni che presentano problemi causati dal comportamento asimmetrico del cluster?
• I report e gli avvisi vengono generati come previsto?

Interactive mode

Interactive mode è utile quando la logica automatica di QuickHA non offre abbastanza controllo.

Prima della configurazione, consentire SSH e Ping/Ping6 per la zona DMZ su entrambi i dispositivi in Administration > Device access. Interactive mode seleziona inizialmente e in modo automatico la prima interfaccia DMZ come Dedicated HA link. Se questa interfaccia non è destinata a HA o ha dipendenze produttive, selezionare prima del salvataggio un’interfaccia fisica, VLAN o LAG preparata e libera.

Motivi tipici:

• si desidera utilizzare indirizzi IP HA-Link fissi
• il Peer Admin Port deve essere definito esattamente
• l’ID del cluster deve essere impostato consapevolmente
• esistono più cluster HA nello stesso ambiente Layer-2
• le appliance virtuali devono essere eseguite con opzioni MAC specifiche
• è necessario un rollout molto controllato

In Interactive mode si configura prima l’Auxiliary e poi il Primary. In questo modo il rilevamento del peer sul Primary non scade mentre il secondo nodo viene ancora preparato.

1. Configurare l’Auxiliary

1. Su FW02 passare a System services > High availability.
2. Selezionare Initial device role > Auxiliary e HA configuration mode > Interactive mode.
3. Definire il nome del nodo e una passphrase conforme alle regole indicate sopra.
4. Selezionare la porta DMZ libera per il Dedicated HA link. Il firewall elimina le configurazioni dipendenti esistenti di questa interfaccia.
5. Salvare e attendere la conferma che la configurazione dell’Auxiliary sia stata applicata.

2. Configurare il Primary

1. Su FW01 selezionare Primary (active-passive) oppure Primary (active-active) e Interactive mode.
2. Definire un Cluster ID univoco e il nome del nodo.
3. Inserire la passphrase di FW02.
4. Specificare lo stesso Dedicated HA link e l’indirizzo IP statico HA-Link dell’Auxiliary. Il campo si chiama Dedicated peer HA link IPv4 address in SFOS 22 e Peer IPv4 address of dedicated HA link nelle istruzioni dettagliate di SFOS 23. Entrambi gli indirizzi HA-Link devono trovarsi nella stessa subnet. Questo indirizzo non è l’IP di amministrazione del peer in Peer administration settings.
5. Selezionare le Monitored ports critiche; SFOS 23 ne consente al massimo 24.
6. In Peer administration settings, specificare l’interfaccia di management e l’indirizzo IP per FW02 solo dopo aver completato il preflight sul conflitto delle fonti descritto nei requisiti di rete, documentato anche i ruoli previsti per i nodi standalone e chiarito l’indirizzamento applicabile alla build installata. Se il conflitto resta irrisolto, fermarsi prima di modificare gli indirizzi o selezionare Initiate HA.
7. Se necessario, selezionare Use host or hypervisor-assigned MAC address per le appliance virtuali in SFOS 22, oppure Use interface MAC address in SFOS 23. L’opzione SFOS 23 usa il MAC dell’hypervisor sulle appliance virtuali e il MAC dell’interfaccia sull’hardware, anziché il MAC virtuale del cluster. Attivarla o disattivarla causa downtime.
8. Definire Preferred primary e selezionare Initiate HA.

Dopo la configurazione, modificare i valori di keepalive solo per un motivo documentato. SFOS 22 consente intervalli di 250–500 ms e 16–24 tentativi; i valori predefiniti di 250 ms e 16 tentativi danno un timeout di 4 secondi. SFOS 23 consente 100–500 ms e 3–24 tentativi; i valori predefiniti di 100 ms e 3 tentativi danno 300 ms. Per i Dedicated HA link di SFOS 23 con LAG o VLAN su LAG, il prodotto deve essere almeno 2500 ms: 250 ms × 10 tentativi è un esempio consentito, non il valore predefinito generale. Verificare anche i LAG ridondanti creati da QuickHA. Questi valori non possono essere modificati quando i dispositivi hanno stato Standalone o Faulty. Dopo il timeout, il nuovo Primary esegue controlli interni prima di iniziare a elaborare il traffico. Nessuno di questi timeout garantisce il tempo di ripristino del traffico.

Discrepanza nella documentazione API di SFOS 22: la descrizione di Keepalive attempts indica 8–16 tentativi, mentre il vincolo dettagliato del parametro e l’esempio XML indicano 16–24. Usare il vincolo dettagliato; non trattare 8–16 come un secondo intervallo supportato. Prima di apportare modifiche, documentare la build SFOS installata e i valori di keepalive attuali di entrambi i nodi. Se i limiti applicabili restano poco chiari, chiarirli con Sophos Support prima di una modifica; i requisiti LAG devono comunque essere rispettati.

Verifica preliminare dell’API per SFOS 22 e 23: le tabelle dei parametri documentano ClusterId come intero facoltativo nell’intervallo 0–63 con valore predefinito 0 e NodeName come stringa obbligatoria di 1–30 caratteri. Anche con il valore predefinito documentato, ogni cluster nella rete Layer 2 condivisa deve utilizzare una Cluster ID univoca per evitare conflitti tra MAC virtuali. Questi metadati API non modificano le indicazioni sulla GUI descritte sopra riguardo all’assegnazione facoltativa o obbligatoria dei nomi e non dimostrano alcuna validazione nella GUI. La tabella riporta ClusterId, mentre l’esempio XML riporta ClusterID; non considerarli alias intercambiabili senza chiarire il nome accettato nell’API help della build installata.

Nelle impostazioni HA avanzate di SFOS 23, Monitor hardware components è opzionale e aggiunge un trigger di failover quando viene rilevato un problema a un dispositivo di archiviazione, oltre ai guasti heartbeat e delle interfacce monitorate. Non presumere che sia attivo per impostazione predefinita o che rilevi tutti i guasti hardware.

Nota sull’API di SFOS 23: La tabella dei parametri API elenca HardwareMonitor come parametro scalare opzionale (SCALAR, Mandatory: No), con i valori Enable e Disable e il valore predefinito documentato per l’API Enable. Questo dato della documentazione non dimostra né l’impostazione effettiva nella GUI né lo stato del dispositivo in esecuzione. Verificare l’impostazione sul dispositivo installato; l’ambito limitato ai dispositivi di archiviazione descritto sopra resta invariato.

L’esempio XML dell’API di SFOS 23 contiene ancora Number(250-500) e Number(16-24). Questi segnaposto non corrispondono agli intervalli della tabella, 100–500 ms e 3–24 tentativi, e non devono essere copiati come limiti completi. Ciò non dimostra né che il prodotto rifiuti i valori inferiori né un comportamento testato dell’API.

Collegare un nuovo Auxiliary virtuale come HA spare

Per un nuovo Auxiliary virtuale in Active-Passive, il Setup Assistant può usare Connect as HA spare. Questa procedura è un’alternativa alla configurazione descritta sopra con due dispositivi già disponibili, in cui si prepara prima l’Auxiliary: la nuova VM spare non viene configurata preventivamente come Auxiliary. La configurazione automatica della porta di amministrazione non risolve le indicazioni discordanti sugli indirizzi descritte sopra. Active-Active o due firewall Virtual/Software già esistenti richiedono ancora QuickHA o Interactive mode su entrambi i dispositivi.

1. Sul Primary esistente, completare prima il preflight sugli indirizzi di amministrazione descritto nei requisiti di rete, documentando anche i ruoli previsti per i nodi standalone; se il conflitto delle fonti resta irrisolto, fermarsi prima di modificare gli indirizzi o selezionare Initiate HA. Consentire SSH per DMZ in Administration > Device access e selezionare Primary (active-passive) e Interactive mode in System services > High availability. In SFOS 23, prima di selezionare Initiate HA, inserire una Cluster ID e un nome del nodo; la guida per SFOS 22 descrive l’inserimento della Cluster ID e la modifica del nome del nodo come facoltativi. Se sono presenti più cluster HA nella stessa rete Layer 2, utilizzare una Cluster ID diversa per ogni cluster per evitare conflitti tra indirizzi MAC virtuali. Documentare in modo sicuro il Dedicated HA Link, il relativo indirizzo IP locale e la subnet mask, l’IP previsto del peer, Peer Administration e la passphrase HA utilizzata sul Primary. Quindi selezionare Initiate HA; in SFOS 23, tornare all’inizio della pagina per farlo. In questa fase, prima che la nuova VM si unisca al cluster, la guida Sophos per la spare documenta il messaggio HA could not be enabled e, temporaneamente, lo stato Standalone. In questa fase di configurazione, nessuno dei due indica di per sé il fallimento di un cluster già completato.
2. Installare il nuovo firewall virtuale con esattamente lo stesso build SFOS, avviare il Setup Assistant e impostare una nuova password amministratore.
3. Selezionare Connect as HA spare e inserire il numero di serie del Primary esistente, la stessa passphrase HA precedentemente utilizzata sul Primary e documentata in modo sicuro e la stessa interfaccia Dedicated HA Link. Per la nuova spare, utilizzare un indirizzo IP dedicato, libero e diverso da quello del Primary, nella subnet del Dedicated HA Link del Primary esistente e con la stessa subnet mask; deve corrispondere all’IP del peer predisposto sul Primary. Non presumere di dover usare una passphrase proveniente da un Auxiliary ritenuto già configurato.
4. Selezionare Apply, Continue e Finish. SFOS crea l’Auxiliary, assegna un numero di serie che inizia con HAAUX e configura automaticamente il Dedicated HA Link e la porta di amministrazione.
5. Dopo alcuni minuti, aggiornare WebAdmin dell’Auxiliary e accedere nuovamente. Verificare poi sul Primary ruoli, sincronizzazione, Peer Admin, Monitored Ports e failover.

Validare il cluster

Dopo la configurazione, il cluster HA dovrebbe essere verificato sistematicamente.

Verifica WebAdmin

1. Accedere al firewall primario.
2. Verificare lo stato HA in alto a destra.
3. Passare a System services > High availability.
4. Verificare ruoli, stato, numeri di serie e modalità.
5. Assicurarsi che il cluster sia sincronizzato.
6. In Active-Passive, verificare quale dispositivo detiene la licenza per il cluster.

Verifica CLI

Nella Device Console, il seguente comando read-only mostra ruoli, stato e sincronizzazione del cluster. Non modifica la configurazione:

system ha show details

Verificare i parametri operativi di SFOS 22

SFOS 22 pubblica due controlli HA aggiuntivi. Entrambi vanno letti prima di qualsiasi modifica:

system ha auxiliary_system_traffic_through_dedicated_link show
system ha load-balancing show

Il primo controllo determina il percorso del traffico di sistema inviato dallo stesso Auxiliary Firewall. Per impostazione predefinita, tutto questo traffico passa sul Dedicated HA Link. Oltre a all, sono disponibili none e only_dynamic_interface. Sophos non definisce con maggiore precisione quali flussi siano considerati un’interfaccia dinamica nell’ultima modalità. Questa opzione va quindi usata solo per un caso confermato sul build installato, non come correzione generale del routing.

Il secondo controllo attiva o disattiva la distribuzione del traffico idoneo tra i firewall. Non sostituisce la selezione della modalità HA e non rende idonei al load balancing i servizi e i tunnel esclusi sopra. Eseguire le modifiche singolarmente in una finestra di manutenzione e salvare prima entrambi gli output show:

system ha auxiliary_system_traffic_through_dedicated_link [all|none|only_dynamic_interface]
system ha load-balancing [on|off]

Verificare quindi ruoli, sincronizzazione, Dedicated HA Link, nuove sessioni, log locali dei nodi e connessioni di sistema avviate dallo stesso Auxiliary. Per il rollback, ripristinare il valore rilevato in precedenza. Sophos documenta all come valore predefinito solo per il primo controllo; non si presume un valore predefinito per il load balancing.

Il dispositivo che detiene la licenza come Initial Primary si verifica in System services > High availability. Sophos documenta inoltre il seguente controllo CLI ufficiale nella Advanced Shell:

nvram get "#li.master"

YES identifica l’Initial Primary che detiene le licenze del cluster; NO identifica il dispositivo configurato come Auxiliary. Il comando è read-only. La vista HA rimane più pratica per i controlli quotidiani, ma anche l’output della shell è documentato ufficialmente.

Se l’accesso alla shell non è ancora preparato, aiuta la guida Connettersi a Sophos Firewall tramite SSH.

Test funzionale

• Testare un client dalla LAN a Internet.
• Testare l’accesso ai server interni.
• Testare VPN.
• Testare scenari DNAT o WAF.
• Testare DNS e DHCP, se il firewall fornisce questi servizi.
• Verificare i log nel Log Viewer.
• Testare il cambio di ruolo HA in una finestra di manutenzione.
• Documentare quindi ruoli, stato e comportamento delle sessioni.

Operatività e manutenzione

Monitoraggio continuo

È necessario monitorare stato HA e ruoli, Dedicated HA link, Monitored Ports, licenze, firmware, CPU, RAM, disco e servizi centrali. Gli avvisi devono essere inoltrati a Sophos Fusion, via e-mail o al sistema di monitoring esistente.

Per i temi di disco e hardware, si dovrebbero considerare separatamente entrambi i nodi. I report locali, i file di log e lo stato SSD possono differire. Per approfondire, consultare gli articoli Verificare lo spazio di archiviazione di Sophos Firewall e gestire i report e Verificare la salute dell’SSD di Sophos Firewall tramite SMART.

Log e report

Ogni nodo scrive i log del traffico che elabora. In Active-Active è quindi necessario controllare entrambi i dispositivi. Per un’analisi comune sono adatti Sophos Fusion Firewall Reporting o Syslog. I file locali sono spiegati in Sophos Firewall Troubleshooting: Servizi e log.

L’Auxiliary invia email di report solo per i report che contengono dati su quel nodo, ad esempio attività email o Pattern Updates. Non invia report senza dati, come Security Dashboard o Security Audit. L’assenza di un’email per questi tipi di report non dimostra quindi, da sola, la presenza di un guasto.

In Active-Active, l’IP di origine fornisce un primo indizio sul nodo in cui ci si aspetta di trovare i log: per il traffico TCP idoneo, gli indirizzi pari corrispondono al Primary, quelli dispari all’Auxiliary. Questo non vale indistintamente per i tipi di traffico esclusi sopra e non sostituisce il confronto dei due dispositivi, soprattutto dopo un cambio di ruolo.

Per gli eventi HA, aprire Log viewer > System separatamente su ogni nodo. Tramite Add filter, selezionare il filtro e il valore appropriati per il periodo interessato e applicarli con il pulsante Add filter. Per un’analisi dettagliata, aprire Diagnostics > Tools > Troubleshooting logs > Select files su entrambi i dispositivi e selezionare csc.log per il servizio centrale che gestisce gli altri servizi. Selezionare inoltre i file HA descritti più avanti in Log importanti e percorsi diagnostici e salvare separatamente ogni pacchetto con Download. Per ricostruire la sequenza degli eventi del cluster, confrontare le registrazioni di entrambi i nodi, prestando attenzione a eventuali lacune temporali o log ruotati.

Runbook per l’operatività HA

Nel runbook operativo documentare almeno:

• Numero di serie, posizione, posizione nel rack e ruolo di entrambe le appliance.
• Dedicated HA link, Peer Admin Port, Cluster ID e porte monitorate.
• Preferred primary e comportamento previsto dopo il failover.
• Titolare della licenza, stato del supporto e contatto RMA.
• Procedura e responsabilità per aggiornamento firmware, backup, reimage, sostituzione hardware, log e casi di supporto.

Se solo il WebAdmin su un nodo è bloccato, non significa automaticamente che l’intero cluster HA sia difettoso. In tal caso, si dovrebbe verificare se un riavvio della GUI WebAdmin o un riavvio controllato del servizio è sufficiente prima di attivare un failover o un riavvio.

Modifiche al cluster

Modificare regole, interfacce e policy solo sul Primary. Prima di modificare interfacce, VLAN, LAG, zone, routing, NAT, VPN, Device Access o SD-WAN:

• Creare un backup.
• Definire una finestra di manutenzione.
• Verificare lo stato HA.
• Aggiornare la documentazione.
• Stabilire un percorso di rollback.
• Verificare quindi sincronizzazione e traffico.

Sincronizzazione manuale e cambio di ruolo forzato

La sincronizzazione automatica è il funzionamento normale. Utilizzare Sync auxiliary device sul Primary o sull’Auxiliary solo per risolvere un problema di sincronizzazione confermato. L’Auxiliary si riavvia, esegue una sincronizzazione completa del database e dei file correlati e rimane Auxiliary. Log e report restano locali su ciascun nodo. Durante il processo il firewall interrompe tutte le connessioni con masquerading, quindi l’operazione deve essere pianificata in una finestra di manutenzione.

In Active-Passive, è possibile forzare l’Auxiliary a subentrare con Switch to passive device sul Primary corrente o Switch to active device sull’Auxiliary corrente. Il Primary corrente si riavvia. È un cambio di ruolo pianificato con rischio per le sessioni, non un semplice interruttore.

Disattivare HA in modo controllato

Le FAQ Sophos su HA per SFOS 22 e 23 indicano come requisito generale di disattivare HA prima di un reimage, prima di sostituire un nodo nella coppia HA e prima di trasferire una licenza tra i nodi. La passphrase monouso per il tunnel SSH viene eliminata dopo la creazione del tunnel; per un nuovo dispositivo, HA deve quindi essere disattivato e riconfigurato. Questo requisito non sostituisce la pianificazione specifica del caso: le istruzioni dettagliate sul reimage riportate di seguito presentano una discrepanza nella documentazione e le procedure RMA presuppongono che un nodo sano operi già nello stato Standalone HA. Pianificare prima backup, accesso amministrativo garantito, finestra di manutenzione e ricostruzione del cluster; per la correzione delle licenze Active-Passive, rispettare anche la condizione relativa ai numeri di serie e ai ruoli descritta sopra.

Quando possibile, disattivare HA sul Primary corrente in System services > High availability > Disable HA. Il nodo utilizzato determina il risultato:

Accesso tramite Fusion da SFOS 22 MR1: I Sophos Known Issues, NC-186855, descrivono un’eccezione al comportamento generale indicato sopra: disattivando HA nell’interfaccia del firewall aperta tramite Sophos Fusion/Central con FRP-SSO, l’Auxiliary può rimanere standalone con HA attivo, mentre sul Primary HA è già disattivato. Esiste quindi un rischio di split brain. Dopo l’operazione, verificare separatamente lo stato HA su entrambi i dispositivi. Se gli stati non sono coerenti, interrompere la ricostruzione pianificata e coordinare il ripristino con Sophos Support prima di rimettere in funzione i dispositivi come coppia. Il completamento della finestra di dialogo sul Primary non è un controllo sufficiente. Al 24 ottobre 2026, la voce non indica una versione corretta.

Aggiornamenti firmware e backup

Aggiornamenti firmware in ambienti HA

Gli aggiornamenti firmware vengono avviati sul firewall primario. I dispositivi vengono aggiornati uno alla volta e il cluster può cambiare ruolo durante il processo.

Procedura tipica:

1. Avviare l’aggiornamento sul firewall primario.
2. Il firewall ausiliario viene aggiornato.
3. Il firewall ausiliario si riavvia e assume temporaneamente il controllo.
4. Il precedente primario viene aggiornato.
5. Il precedente primario si riavvia.
6. Se Preferred primary è attivo, può avvenire un ritorno al dispositivo preferito.

Gli aggiornamenti firmware devono comunque essere eseguiti in una finestra di manutenzione. Anche se il processo è progettato per minimizzare i tempi di inattività, alcune sessioni, connessioni VPN o applicazioni speciali possono subire brevi interruzioni o richiedere una riconnessione.

Il rollback del firmware della coppia HA segue lo stesso processo e non richiede la disattivazione preventiva di HA.

Per la preparazione, consultare Aggiornamento firmware di Sophos Firewall - Preparazione e best practice.

Aggiornamenti pattern

Gli aggiornamenti pattern vengono installati sul Primary e sincronizzati automaticamente sull’Auxiliary. Questo vale anche per ambienti in cui gli aggiornamenti vengono controllati o installati offline.

Se un cluster HA viene eseguito in un ambiente isolato, prima di ogni aggiornamento pattern o licenza manuale, dovrebbe essere chiaro quale nodo è l’Initial Primary e quale nodo è attualmente primario. La procedura Air-Gap è descritta in Gestire la licenza Air-Gap e gli aggiornamenti pattern di Sophos Firewall.

Backup e ripristino

Creare backup regolarmente e prima di ogni modifica importante. Se LINCE è attivo, il backup e il cluster di destinazione devono avere lo stesso stato LINCE. Esistono tre casi di ripristino:

Active-Active e Bridge-VLAN: Ogni nodo scrive i propri log. In SFOS 22 Active-Active, solo il Primary elabora il traffico ricevuto sulle interfacce VLAN configurate sulle Bridge Interfaces. Le descrizioni di configurazione e interfacce di SFOS 23 omettono questa restrizione, ma l’omissione non conferma il bilanciamento del carico. Finché Sophos Support non conferma il comportamento per la build SFOS 23 e la topologia in uso, pianificare prudentemente questo traffico solo sul Primary e non contare sulla distribuzione per dimensionare la capacità.

Accesso alla quarantena: Ogni nodo memorizza la propria quarantena e invia il proprio Quarantine Digest. Gli amministratori rilasciano un’email sul nodo che l’ha elaborata. Gli utenti rilasciano le email in quarantena tramite il User Portal. Il User Portal mostra solo le email in quarantena sul Primary corrente.

Attenzione con un backup senza HA: Le descrizioni Sophos per SFOS 22 e 23 si contraddicono sullo stato dell’Auxiliary dopo questo ripristino: il testo indica che conserva la configurazione precedente, mentre il riepilogo indica un ripristino alle impostazioni di fabbrica, esclusi il Peer Admin Port e il Dedicated HA Link. Né la conservazione completa né il ripristino di fabbrica sono quindi comportamenti accertati. Non fare affidamento sulla conservazione della configurazione dell’Auxiliary. Prima salvare le configurazioni esternamente, documentare gli indirizzi IP di amministrazione e le credenziali e pianificare il downtime e la ricostruzione di HA. Prima di dipendere dallo stato incerto dell’Auxiliary, chiarire la procedura per il build SFOS installato con Sophos Support.

Se il Primary era registrato come gateway Sophos ZTNA, aggiungerlo nuovamente come gateway in Sophos ZTNA dopo il ripristino sul cluster HA.

Reimage dei nodi HA in Active-Passive

Un reimage interrompe l’operatività e, secondo Sophos, si applica solo ad Active-Passive. Eseguire prima system diagnostics show version-info nella Device Console di entrambi i nodi, documentare firmware, build e Initial Primary e salvare esternamente un backup aggiornato.

Ambito di applicazione delle procedure seguenti: all’inizio, FW1 è sia il Primary corrente sia l’Initial Primary titolare delle licenze; FW2 è l’Auxiliary corrente. Questi nomi identificano gli stessi dispositivi fisici per tutta la procedura, anche dopo un cambio di ruolo. L’obiettivo è ripristinare FW1 come Primary e FW2 come Auxiliary. Se il Primary corrente e l’Initial Primary sono dispositivi diversi, non improvvisare seguendo queste procedure: prima identificare ruoli e titolare delle licenze sulla base delle istruzioni Sophos applicabili o con Sophos Support.

Chiarire la discrepanza nella documentazione prima del reimage: le FAQ su HA per SFOS 22 e 23 richiedono in generale di disattivare HA prima del reimage. Le istruzioni dettagliate Active-Passive descrivono invece, per il reimage del Primary e di entrambi i nodi, un cambio di ruolo con Switch to passive device seguito dalla reinstallazione, senza indicare un passaggio separato Disable HA. Il cambio di ruolo non equivale alla disattivazione di HA; l’omissione non dimostra un’eccezione sicura in generale. Le sequenze dettagliate seguenti vengono quindi mantenute come procedure documentate, ma contraddittorie su questo punto. Prima di eseguirle, definire con certezza ruoli, Initial Primary, build installato, backup, downtime e percorso di rollback e, se è necessario ricorrere a questa sequenza divergente, chiarire l’ordine applicabile con Sophos Support. Se l’ordine non è stato chiarito, fermarsi prima del cambio di ruolo o della reinstallazione; non inserire autonomamente un passaggio di disattivazione nella sequenza.

Se FW1 è registrato per Central Management, deregistrarlo prima di ciascuna delle tre procedure. Quindi, nello stesso tenant Sophos Central/Fusion, verificare in My Products > Firewall Management > Firewalls che la voce di FW1 non sia più presente. Solo dopo procedere con il backup, la disattivazione di HA o il cambio di ruolo. Questo controllo si applica a Firewall Management registrato, non solo a Synchronized Security.

Reinstallare solo l’Auxiliary FW2

1. Dopo la deregistrazione e il controllo descritti sopra, salvare esternamente il backup di FW1 e disattivare HA su FW1, mai su FW2.
2. Nella Advanced Shell di FW1, usare service -S | grep msync per verificare che msync mostri lo stato UNTOUCHED o STOPPED. In caso contrario, non proseguire.
3. Reinstallare FW2 con esattamente la stessa versione firmware, incluso il build, di FW1. Accedere localmente e configurare esclusivamente la WAN per Internet, senza configurare interfacce LAN o DMZ. Quindi effettuare il claiming di FW2, se non è già stato effettuato.
4. Ricostruire HA con FW1 come Primary e FW2 come Auxiliary.

Reinstallare solo il Primary FW1

1. Dopo la deregistrazione e il controllo, salvare esternamente il backup di FW1 e usare Switch to passive device per far subentrare FW2. Le identità dei dispositivi rimangono invariate.
2. Reinstallare FW1 con esattamente la stessa versione firmware, incluso il build, di FW2. Accedere localmente, configurare solo la WAN per Internet, senza configurare interfacce LAN o DMZ, ed effettuare il claiming di FW1, se non è già stato effettuato.
3. Per il ripristino, scollegare tutti i cavi da FW1 tranne quello del PC di amministrazione, ripristinare il backup, ricollegare i cavi e riportare il traffico da FW2 a FW1.
4. Ripristinare quindi FW2 alle impostazioni di fabbrica. Accedere localmente, configurare esclusivamente la WAN per Internet, senza configurare interfacce LAN o DMZ, ed effettuare il claiming, se non è già stato effettuato.
5. Ricostruire HA con FW1 come Primary e FW2 come Auxiliary.

Reinstallare e aggiornare entrambi i nodi

1. Eseguire deregistrazione, controllo, backup e cambio di ruolo come per il reimage del Primary. Portare però FW1 alla versione di destinazione, incluso il build di destinazione. Quindi accedere localmente, configurare solo la WAN per Internet, senza configurare interfacce LAN o DMZ, ed effettuare il claiming, se non è già stato effettuato.
2. Per il ripristino, scollegare tutti i cavi da FW1 tranne quello del PC di amministrazione, ripristinare il backup su questo dispositivo, ricollegare i cavi e riportare il traffico da FW2 a FW1.
3. Diversamente dal solo reimage del Primary, ora non limitarsi a ripristinare FW2 alle impostazioni di fabbrica, ma reinstallarlo con esattamente la stessa versione di destinazione, incluso il build, di FW1. Accedere localmente, configurare esclusivamente la WAN per Internet, senza configurare interfacce LAN o DMZ, ed effettuare il claiming, se non è già stato effettuato.
4. Ricostruire il cluster Active-Passive con FW1 come Primary e FW2 come Auxiliary. L’interruzione pianificata comprende anche questa seconda fase di reinstallazione e adesione al cluster.

Se il cluster utilizza Sophos Fusion Synchronized Security, la coppia HA deve essere rimossa dalla gestione Central prima di restituire il dispositivo tramite il processo RMA. Dopo la sostituzione, il nuovo cluster HA viene registrato nuovamente in Central. Questo evita conflitti nella sincronizzazione di numeri di serie e licenze con il vecchio dispositivo ancora registrato.

Sostituzione dell’Auxiliary dopo RMA

La sostituzione o il reimage di un nodo causa un’interruzione pianificata. Le procedure seguenti valgono per Active-Passive; per Active-Active, il processo concreto deve essere pianificato con Sophos Support. Entrambe le varianti RMA dettagliate presuppongono che il nodo sano rimanente operi già come Standalone HA: il Primary sano per l’RMA dell’Auxiliary, l’Auxiliary sano per l’RMA del Primary. Solo per questo stato iniziale le fonti descrivono il claiming e il trasferimento della licenza del dispositivo sostitutivo prima della successiva disattivazione di HA o del ripristino del nodo sano. Non applicare questo ordine alla sostituzione in una coppia HA ancora funzionante; in quel caso vale il requisito generale delle FAQ di disattivare prima HA. Se lo stato iniziale non corrisponde o non è chiaro, fermarsi prima della sostituzione o del trasferimento della licenza e pianificare la procedura con Sophos Support.

1. Verificare modello e revisione hardware del dispositivo sostitutivo e installare esattamente lo stesso Build firmware del Primary sano.
2. Sul dispositivo sostitutivo, preparare prima l’accesso locale. Nell’esempio documentato di disposizione delle porte, collegare un PC di amministrazione in grado di utilizzare DHCP alla porta 1 e aprire https://172.16.16.16:4444; collegare la WAN alla porta 2 e configurarla per Internet nel Setup Assistant. Se la disposizione delle porte è diversa, utilizzare le porte di amministrazione e WAN previste per il modello del dispositivo. Non configurare altre interfacce. Solo dopo effettuare il claiming del dispositivo sostitutivo in Sophos Fusion e trasferire la licenza del dispositivo Auxiliary guasto.
3. Spostare i cavi dal dispositivo guasto a quello sostitutivo.
4. Sul Primary sano, disattivare HA in System services > High availability.
5. Nella Advanced Shell, verificare che msync sia terminato:

service -S | grep msync

Il risultato previsto è UNTOUCHED o STOPPED. Il comando non modifica nulla; uno stato diverso indica che HA non deve ancora essere ricostruito. Configurare quindi il Primary sano come Primary e il dispositivo sostitutivo come Auxiliary.

Sostituzione del Primary dopo RMA

1. Scaricare un backup aggiornato dall’Auxiliary sano e deregistrare il dispositivo da Sophos Fusion. Prima di proseguire, verificare nello stesso tenant Sophos Central/Fusion, in My Products > Firewall Management > Firewalls, che la voce di questo Auxiliary sano non sia più presente.
2. Portare il dispositivo sostitutivo allo stesso build firmware e accedere localmente. Nell’esempio documentato di disposizione delle porte, collegare un PC di amministrazione in grado di utilizzare DHCP alla porta 1 e aprire https://172.16.16.16:4444; configurare la WAN sulla porta 2 per Internet nel Setup Assistant. Se la disposizione delle porte è diversa, utilizzare le porte di amministrazione e WAN previste per il modello del dispositivo. Non configurare altre interfacce. Solo dopo effettuare il claiming in Sophos Fusion e trasferire la licenza del Primary guasto.
3. Ripristinare il backup sul dispositivo sostitutivo.
4. Spostare i cavi dell’Auxiliary sano sul dispositivo sostitutivo. Da questo momento, il dispositivo sostitutivo elabora il traffico come firewall autonomo.
5. Ripristinare il precedente Auxiliary alle impostazioni di fabbrica e preparare nuovamente l’accesso locale: nell’esempio documentato di disposizione delle porte, collegare un PC di amministrazione in grado di utilizzare DHCP alla porta 1 e aprire https://172.16.16.16:4444, quindi configurare la WAN sulla porta 2 per Internet nel Setup Assistant. Se la disposizione delle porte è diversa, utilizzare le porte di amministrazione e WAN previste per il modello del dispositivo. Non configurare altre interfacce. Solo dopo effettuare nuovamente il claiming in Sophos Fusion e collegare i cavi previsti.
6. Ricostruire HA con il dispositivo sostitutivo come Primary e il dispositivo ripristinato come Auxiliary.

Attenzione: backup/restore, Factory Reset e spostamento dei cavi causano downtime. Numeri di serie, Initial Primary, Build firmware, trasferimento licenze, stato Central e percorso di rollback devono essere documentati prima di iniziare.

Per la nuova installazione tecnica, consultare Reinstallare Sophos Firewall OS: Reimage con chiavetta USB. Se è presente un guasto hardware o un processo RMA, dovrebbe essere pianificato anche Preparare correttamente un guasto hardware e RMA di Sophos.

Risoluzione dei problemi

In caso di problemi complessi, procedere in modo strutturato: prima verificare stato, HA-Link, porte monitorate, versione firmware e stato della licenza, poi considerare casi speciali o indicazioni del produttore. In questo modo, rimane chiaro se esiste un vero problema HA o se licenza, interfaccia, versione firmware o monitoraggio causano l’errore.

Log importanti e percorsi diagnostici

• Stato HA:System services > High availability.
• Event Logs:Log viewer > System.
• Troubleshooting Logs:Diagnostics > Tools > Troubleshooting logs > Select files o tramite SSH sotto /log.
• Dettagli HA CLI: vedere l’unica verifica CLI descritta in Validare il cluster.
• Problemi di interfaccia: show network interfaces, ifconfig, dmesg in casi di diagnosi appropriati.
• Titolare della licenza:System services > High availability.

Per una prima analisi, questi file sono particolarmente utili:

• ha.log: errori di configurazione, configurazione HA riuscita e cambi di stato.
• ha_pair.log: rilevamento del peer in QuickHA.
• ha_tunnel.log: tunnel SSH sul Dedicated HA link.
• msync.log: sincronizzazione della configurazione HA.
• ctsyncd.log: sincronizzazione delle sessioni Conntrack.
• filesync.log: sincronizzazione di file specifici dei servizi, per esempio per route dinamiche o DHCP.

Ogni nodo conserva solo log e report del traffico che elabora. Per l’Auxiliary, accedere tramite il relativo indirizzo Peer Admin oppure consultare i file di log via SSH su quel nodo.

Per analisi più approfondite, spesso aiuta l’articolo Sophos Firewall CLI Troubleshooting: comandi importanti.

Errori HA tipici

• Il cluster non si forma, versione firmware o build diversa: verificare la versione su entrambi i dispositivi e portarli alla stessa versione SFOS.

• Il cluster non si forma, modello o appliance non compatibile: verificare modello e numero di serie. Per hardware HA usare solo modelli XGS Appliance compatibili e uguali.

• HA could not be enabled: solo per la configurazione descritta sopra con una nuova HA spare virtuale, Sophos documenta questo messaggio sul Primary subito dopo Initiate HA, prima che la spare si unisca al cluster; in quel contesto è descritto anche lo stato temporaneo Standalone. Ciò non significa che il messaggio possa essere ignorato in generale. Se persiste dopo il completamento dell’assistente della spare e della fase di attesa e aggiornamento, oppure compare in un’altra configurazione, il Dedicated HA link potrebbe non essere connesso o il peer non raggiungibile. Assicurarsi che le interfacce HA-Link dedicate dei due dispositivi siano collegate direttamente tramite un cavo Ethernet o attraverso lo switch previsto. Su entrambi i nodi, verificare in Network > Interfaces che l’interfaccia HA-Link selezionata mostri Connected. Sul Primary, usare lo strumento ping in Diagnostics > Tools per verificare l’IP HA-Link dedicato dell’Auxiliary, non il suo indirizzo Peer Admin. Le risposte dimostrano la raggiungibilità di base, ma non ancora il completamento della sincronizzazione HA. In assenza di risposte, verificare e correggere prima il cablaggio, il percorso attraverso lo switch, lo stato del link e l’IP/subnet dell’HA-Link; quindi ripetere il ping e ricontrollare ruoli e sincronizzazione.

• HA-Link down: cavo, porta switch, VLAN o LAG possono essere difettosi. Verificare stato interfaccia, speed/duplex, trunk VLAN e membri LAG.

• Entrambi i dispositivi diventano Standalone: HA-Link guasto, rischio di split-brain. Verificare connessione fisica HA-Link e percorso switch, spegnere un dispositivo in modo controllato, riparare HA-Link e poi riavviare.

• Auxiliary WebAdmin non raggiungibile: Peer Admin Port, subnet, route o Device Access non combaciano. Verificare IP dell’admin port e accesso dalla rete di management.

• Validation Failed For Ha interface IP: Cercare questo messaggio esatto in /log/syslog.log sul Primary. Sophos lo associa a porte di amministrazione che non si trovano nella stessa subnet; confrontare gli indirizzi delle porte di amministrazione dei due dispositivi. Verificare inoltre, come requisito separato, che gli indirizzi HA-Link si trovino nella stessa subnet, senza considerarli una causa accertata di questo messaggio. Prima di correggere l’indirizzamento di management, completare il preflight descritto sopra per chiarire il conflitto tra le fonti: documentare ruoli, build SFOS installata, interfaccia di amministrazione e IP attuali, salvare un backup in modo sicuro, garantire un accesso amministrativo separato tramite console o accesso locale e verificare il comportamento di indirizzamento applicabile oppure chiarirlo con Sophos Support. Se il comportamento resta irrisolto, fermarsi prima di modificare gli indirizzi.

• Failover avviene inaspettatamente: spesso una Monitored Port è guasta o scelta male. Verificare Monitored Ports e stato switch e monitorare solo porte critiche e stabili. Se il nodo interessato si è effettivamente riavviato e non ha soltanto cambiato ruolo, verificare il riavvio inatteso in modo specifico per quel nodo.

• Failover non avviene: probabilmente la porta rilevante non è monitorata. Inserire porte WAN, core o DMZ critiche come Monitored Ports.

• Active-Active non distribuisce come previsto: il tipo di traffico potrebbe non essere load-balanced. Verificare tipo di connessione, protocollo e log di entrambi i nodi; se il vantaggio non è chiaro, usare Active-Passive o adattare il design.

• Log apparentemente mancanti: il traffico potrebbe essere stato gestito dall’altro nodo o il logging non essere attivo. Verificare su entrambi i nodi e nel Log Viewer, attivare logging nelle regole e usare Central Reporting o Syslog.

• Report diversi: i report locali sono specifici per nodo. Confrontare i report dei due dispositivi o usare Sophos Fusion Firewall Reporting.

• Problema di licenza in Active-Active: i tipi di licenza potrebbero non coincidere. Verificare Licensing su entrambi i firewall e allineare le licenze.

• Problemi dopo firmware update: un nodo non è stato aggiornato correttamente o il cluster non è sincronizzato. Verificare stato HA, versioni firmware e log; nei cluster produttivi usare una finestra di manutenzione e coinvolgere Sophos Support.

• L’HA-Link Flexi Port non funziona dopo un aggiornamento: sui modelli 1U XGS 2100, XGS 2300, XGS 3100, XGS 3300, XGS 4300 e XGS 4500, HA potrebbe non stabilirsi se si usa un Flexi Port come Dedicated HA link. Dopo l’aggiornamento e il riavvio del primo dispositivo, il suo Interface speed non è più impostato su Auto negotiation, mentre il secondo continua a usare Auto negotiation.

  Prima di modificare l’impostazione: documentare i ruoli HA e le impostazioni delle porte di entrambi i dispositivi, assicurarsi di avere un backup e un accesso amministrativo separato e usare una finestra di manutenzione. In caso di split-brain, seguire prima la procedura per il guasto dell’HA-Link riportata sotto: decidere quale nodo deve rimanere attivo e scollegare l’altro dalla rete di produzione o spegnerlo in modo controllato. Non riavviare entrambi i nodi senza coordinamento.

  1. Su entrambi i dispositivi, aprire Network > Interfaces.
  2. Selezionare l’interfaccia Flexi Port interessata e aprire Advanced settings.
  3. Impostare Interface speed su Auto negotiation.

  Verificare poi stato del link, ruoli HA, sincronizzazione e traffico di produzione. Se il problema persiste, salvare impostazioni e log di entrambi i nodi e coinvolgere Sophos Support. Ripristinare i valori precedenti documentati solo con una modifica controllata e un accesso amministrativo garantito; il ripristino può far ricomparire il guasto dell’HA-Link. In alternativa, pianificare l’uso di una porta integrata come Dedicated HA link, non di un valore di velocità fisso.

WebAdmin e VPN Portal non raggiungibili durante la sincronizzazione dei certificati

Le note di rilascio di SFOS 22.0 MR3 Build 576 del 16 ottobre 2026 indicano NC-186809 come corretto: sul nodo Auxiliary, la sincronizzazione dei certificati poteva fallire quando determinati nomi di file dei certificati iniziavano con due punti consecutivi (..), rendendo WebAdmin e VPN Portal non raggiungibili. Distinguere questi sintomi dai problemi generali di routing o Device Access e salvare build, nodo interessato, ora e log di sincronizzazione disponibili. Non rinominare né eliminare certificati sulla base di un sospetto. Se il sospetto è fondato, coinvolgere il supporto e pianificare un cambio di firmware supportato con accesso di gestione garantito; quindi verificare nuovamente entrambi i portali e la sincronizzazione HA.

Procedura in caso di guasto HA-Link

Se l’HA-Link dedicato si guasta, è necessaria cautela. Entrambi i firewall potrebbero non vedersi più. Nel caso peggiore, entrambi i dispositivi inviano ARP/GARP e tentano di usare l’indirizzo MAC del cluster.

Procedura sicura:

1. Stabilizzare lo stato della rete.
2. Decidere quale dispositivo dovrebbe rimanere attivo.
3. Spegnere l’altro dispositivo in modo controllato o scollegarlo dalla rete di produzione.
4. Riparare cavo HA-Link, porta switch, VLAN o LAG.
5. Riavviare il dispositivo.
6. Verificare lo stato HA.
7. Controllare log e ruoli.

Altri comandi CLI

Oltre alla verifica dello stato HA in Validare il cluster, il seguente comando in sola lettura nella Device Console mostra lo stato delle interfacce e dei link:

show network interfaces

Per il Dedicated HA link e le Monitored Ports collegate sono previsti stati UP.

Nello stesso output di show network interfaces, individuare l’interfaccia fisica interessata tramite il suo nome effettivo e verificare, oltre allo stato del link, i contatori disponibili per perdite di pacchetti (Drops), errori e collisioni. Non tutte le build mostrano tutti i contatori; un dato assente non equivale a un valore zero. Salvare l’output insieme a nodo, interfaccia e timestamp e confrontarlo con un’osservazione successiva: contatori in aumento aiutano a circoscrivere problemi di interfaccia, cavo o negoziazione, ma da soli non dimostrano una causa specifica. Eseguire la sostituzione del cavo o la correzione di Speed/Duplex solo in modo controllato, con un accesso amministrativo garantito e le precauzioni HA/split-brain descritte sopra; quindi confrontare nuovamente contatori, stato del link, ruoli e sincronizzazione. Questi contatori di interfaccia vanno distinti dai pacchetti scartati dalle regole firewall e dal relativo Drop Capture.

Per i link flap, passare alla shell tramite Device Management > Advanced Shell e sostituire PortE con il nome reale dell’interfaccia:

dmesg | grep PortE

L’output filtra i messaggi del kernel per questa interfaccia. Ripetuti messaggi link-up/link-down indicano problemi di cavo, transceiver, porta o negoziazione. Il comando non modifica nulla; dmesg contiene però solo il buffer kernel corrente e non sostituisce un’analisi dei log a lungo termine.

La verifica fisica completa con ethtool, dati del modulo e casi speciali noti è descritta in Scegliere e verificare SFP e SFP+ su Sophos Firewall.

Prima di ogni intervento approfondito, salvare output e timestamp. Confrontare i comandi con la guida della build installata prima dell’uso.

Checklist per il go-live

• Scelta motivata tra Active-Passive e Active-Active.
• Modelli, Flexi Ports, Build SFOS, stato LINCE, claiming e licenze verificati.
• Backup e percorso di rollback disponibili.
• Dedicated HA link libero, stabile e possibilmente collegato direttamente.
• VLAN, LAG, porte switch e RSTP coerenti su entrambi i lati.
• Accesso Peer Admin all’Auxiliary testato.
• Selezionate come Monitored Ports solo interfacce stabili e critiche.
• Cluster ID, Initial Primary, Preferred primary e numeri di serie documentati.
• WebAdmin, stato CLI e log rilevanti verificati.
• LAN, Internet, server, VPN, DNAT/WAF, DNS e DHCP testati funzionalmente.
• Failover e ritorno testati in una finestra di manutenzione.
• Monitoring e procedure firmware, restore e RMA documentati nel runbook.

FAQ