Configurazione e risoluzione dei problemi di Sophos SD-RED

Con un Sophos SD-RED è possibile collegare sedi remote, filiali o piccoli uffici domestici a un Sophos Firewall. Il RED crea un tunnel crittografato verso il firewall e fornisce una rete nella sede remota che viene gestita centralmente tramite il firewall.

Il vantaggio pratico: in loco non è necessaria una configurazione VPN complessa. L’SD-RED si collega a Internet, scarica la sua configurazione tramite il Sophos RED Provisioning Service e quindi stabilisce il tunnel verso il Sophos Firewall. Tuttavia, il solo tunnel non risolve tutto. Anche zone, regole del firewall, DHCP, VLAN, routing, DNS e versione del firmware devono essere corretti.

La modalità operativa deve essere definita prima della configurazione vera e propria. Determina DHCP, gateway, percorso internet, controllo centrale e comportamento durante un’interruzione del tunnel. Scegliere la modalità operativa corretta di Sophos RED spiega le differenze e i criteri decisionali.

Pianificazione e prerequisiti

Classificazione: SD-RED e RED tra firewall

RED comprende due casi d’uso attuali che devono rimanere separati. Questo articolo tratta una SD-RED 20 o SD-RED 60 fisica in una filiale. SFOS 22 continua inoltre a supportare un tunnel Site-to-Site RED tra due Sophos Firewall, con una firewall che opera come Firewall RED server e l’altra come Firewall RED client.

Il secondo caso non richiede hardware RED. Configurare Site-to-Site RED tra due Sophos Firewall spiega il file di provisioning, le route statiche senza interfaccia selezionata, le regole su entrambi i lati e il servizio RED. Le modalità operative SD-RED non si applicano a questa architettura.

Prerequisiti presso la sede principale

Prima di collegare il RED, questi punti devono essere chiari sul Sophos Firewall:

• Il servizio RED è attivato sul firewall.
• L’indirizzo IP pubblico o il nome DNS/DynDNS del firewall è raggiungibile.
• Le connessioni RED al firewall sono consentite sul lato WAN.
• RED è consentito sotto Administration > Device access per la zona WAN appropriata o è specificamente consentito tramite Local Service ACL.
• Interfaccia RED, zona e configurazione IP sono pianificate.
• Le regole del firewall dalla rete RED alle reti di destinazione sono previste.
• DHCP, DHCP Relay o indirizzamento statico per i client dietro il RED è chiarito.
• Il pattern del firmware RED sul firewall è aggiornato.
• Backup e versione del firmware del firewall sono documentati prima di apportare modifiche significative.

Per la comunicazione RED, sono particolarmente rilevanti TCP 3400, UDP 3410 e NTP 123. Queste connessioni non devono essere bloccate da router del provider, firewall preposti o gateway di sicurezza.

Prerequisiti presso la sede remota

Nella sede remota, l’SD-RED necessita di una connessione Internet pulita. Non è solo la larghezza di banda a essere decisiva, ma soprattutto la stabilità, la latenza, la perdita di pacchetti e se il provider consente le connessioni necessarie.

Si dovrebbe verificare:

• La connessione Internet è stabile.
• La porta WAN del RED riceve un indirizzo tramite DHCP o ha una configurazione statica corretta.
• Il gateway predefinito è raggiungibile.
• Il DNS funziona.
• NTP è raggiungibile.
• TCP 3400, UDP 3410 e NTP 123 non sono bloccati.
• Il router del provider o il firewall preposto non effettua un filtraggio inaspettato.
• Per le VLAN, è chiaro quale porta è taggata, non taggata o ibrida.

Per le sedi semplici, spesso è sufficiente una piccola connessione. Nella pratica, tuttavia, la perdita di pacchetti, router consumer instabili, CGNAT, problemi DNS o firewall del provider restrittivi sono più spesso la causa rispetto alla pura larghezza di banda.

Provisioning e messa in servizio

Eseguire automaticamente il provisioning tramite Sophos Provisioning Service

Per il normale provisioning online, la firewall e il SD-RED devono avere accesso a internet. Al primo avvio il SD-RED deve ottenere un indirizzo WAN tramite DHCP per poter scaricare la configurazione. Sulla firewall si attiva il servizio di provisioning RED in System services > RED, si inseriscono le informazioni di contatto e si accettano le condizioni d’uso di Sophos.

