Verifica dei Bridge-VLAN su Sophos Firewall dopo SFOS 22

Le interfacce bridge su Sophos Firewall sono utili quando si desidera continuare a gestire una rete Layer-2 esistente in modo trasparente o effettuare una migrazione senza modifiche immediate agli indirizzi IP. Tuttavia, l’uso di VLAN su un bridge può rendere il design suscettibile a errori: si verifica quindi un inoltro tra reti, traffico verso il firewall stesso, Device Access, DNS, AD, autenticazione e spesso configurazioni CLI obsolete.

Proprio in questo contesto, SFOS 22 presenta un caso operativo importante. Sophos elenca nella lista dei problemi noti un problema in cui le interfacce bridge con configurazioni di tag VLAN CLI in SFOS 22.0 GA e SFOS 22.0 MR1 non gestiscono correttamente il traffico VLAN taggato quando questo traffico proviene dal firewall Sophos stesso o termina sul firewall. Questo può riguardare, ad esempio, Active Directory, DNS, Device Access, STAS, LDAP, RADIUS o accesso di gestione, anche se il traffico normale viene inoltrato attraverso il bridge.

Questo articolo non è un capitolo generale sulle basi delle VLAN. Per la pianificazione di zone, interfacce, VLAN, bridge e LAG, consultare prima Configurare zone e interfacce su Sophos Firewall. Qui ci concentriamo specificamente sul caso speciale dei Bridge-VLAN dopo SFOS 22.

Quando questo argomento è rilevante

Il controllo è utile quando si verificano più punti contemporaneamente:

• Il firewall funziona su SFOS 22.0 GA o SFOS 22.0 MR1.
• Esiste un’interfaccia bridge, ad esempio br0.
• Le VLAN sono state storicamente costruite tramite configurazione di tag VLAN CLI come system vlan-tag o ereditate da una vecchia configurazione.
• I servizi del firewall stesso devono raggiungere una VLAN taggata.
• Dopo un aggiornamento, AD, DNS, autenticazione, monitoraggio o accesso di gestione funzionano solo parzialmente.
• Il traffico client normale attraverso il bridge sembra continuare a funzionare.

L’ultimo punto è importante: se il bridge continua a inoltrare traffico tra reti, il problema inizialmente non sembra un errore del bridge. In pratica, si tende a cercare nel posto sbagliato, ad esempio nelle regole del firewall, DNS, STAS o nel controller di dominio.

Comprendere la direzione del traffico interessato

È necessario distinguere chiaramente tre tipi di traffico.

Se si testa solo un’applicazione tra due host, non si riconosce il problema con certezza. Il test deve includere consapevolmente un servizio che termina o è generato dal firewall Sophos.

Sintomi tipici

Possibili segni sono:

• Le regole basate sugli utenti non funzionano più in modo affidabile perché AD, STAS o LDAP non sono stabilmente raggiungibili.
• Le richieste DNS al firewall falliscono da alcune VLAN.
• Ping o HTTPS ai servizi locali del firewall non funzionano da una VLAN, anche se le regole del firewall sembrano plausibili.
• Il monitoraggio o Syslog appare incompleto se il firewall deve raggiungere una destinazione in una VLAN taggata.
• Packet Capture mostra che il traffico tra i sistemi finali è visibile, ma i servizi del firewall stesso non rispondono come previsto.
• Dopo un aggiornamento a SFOS 22, i sintomi si manifestano senza che siano state apportate modifiche consapevoli allo switch o alle regole del firewall.

Tali sintomi non dovrebbero essere affrontati immediatamente con regole di autorizzazione ampie o concessioni di Device Access. Prima di tutto, è necessario chiarire se il design dell’interfaccia è interessato.

Delimitazione rapida prima della modifica

Prima di spostare un IP del bridge o creare nuove interfacce VLAN sul bridge, è necessario delimitare la causa. Non tutti i problemi dopo un aggiornamento sono automaticamente il caso dei Bridge-VLAN di SFOS 22.

Per i problemi DNS è inoltre importante sapere se i client utilizzano il firewall come resolver o se il firewall stesso utilizza DNS Request Routes verso server interni. Il secondo caso riguarda il traffico dal firewall e può apparire diverso dai normali traffici client in caso di problemi Bridge-VLAN. Le basi sono descritte in Configurare le DNS Request Routes su Sophos Firewall.

Se la delimitazione rapida indica chiaramente i servizi locali del firewall o il traffico generato dal firewall, la modifica dovrebbe comunque essere pianificata. Una correzione del bridge senza backup, finestra di manutenzione e percorso di accesso alternativo è troppo rischiosa per le reti produttive.

Documentare il design esistente

Prima delle modifiche, è necessario documentare lo stato attuale. Sono particolarmente importanti:

• Nome dell’interfaccia bridge, ad esempio br0.
• Membri del bridge, ovvero interfacce fisiche coinvolte, VLAN, interfacce RED o LAG.
• Indirizzo IP del bridge, se presente.
• ID VLAN che attraversano il bridge.
• Profilo della porta switch: VLAN taggate, VLAN native, trunk o porta di accesso.
• Servizi che terminano sul firewall: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Servizi che il firewall deve raggiungere: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, monitoraggio.

Se la configurazione deriva da una vecchia migrazione, è necessario verificare se le VLAN sono state configurate tramite CLI. Proprio questo retaggio è spesso dimenticato quando il firewall è stato solo aggiornato nel corso degli anni.

⚠️ Non si dovrebbe sperimentare spontaneamente con interfacce bridge e VLAN durante l’orario di lavoro. Una modifica errata può influire sull’accesso di gestione, DNS, autenticazione o intere reti client. Prima della correzione, è necessario un backup, una finestra di manutenzione e un percorso di accesso alternativo.