Si crea quindi un’interfaccia in Network > Interfaces > Add interface > Add RED. Si configurano Branch name, tipo di dispositivo, Automatically via provisioning service, indirizzo della firewall, uplink, modalità operativa, rete RED, zona e DHCP per la sede. Per un RED usato per la prima volta, Unlock code rimane vuoto. Dopo il salvataggio, la firewall carica la configurazione nel servizio di provisioning. Il SD-RED la recupera, apre il canale di controllo su TCP 3400 e poi stabilisce il tunnel Layer 2 su UDP 3410.

Al primo salvataggio il servizio di provisioning genera un codice di sblocco specifico del dispositivo. Il codice appare in WebAdmin e viene inviato all’indirizzo e-mail configurato in System services > RED. Va conservato in modo sicuro perché è necessario quando si sposta il RED su un’altra firewall. WebAdmin lo mostra nuovamente quando si elimina l’interfaccia. Se non è disponibile, occorre contattare Sophos Support.

Impostare consapevolmente le protezioni RED globali

Durante l’attivazione iniziale in System services > RED, SFOS crea un certificato per la comunicazione RED dai campi Organization name, City, Country ed Email. Organization name e City non devono quindi contenere dieresi o caratteri speciali. L’indirizzo e-mail deve restare raggiungibile, perché Sophos vi invia i nuovi codici di sblocco.

Per gli attuali SD-RED 20 e 60, TLS v1.2 (strict) and later è il punto di partenza consigliato. Questa selezione utilizza solo le cifrature TLS 1.2 raccomandate da Sophos. TLS v1.2 and later include anche cifrature non raccomandate da Sophos e non deve essere selezionato senza una comprovata esigenza di compatibilità. Dopo la modifica, tutti i tunnel RED di produzione vanno riconnessi e testati in modo controllato.

Automatic device deauthorization impedisce che un RED scollegato per molto tempo rimanga autorizzato indefinitamente. Il periodo deve adattarsi al processo aziendale di gestione degli incidenti e sostituzione: alla scadenza il dispositivo non viene eliminato, ma l’interfaccia RED deve essere riattivata esplicitamente in Network > Interfaces. Monitoraggio e documentazione del codice di sblocco fanno quindi parte di questa protezione.

Per SD-RED 20 e 60, RED unified firmware rimane attivo. Un nuovo pattern del firmware RED viene installato consapevolmente in Backup & firmware > Pattern updates e non viene applicato automaticamente. Occorre pianificare una finestra di manutenzione e poi verificare il tunnel e un client.

Collegare l’SD-RED

Procedura tipica:

1. Collegare la porta WAN del SD-RED al router del provider o al modem.
2. Collegare la porta LAN a un client di test, uno switch o una rete locale.
3. Alimentare l’SD-RED.
4. Attendere che il RED si avvii, verifichi il gateway e Internet, carichi la configurazione e stabilisca il tunnel.
5. Verificare sul Sophos Firewall se l’interfaccia RED è attiva.
6. Collegare un client di test dietro il RED e verificare IP, DNS, gateway e accesso alla destinazione.

Se tutti i LED rilevanti sono verdi, il tunnel tecnico è attivo. Successivamente inizia la vera verifica della rete: zona, DHCP, regole del firewall, routing inverso, DNS e, se necessario, VLAN.

Provisioning manuale con chiavetta USB

Normalmente un SD-RED viene fornito tramite Sophos RED Provisioning Service. Il provisioning manuale tramite chiavetta USB è utile quando il dispositivo si trova in una rete privata o fortemente limitata, richiede una configurazione WAN statica oppure il percorso di provisioning automatico non è affidabile.

Il flusso è più preciso del semplice copiare un file di provisioning su USB:

1. Sulla firewall, aprire Administration > Time, selezionare Use custom NTP server e aggiungere l’indirizzo IP della firewall come server NTP. Nel setup manuale, il RED deve poter ottenere un’ora valida dalla firewall attraverso il percorso previsto affinché il TLS handshake funzioni.
2. Sotto Network > Zones, creare una zona dedicata per le sedi RED oppure usare una zona esistente come VPN o WiFi. La zona LAN dovrebbe essere evitata per RED, così le regole LAN non si applicano involontariamente alla sede remota.
3. Sotto System services > RED, attivare il RED Provisioning Service.
4. Sotto Network > Interfaces > Add interface > Add RED, creare l’interfaccia RED.
5. Per Device deployment, scegliere Manually via USB stick.
6. Inserire RED ID, Unlock Code, uplink, RED network settings, zona, DHCP e VLAN adatti alla sede.
7. Scaricare il file di provisioning generato dall’interfaccia RED.
8. Copiare il file nella root della chiavetta USB.
9. Spegnere il RED, inserire la chiavetta USB e riaccendere il RED.
10. Dopo l’avvio, verificare interfaccia, LED, IP client, DNS, regola firewall e accesso alle destinazioni.

Se il lato WAN del RED usa DHCP, nella sede remota deve rispondere davvero un server DHCP. Se il RED non riceve un indirizzo, può entrare in un loop di riavvio. Con configurazione WAN statica, IP, gateway, DNS e NTP vanno controllati con particolare precisione.

I RED offline hanno comunque bisogno di un’ora valida. O il RED può raggiungere i server NTP Sophos, oppure si pianifica una Local service ACL exception rule mirata affinché il RED possa parlare dalla zona WAN verso la firewall. Come source va usato solo l’IP RED noto, la destination è la porta WAN della firewall, il service in questo scenario è HTTPS, action Accept. Questa eccezione non sostituisce un’apertura ampia di RED via WAN.

Stato, aggiornamenti e migrazione

Comprendere lo stato dei LED

I LED di stato sono spesso il punto di partenza più rapido per il troubleshooting del RED, poiché indicano in quale punto il processo di avvio si blocca.

Legenda:

• ⚫ spento
• 🟢 acceso verde
• 🟢 lampeggiante verde
• 🔴 acceso rosso
• 🔴 lampeggiante rosso

A seconda dell’angolo di visuale, della foto o della luce ambientale, un LED può apparire giallastro o arancione. Per la diagnosi conta soprattutto quale LED è acceso o lampeggiante e se è verde o rosso.

Normale sequenza di avvio

Se tutti e quattro i LED sono verdi ma il traffico non funziona, il problema di solito non è più nel tunnel. In tal caso, le regole del firewall, DHCP, VLAN, DNS, NAT o il routing sono più probabili.

Codici di errore

Failover 3G/4G

Nei modelli SD-RED con failover 3G/4G o modulo corrispondente possono verificarsi modelli aggiuntivi.

Controllare gli aggiornamenti del firmware

Se i LED lampeggiano insieme, il RED sta installando un firmware. In questa fase non si dovrebbe spegnere il dispositivo né scollegarlo da Internet. Un aggiornamento può richiedere alcuni minuti.

Sul Sophos Firewall si dovrebbe inoltre verificare:

Backup & firmware > Pattern updates

Lì, il pattern del firmware RED deve essere aggiornato. Se un RED è bloccato in un ciclo o non si avvia correttamente dopo un aggiornamento del firewall, un pattern del firmware RED obsoleto è un passo di verifica sensato. Configurare e verificare i pattern di Sophos Firewall spiega come interagiscono gli stati, il download automatico e l’installazione consapevole.

Un desiderio operativo correlato è descritto in Sophos Firewall Feature Request 2024: negli aggiornamenti del firmware RED e Access Point spesso mancano note di rilascio visibili direttamente nel backend. Per ambienti produttivi, gli aggiornamenti dovrebbero quindi essere pianificati consapevolmente e non installati in modo non coordinato durante i tempi operativi critici.

Verificare interfaccia RED, zona e regole

Dopo il successo del tunnel, il RED necessita di una configurazione del firewall pulita.

Punti di verifica tipici:

• L’interfaccia RED è attiva sotto Network > Interfaces.
• L’interfaccia si trova nella zona corretta.
• Il server DHCP o il relay DHCP è configurato correttamente.
• I client ricevono indirizzo IP, gateway e DNS.
• Le regole del firewall consentono solo le destinazioni necessarie.
• Il routing inverso verso la rete RED funziona.
• NAT viene utilizzato solo se pianificato consapevolmente.
• La configurazione VLAN corrisponde alla modalità RED e alla porta dello switch.

Per le basi delle regole, si adatta Comprendere e configurare correttamente le regole del Sophos Firewall. Se il tunnel è attivo ma il traffico non scorre, si dovrebbe combinare Log Viewer e Packet Capture.

L’opzione MAC filtering type può applicare nella rete RED una allow list o block list con un limite dipendente dal dispositivo, ma non sostituisce una regola firewall. Anche Remote IP assignment non è un’impostazione predefinita: assegna tramite DHCP o in modo statico un indirizzo al bridge con il tunnel RED sul lato WAN e va considerata solo quando i dispositivi dietro il RED non rispondono alle richieste ARP. Nessuna delle due opzioni deve essere attivata come soluzione generica per prestazioni o connettività.