Soluzione temporanea: Creare interfacce VLAN sul bridge

Un modo pratico è creare interfacce VLAN in Network > Interfaces utilizzando l’interfaccia bridge come interfaccia principale.

Esempi:

La procedura dipende dal fatto che il bridge stesso abbia già un indirizzo IP.

Se il bridge non necessita di un indirizzo IP

Se il bridge deve solo inoltrare in modo trasparente, può essere gestito senza un proprio indirizzo IP. L’indirizzo IP per la VLAN interessata si trova quindi sull’interfaccia VLAN, ad esempio br0.100.

Procedura pratica:

1. Creare un backup.
2. Documentare la configurazione attuale del bridge e delle VLAN.
3. Aggiungere una nuova interfaccia VLAN in Network > Interfaces.
4. Selezionare il bridge come interfaccia principale, ad esempio br0.
5. Inserire l’ID VLAN.
6. Scegliere consapevolmente la zona.
7. Impostare l’indirizzo IP sull’interfaccia VLAN, se il firewall deve essere gateway o servizio locale in questa VLAN.
8. Verificare il Device Access per la zona.
9. Verificare le regole del firewall e le regole NAT.
10. Validare con un client di test.

La zona non è solo un ordine nel WebAdmin. Questa decisione influenza le regole del firewall, il Device Access, i log e molti passaggi successivi di risoluzione dei problemi. Se una VLAN è destinata a essere una rete di gestione, server o client, dovrebbe essere visibile nella zona.

Se il bridge attualmente ha l’indirizzo IP produttivo

Se il bridge utilizza attualmente l’indirizzo IP che deve essere raggiungibile nella VLAN in futuro, è necessario procedere con particolare cautela. Per la modifica ci sono due varianti pulite: il bridge riceve un altro indirizzo IP, oppure il bridge rimane senza indirizzo IP. L’indirizzo produttivo attuale viene successivamente assegnato all’interfaccia VLAN.

Questo è un cambiamento con rischio di interruzione. Prima dovrebbe essere chiarito:

• Quale indirizzo viene utilizzato per raggiungere WebAdmin?
• Quali client utilizzano il firewall come gateway predefinito?
• Quali impostazioni DNS o DHCP puntano a questo indirizzo?
• Quali regole di Device Access dipendono dalla zona attuale?
• Esiste un secondo accesso di gestione da una rete non interessata?

Per le sedi remote, questa modifica non dovrebbe essere pianificata senza un percorso di ritorno locale. Se WebAdmin e SSH funzionano tramite l’IP del bridge interessato, un errore può interrompere l’accesso amministrativo.

Verificare Device Access e regole del firewall dopo

Dopo aver creato l’interfaccia VLAN, non basta testare solo l’indirizzo IP. Device Access e regole del firewall devono corrispondere al nuovo design dell’interfaccia e della zona.

Da verificare:

• Administration > Device access: Ping/Ping6, DNS, HTTPS, SSH, User Portal o VPN Portal sono consentiti solo nelle zone corrette?
• Rules and policies > Firewall rules: Esistono regole per la nuova zona?
• Rules and policies > NAT rules: Il traffico viene tradotto in modo inaspettato?
• Network > DNS o DNS Request Routes: Il firewall raggiunge i server DNS o AD corretti?
• Authentication > Servers: AD, LDAP o RADIUS sono raggiungibili dopo la modifica?

Per i servizi locali del firewall, Configurare in modo sicuro il Device Access su Sophos Firewall è l’articolo di approfondimento appropriato. Per l’analisi delle regole, aiuta Testare la regola del firewall con Log Viewer e Packet Capture su Sophos Firewall.

Validazione dopo la correzione

Un test accurato dovrebbe includere più di un semplice ping.

Test dalla VLAN interessata

Da un client nella VLAN interessata, verificare:

1. Raggiungere il gateway predefinito.
2. Testare l’IP del firewall sulla nuova interfaccia VLAN tramite ping, se consentito.
3. Testare il DNS contro il firewall, se il firewall funge da resolver DNS.
4. Testare WebAdmin o il portale solo dalle reti di gestione consentite.
5. Verificare un’applicazione tipica o una connessione al server.
6. Controllare Log Viewer per ID regola e zona corrispondenti.

Test dal firewall

Per il traffico generato dal firewall stesso, sono necessari test separati:

• Testare il server AD o LDAP in Authentication > Servers.
• Verificare la risoluzione DNS tramite il firewall.
• Verificare l’obiettivo NTP, Syslog o monitoraggio, se questi servizi si trovano nella VLAN.
• Utilizzare Packet Capture sull’interfaccia VLAN se non è chiaro se i pacchetti lasciano il firewall.

Se STAS o le regole basate sugli utenti sono interessate, dovrebbe essere verificato anche Configurare STAS su Sophos Firewall. Negli aggiornamenti a SFOS 22, questo punto è incluso anche nel Controllo dell’aggiornamento a SFOS 22.

Errori comuni

Checklist

• Verificata la versione SFOS e la rilevanza del problema noto.
• Documentati l’interfaccia bridge, i membri del bridge e gli ID VLAN.
• Chiarito se è stata utilizzata una vecchia configurazione di tag VLAN CLI.
• Identificati i servizi interessati verso e dal firewall.
• Backup e accesso di gestione alternativo disponibili.
• Pianificata l’interfaccia VLAN con il bridge come interfaccia principale.
• Verificati zona, Device Access, regole del firewall e regole NAT.
• Eseguiti test dalla VLAN e dal firewall.
• Risultato registrato nel registro delle modifiche o nella documentazione di rete.

FAQ