Insidie di aggiornamento e migrazione

Non confondere Site-to-Site RED con SD-RED

Un tunnel RED tra firewall rimane un’architettura separata supportata in SFOS 22. Non utilizza nessuna delle quattro modalità operative SD-RED e non viene definito tramite DHCP o le porte LAN di una SD-RED. Durante un aggiornamento si inventariano entrambi i tipi di RED e si verifica poi ciascuno con il relativo test funzionale.

Per una pianificazione di aggiornamento più ampia, vedere Pianificare correttamente l’aggiornamento del firmware Sophos Firewall. Il processo completo tra firewall è descritto in Configurare Site-to-Site RED tra due Sophos Firewall.

Rimuovere Firewall RED legacy e i vecchi dispositivi RED prima di SFOS 22

SFOS 22.0 e versioni successive non supportano più Firewall RED Server Legacy e Firewall RED Client Legacy. Finché è presente una configurazione UTM-SFOS di questo tipo, l’aggiornamento, il ripristino e l’importazione della configurazione in SFOS 22 sono bloccati. Ciò non riguarda i tipi attuali Firewall RED server e Firewall RED client. Prima dell’aggiornamento si sostituiscono tutte le dipendenze delle interfacce legacy, si eliminano le interfacce e si crea quindi un nuovo backup della configurazione.

Anche RED 15, RED 15w e RED 50 sono end-of-life. I loro tunnel non si connettono più a partire da SFOS 20.0 MR1. Dopo un aggiornamento o ripristino in SFOS 22, la vecchia configurazione rimane visibile, ma non viene applicata e può soltanto essere eliminata. Non può essere importata. Queste sedi devono essere migrate a SD-RED 20 o SD-RED 60 prima dell’aggiornamento e testate con il loro flusso dati reale.

Host di sistema RED dopo SFOS 21.5 MR1

Da SFOS 21.5 MR1, gli oggetti host di sistema RED ricevono la corretta maschera di sottorete /32. Se tali oggetti generati automaticamente sono stati utilizzati in precedenza in regole o altre configurazioni per più di un IP host, dopo l’aggiornamento il traffico potrebbe corrispondere diversamente.

Dopo un aggiornamento, si dovrebbe quindi verificare:

• Gli host di sistema RED vengono utilizzati nelle regole del firewall?
• Una regola si aspetta erroneamente una rete invece di un singolo host?
• Devono essere sostituiti oggetti IP Host o Network Host?
• Le corrispondenze delle regole nel Log Viewer sono ancora corrette?

RED e failover HA

Negli ambienti HA, le sedi RED devono essere testate consapevolmente dopo un failover. Sophos segnala che i tunnel RED non sempre si riconnettono subito al dispositivo auxiliary dopo un failover HA. La durata dipende tra l’altro dal numero di interfacce e dalla configurazione.

Per sedi critiche non basta controllare lo stato HA della firewall. Vanno verificati anche:

• stato dell’interfaccia RED dopo failover
• accesso dei client dietro il RED
• match delle regole firewall rilevanti
• DNS e DHCP dietro il RED
• alerting di monitoring per interruzioni tunnel prolungate

Verificare throughput e prestazioni del RED

Sophos indica un throughput massimo del tunnel di 250 Mbit/s per SD-RED 20 e di 850 Mbit/s per SD-RED 60. Sono valori massimi della piattaforma, non una garanzia per un singolo trasferimento SMB, uno speed test nel browser o un unico flusso TCP. Sul risultato incidono anche endpoint, storage, finestra TCP, latenza effettiva tra le sedi, perdita di pacchetti, percorso del provider, carico del firewall e profili di sicurezza.

Un ping, ad esempio di 8 ms, verso un server pubblico per speed test non descrive necessariamente la latenza tra le due sedi RED. Anche uno speed test su ciascuna connessione Internet non verifica il percorso cifrato end-to-end attraverso il tunnel RED. Per rispondere a questa domanda servono un server di test in una LAN e un client di test nella LAN della sede opposta.

Testare il tunnel RED con iPerf3 in entrambe le direzioni

Prima del test del tunnel è opportuno creare una baseline locale con gli stessi endpoint cablati. In seguito si esegue iPerf3 attraverso il tunnel RED, prima con un flusso TCP, poi nella direzione inversa e infine con quattro flussi paralleli:

iperf3 -c 10.10.10.50 -t 30
iperf3 -c 10.10.10.50 -t 30 -R
iperf3 -c 10.10.10.50 -t 30 -P 4

10.10.10.50 è solo un indirizzo di esempio e deve essere sostituito con l’indirizzo IP del server iPerf3 nella LAN remota. Il test genera deliberatamente carico e va eseguito in una finestra appropriata. Testare correttamente le prestazioni di Sophos Firewall con iPerf3 descrive l’installazione, la regola firewall temporanea, i test UDP e l’analisi completa dei risultati.

I tre risultati rispondono a domande diverse:

• Se la baseline locale è già lenta, controllare prima endpoint, NIC, driver, cavi, switch e storage.
• Se un flusso è nettamente più lento di -P 4, è più probabile che il limite sia dovuto a latenza, finestra TCP o singolo flusso applicativo. Questo non dimostra ancora un limite del RED.
• Se uno e quattro flussi raggiungono lo stesso limite in entrambe le direzioni, analizzare collegamenti fisici, percorso del provider, perdita di pacchetti, configurazione RED e carico del firewall.
• Se solo una direzione è lenta, confrontare le rispettive velocità di upload, i contatori delle interfacce, gli errori, i drop e il percorso di ritorno.

Un tipico scenario pratico potrebbe mostrare circa 400 Mbit/s con un flusso e tra 700 Mbit/s e 800 Mbit/s con -P 4. Ciò indica che il percorso può trasportare una capacità aggregata nettamente superiore, mentre un singolo flusso TCP o SMB non riesce a sfruttarla completamente. Non garantisce che ogni applicazione raggiunga lo stesso risultato multistream.

Durante ogni esecuzione vanno documentati il round-trip time effettivo e la perdita di pacchetti tra le sedi, le ritrasmissioni iPerf, la Firewall Rule ID, i profili di sicurezza, la CPU del firewall e i contatori delle porte coinvolte. I link WAN e LAN devono funzionare realmente a 1 Gbit/s, in Full Duplex e senza contatori di errori o drop in aumento. Velocità e duplex dovrebbero restare in auto-negotiation su entrambi i lati, invece di forzare il gigabit su un solo lato.

IPS o altri profili di sicurezza non vanno disattivati in modo generalizzato. Per un test A/B si utilizza al massimo una regola temporanea limitata alla sorgente, alla destinazione e al servizio iPerf3 specifici, rimuovendola subito dopo. Se il risultato non cambia senza IPS, è meno probabile che IPS sia la causa per quel preciso percorso di test.

Disattivare realmente 802.3az o EEE

Per prestazioni ottimali, Sophos consiglia di disattivare 802.3az sugli switch collegati a un SD-RED 20 o SD-RED 60. Si tratta di Energy Efficient Ethernet, abbreviato EEE. EEE porta alcune parti del PHY Ethernet nello stato Lower Power Idle quando l’utilizzo del link è basso, risparmiando energia. Non è la stessa cosa di PoE o di 802.3x Flow Control.

L’impostazione non si trova né in WebAdmin né nella CLI di Sophos Firewall, e neppure in una schermata SD-RED documentata. Si modifica sulla porta dello switch collegata direttamente. Questo vale per le connessioni LAN utilizzate dal RED e, se è presente uno switch o router gestibile, anche per il link WAN fisico. Sui dispositivi di altri produttori l’opzione può chiamarsi EEE, Energy Efficient Ethernet, Green Ethernet, 802.3az o Power Saving. Non esiste una CLI universale.

Su un Sophos Switch si utilizza la pagina Port settings:

1. Selezionare la porta collegata direttamente al SD-RED.
2. Aprire Edit.
3. Impostare EEE status su Off.
4. Salvare con Apply.
5. Controllare stato del link, velocità negoziata, duplex e contatori degli errori, quindi ripetere lo stesso test iPerf3.

Su un Sophos Switch attuale lo stato può essere visualizzato in sola lettura nella CLI:

show eee

Per la porta di esempio 0/1, EEE si disattiva così:

configure terminal
interface gigabitethernet 0/1
no eee
exit
exit
save
show eee

0/1 deve essere sostituito con la porta effettivamente collegata al RED. no eee modifica la configurazione della porta. Se lo switch è raggiungibile solo attraverso questo percorso RED, servono una finestra di manutenzione e un accesso di gestione locale o alternativo. A seconda dello switch e del firmware, la modifica può causare una nuova negoziazione del link.

Per ripristinare lo stato precedente su un Sophos Switch, utilizzare eee al posto di no eee nello stesso Interface Configuration Mode:

configure terminal
interface gigabitethernet 0/1
eee
exit
exit
save
show eee

La disattivazione di EEE non disattiva né Ethernet né il gigabit. Lo svantaggio è che il PHY non risparmia più la stessa quantità di energia durante i periodi di inattività, quindi la porta consuma leggermente di più e può generare più calore. Non esiste alcuna garanzia di uno specifico aumento del throughput. È determinante il test riproducibile prima e dopo. Su uno switch unmanaged senza opzione EEE non è possibile modificare l’impostazione in modo affidabile; per il test occorre bypassarlo oppure utilizzare temporaneamente uno switch gestibile.

Modificare Tunnel compression e MTU solo in modo controllato

L’interfaccia RED si modifica in Network > Interfaces. Qui si trovano Tunnel compression e MTU. Sophos descrive Tunnel compression come un modo per comprimere il traffico RED e aumentare il throughput, soprattutto sulle connessioni lente. I dati già compressi o cifrati difficilmente possono essere ridotti ulteriormente, mentre la compressione aggiunge lavoro di elaborazione. Per questo non esiste un’impostazione corretta per tutte le sedi.

Per un test A/B si documentano prima lo stato iniziale e le misure. In seguito si modifica solo Tunnel compression, si salva e si ripete esattamente la stessa serie iPerf3. Infine si ripristina lo stato iniziale oppure si documenta consapevolmente la variante risultata effettivamente migliore. Il salvataggio può interrompere brevemente il tunnel RED, quindi sono opportuni una finestra di manutenzione e un accesso alternativo.

MTU non è un regolatore generale della velocità. Va analizzata solo quando i pacchetti piccoli funzionano ma i trasferimenti più grandi si bloccano, è visibile frammentazione oppure iPerf3 mostra molte ritrasmissioni. Verificare MTU e MSS di Sophos Firewall in caso di problemi VPN descrive il test DF sicuro, le dimensioni dei pacchetti e il ripristino. Senza un riscontro MTU riproducibile, mantenere il valore iniziale documentato.

Risoluzione dei problemi

Impossibile modificare l’IP RED in SFOS 22.0 MR2

In SFOS 22.0 MR2 Build 546, quando si modifica l’IP di un’interfaccia RED esistente può comparire il messaggio Failed to update RED interface. L’aspetto insidioso è che WebAdmin può già mostrare il nuovo IP, anche se il firewall continua a utilizzare internamente il vecchio indirizzo. Il solo IP visualizzato non dimostra quindi che la modifica sia stata applicata correttamente.

Il workaround documentato da Sophos modifica anche il nome della filiale e salva nuovamente l’interfaccia:

1. Documentare l’IP RED attuale, la maschera di rete, il Branch Name e qualsiasi intervallo DHCP RED esistente.
2. In Network > Interfaces, aprire l’interfaccia RED interessata e inserire l’IP desiderato.
3. Se compare Failed to update RED interface, aprire nuovamente l’interfaccia.
4. Modificare effettivamente il Branch Name, ad esempio da Branch-Zurich a Branch-Zurich-01, e salvare nuovamente con Save.
5. In 5. Device Management > 3. Advanced Shell, utilizzare il comando di sola lettura ifconfig per verificare se il nuovo indirizzo è attivo sull’interfaccia RED:

ifconfig

Il nome dell’interfaccia dipende dalla configurazione e può essere individuato in Network > Interfaces. Il riavvio del firewall o di un servizio, così come l’eliminazione dell’interfaccia RED, non fanno parte di questo workaround.

Se il nuovo IP RED appartiene a una rete diversa dall’intervallo DHCP RED precedente, SFOS disattiva il server DHCP RED. Si tratta del normale comportamento del prodotto, indipendente dal messaggio di errore. In Network > DHCP occorre quindi adattare il server esistente alla nuova rete oppure creare un nuovo server DHCP. L’intervallo di lease, le associazioni MAC statiche, il gateway e il DNS devono corrispondere al nuovo indirizzamento.

Infine, rinnovare il lease DHCP su un client dietro il RED e verificare l’indirizzo IP, il gateway, il DNS, lo stato del tunnel e l’accesso previsto. In Log Viewer, il traffico dovrebbe corrispondere nuovamente alla regola del firewall prevista. Se l’IP del backend rimane quello precedente anche dopo il nuovo salvataggio, al momento non è documentato alcun fix di produzione pubblicato per NC-184971. Le regole o le interfacce dipendenti non devono essere eliminate sulla base di un sospetto; occorre invece eseguire un backup della configurazione e coinvolgere il supporto Sophos.

Il RED non riceve un indirizzo IP

Se il RED si blocca al passaggio del router o il codice di errore indica DHCP o gateway, la causa è di solito nella sede remota.

Verificare:

• Il router del provider assegna un indirizzo IP tramite DHCP?
• Il cavo di rete è correttamente inserito nella porta WAN?
• Il gateway predefinito è raggiungibile?
• Un indirizzo IP statico è stato inserito completamente?
• Indirizzo IP, maschera di sottorete, gateway e DNS sono corretti?
• Un dispositivo preposto blocca il traffico?

Se il DHCP nella sede remota non funziona, il RED può finire in un ciclo di riavvio.

Il RED non raggiunge Internet

Se il router o il gateway è raggiungibile ma il LED Internet non diventa verde in modo permanente, il problema è di solito dietro il router locale.

Verificare:

• La connessione Internet funziona con un client normale?
• Il DNS funziona?
• NTP è raggiungibile?
• TCP 3400, UDP 3410 o NTP 123 sono bloccati?
• C’è un proxy o un firewall tra RED e Internet?
• La connessione del provider è abbastanza stabile?

Per il provisioning RED, il RED deve raggiungere il Sophos Provisioning Service. Sophos documenta *.astaro.com tramite TCP 3400 e UDP 3410; le altre destinazioni del produttore e i limiti di validazione sono descritti in Verificare servizi e porte in uscita di Sophos Firewall.

Il RED non raggiunge il Sophos Firewall

Se Internet è raggiungibile ma il tunnel non viene stabilito, si verifica il lato del firewall.

Verificare:

• Il servizio RED è attivato sul Sophos Firewall?
• Il RED è configurato correttamente?
• ID RED e codice di sblocco sono corretti?
• L’IP pubblico o il FQDN del firewall è raggiungibile?
• Administration > Device access è consentito per RED nella zona WAN appropriata?
• Una Local Service ACL consente l’accesso dalla sede remota?
• TCP 3400 e UDP 3410 arrivano al firewall?

Nella Advanced Shell si può verificare se il traffico RED arriva:

tcpdump -ni any port 3400 or port 3410

Se non arriva nulla, il problema è di solito prima del firewall: router del provider, NAT, firewall preposto, IP pubblico errato, FQDN o blocco delle porte.

Il RED si riavvia continuamente

Un ciclo di riavvio può avere diverse cause:

• alimentazione instabile
• alimentatore difettoso
• nessun indirizzo IP tramite DHCP
• configurazione IP statica errata
• porte bloccate
• pattern del firmware RED obsoleto
• codice di sblocco errato
• configurazione RED danneggiata o errata

Prima controllare alimentazione, cavi e DHCP. Poi verificare pattern del firmware RED, raggiungibilità delle porte e configurazione. Se il RED viene ricreato o ripristinato, ID RED e codice di sblocco devono essere documentati in anticipo.

Il tunnel è verde, ma il traffico non scorre

Questo caso è particolarmente comune. Il RED è connesso, ma i client non raggiungono sistemi interni o Internet.

Possibili cause:

• Regola del firewall mancante o troppo bassa.
• L’interfaccia RED si trova nella zona sbagliata.
• DHCP distribuisce gateway o server DNS errati.
• Mancanza di routing inverso verso la rete RED.
• NAT traduce il traffico inaspettatamente.
• Il tagging VLAN non è corretto.
• Una funzione di sicurezza blocca il traffico.

Ordine di verifica:

1. Verificare IP client, gateway e DNS.
2. Filtrare Log Viewer sull’IP di origine del client RED.
3. Verificare la corrispondenza della regola del firewall.
4. Eseguire Packet Capture su interfaccia RED e interfaccia di destinazione.
5. Verificare il percorso di ritorno dal sistema di destinazione o dalla rete di destinazione.
6. Controllare NAT e routing.

In caso di corrispondenze di regole poco chiare, aiuta Testare la regola del firewall con Log Viewer, Policy Test e Packet Capture.

Il traffico VLAN non funziona

Con SD-RED 60 sono possibili scenari VLAN, ma la modalità della porta, l’ID VLAN e la modalità RED devono corrispondere.

Verificare:

• Gli ID VLAN sono corretti su firewall, RED e switch.
• La porta RED è configurata come Access, Hybrid o Tagged Trunk in modo appropriato.
• La porta dello switch nella sede remota è correttamente taggata o non taggata.
• DHCP e DNS sono pianificati per VLAN.
• Esistono regole del firewall per le rispettive reti VLAN.
• La modalità RED scelta supporta lo scenario VLAN desiderato.

Per la risoluzione dei problemi, è utile una semplice rete di test non taggata. Se questa funziona, la causa è di solito nell’ID VLAN, nel tagging, nella modalità della porta o nella configurazione dello switch.

I punti di accesso RED rimangono inattivi

Se i punti di accesso RED o le funzioni Wi-Fi rimangono inattivi in scenari VLAN, l’opzione DHCP 234 può essere rilevante. Questo riguarda soprattutto i casi in cui la comunicazione RED o Access Point avviene tramite interfacce VLAN.

Questa opzione dovrebbe essere impostata solo se lo scenario specifico è adatto e chiaro quale IP dell’interfaccia del firewall i dispositivi devono raggiungere. In caso di problemi generali di connessione RED, l’opzione DHCP 234 non è il primo passo.

Il provisioning offline viene sovrascritto

Se un RED è stato prima provisionato online e successivamente offline tramite USB, una vecchia configurazione online può rimanere sul Sophos Provisioning Server. Se il RED non raggiunge il firewall, può riprovare a provisionare online e sovrascrivere la configurazione USB.

In tal caso, il RED deve essere nuovamente provisionato offline. Inoltre, la vecchia configurazione online dovrebbe essere rimossa tramite il supporto Sophos.

Diagnosi e controllo operativo

Punti di diagnosi sul Sophos Firewall

Per i problemi RED, questi punti sono utili:

• Network > Interfaces per interfaccia RED e stato
• Administration > Device access per autorizzazioni del servizio RED
• Rules and policies > Firewall rules per traffico dalla rete RED
• Diagnostics > Packet capture per verifica del percorso
• Log viewer con eventi RED, firewall e di sistema
• Backup & firmware > Pattern updates per pattern del firmware RED
• Advanced Shell con tcpdump

Una connessione riuscita può essere confermata anche nei log specifici del dispositivo. In /log/red.log appare un messaggio come New connection from ... with ID <RED ID>. In /log/red-<RED ID>.log compaiono poi connected OK, pushing config e, dopo una riconnessione, is now re-connected. Queste righe confermano la connessione e il trasferimento della configurazione, ma non un percorso del traffico produttivo funzionante. Il log completo specifico del dispositivo può contenere dati di provisioning e configurazione e deve essere ripulito prima della condivisione.

Per file di log e assegnazione dei servizi, si adatta Risoluzione dei problemi del Sophos Firewall: servizi e log.

Se invece l’intero firewall si avvia in modalità failsafe con Failed to start Red server service, non si tratta di un normale errore di un tunnel RED. Il runbook del failsafe spiega come distinguere i build e salvare le prove prima del ripristino.

Lista di controllo operativa

Prima del rollout:

• ID RED e codice di sblocco documentati.
• Indirizzo pubblico del firewall o FQDN verificato.
• TCP 3400, UDP 3410 e NTP 123 verificati.
• Servizio RED e Device Access pianificati sul firewall.
• Zona, DHCP, routing e regole del firewall definiti.
• Modalità VLAN testata in anticipo se necessario.

Dopo il collegamento:

• I LED mostrano il successo del tunnel.
• L’interfaccia RED è attiva.
• Il client riceve IP, gateway e DNS.
• Log Viewer mostra la regola del firewall prevista.
• I sistemi di destinazione interni e il percorso Internet funzionano come previsto.
• Il pattern del firmware è aggiornato.

In esercizio:

• Verificare regolarmente il pattern del firmware RED.
• Testare le connessioni delle sedi dopo gli aggiornamenti del firewall.
• Testare i tunnel RED tra firewall separatamente dalle sedi SD-RED fisiche.
• Verificare gli effetti /32 sugli host di sistema RED dopo SFOS 21.5 MR1.
• Confrontare il throughput RED con una baseline locale, uno e quattro flussi iPerf3 e le due direzioni.
• Mantenere 802.3az o EEE disattivato sulle porte switch collegate direttamente e verificarlo di nuovo dopo la sostituzione degli switch.
• Modificare Tunnel compression e MTU solo con un test documentato prima e dopo.
• Includere le sedi RED nel monitoraggio, nel backup e nella pianificazione di emergenza.

FAQ