Sophos Firewall Controlla le VLAN bridge per SFOS 22

Le interfacce bridge su Sophos Firewall sono pratiche se si vuole portare avanti in modo trasparente una rete Layer 2 esistente o se si vuole implementare una migrazione senza modifiche immediate a IP. Tuttavia, con le VLAN su un bridge, la progettazione diventa rapidamente soggetta a errori: c’è poi l’inoltro tra reti, traffico verso il firewall stesso, Device Access, DNS, AD, autenticazione e spesso vecchie configurazioni CLI.

Esattamente a questo punto c’è un importante caso operativo con SFOS 22. Sophos elenca un problema nell’attuale elenco dei problemi noti in cui il bridge si interfaccia con le configurazioni dei tag CLI VLAN in SFOS 22.0 GA e SFOS 22.0 MR1 non elaborano correttamente il traffico con tag VLAN se questo traffico ha origine da Sophos Firewall stesso o termina nel firewall. Ad esempio, ciò può influire su Active Directory, DNS, Device Access, STAS, LDAP, RADIUS o sull’accesso alla gestione, anche se il traffico normale viene instradato attraverso il bridge.

Sophos ora descrive anche il legacy CLI VLAN tagging come deprecated. Queste configurazioni ereditate possono impedire gli upgrade a SFOS 22.0 MR2 e versioni successive. Questo controllo quindi non è solo troubleshooting dopo un upgrade, ma anche una preparazione utile prima della prossima finestra di manutenzione.

Questo articolo non è un capitolo generale sui principi fondamentali di VLAN. Per pianificare zone, interfacce, VLAN, bridge e LAG, Sophos Firewall Configura zone e interfacce si adatta per primo. Si tratta specificamente del caso speciale del bridge VLAN dopo SFOS 22.

Quando questo argomento è rilevante

Il controllo ha senso quando più punti confluiscono:

Il firewall funziona su SFOS 22.0 GA o SFOS 22.0 MR1.
Esiste un’interfaccia bridge, ad esempio br0.
Storicamente le VLAN venivano create utilizzando la configurazione del tag CLI VLAN come system vlan-tag o venivano riprese da una vecchia configurazione.
Gli stessi servizi firewall devono raggiungere un tag VLAN.
Dopo un aggiornamento, AD, DNS, autenticazione, monitoraggio o accesso di gestione funzionano solo parzialmente.
Il normale traffico client attraverso il bridge sembra essere ancora in esecuzione.
È pianificato un upgrade a SFOS 22.0 MR2 o successivo oppure l’upgrade è bloccato dal legacy CLI VLAN tagging.

L’ultimo punto è importante: se il bridge continua a inoltrare il traffico tra le reti, inizialmente il problema non sembrerà un guasto del bridge. In pratica è facile cercare nel posto sbagliato, ad esempio nelle regole del firewall, nel DNS, nello STAS o nel controller del dominio.

Comprendere la direzione del traffico interessata

Devi separare chiaramente tre tipi di traffico.

I tipi di traffico differiscono in modo significativo:

Traffico passato attraverso il bridge: un client in VLAN 100 sta comunicando con un server in VLAN 100. Potrebbe continuare a funzionare, ma non dimostra che il traffico verso il firewall funzioni.
Traffico verso il firewall: un client utilizza il firewall come server DNS o destinazione WebAdmin. È proprio questo traffico che può essere influenzato perché finisce davanti al firewall.
Traffico dal firewall: il firewall interroga le destinazioni AD, DNS, LDAP, RADIUS, NTP o Syslog. Anche questo è fondamentale perché il firewall stesso è il mittente.

Se viene testata una sola applicazione tra due host, l’errore non può essere identificato con certezza. Il test deve includere deliberatamente un servizio che termina su Sophos Firewall o viene creato dal firewall.

Sintomi tipici

I possibili segnali sono:

Le regole basate sull’utente non funzionano più in modo affidabile perché AD, STAS o LDAP non possono essere raggiunti in modo stabile.
Le query DNS al firewall non riescono da singole VLAN.
Ping o HTTPS sui servizi firewall locali non funziona da VLAN, anche se le regole del firewall sembrano plausibili.
Il monitoraggio o Syslog appare incompleto se il firewall deve raggiungere un obiettivo in un tag VLAN.
Packet Capture mostra che il traffico tra i sistemi finali è visibile, ma i servizi firewall stessi non rispondono come previsto.
Dopo un aggiornamento SFOS-22, i sintomi si verificano senza modificare consapevolmente nulla sulle regole dello switch o del firewall.

Tali sintomi non dovrebbero essere affrontati immediatamente con regole di autorizzazione generali o approvazioni di accesso ai dispositivi. Innanzitutto deve essere chiaro se il design dell’interfaccia stessa ne risente.

Demarcazione rapida prima della conversione

Prima di spostare un bridge IP o creare nuove interfacce VLAN sul bridge, dovresti restringere la causa. Non tutti i problemi dopo un aggiornamento rientrano automaticamente nel caso SFOS-22-Bridge-VLAN.

Classificazione pratica:

Una sola applicazione tra due host non funziona: Più probabilmente sono la regola del firewall, NAT, il sistema di destinazione o il percorso di ritorno. Innanzitutto testare la regola del firewall e per le interruzioni analizzare i pacchetti eliminati.
WebAdmin, DNS o ping al firewall da un VLAN non funziona: Controlla Device Access, zona, servizio locale o bridge VLAN caso speciale. Quindi testare separatamente il traffico verso il firewall.
Il firewall non raggiunge AD, LDAP, RADIUS, DNS o Syslog in VLAN: Controlla il traffico dal firewall, dal routing, dal DNS o dal bridge VLAN caso speciale. Utilizza i test direttamente dalla configurazione del firewall e dai registri di servizio appropriati.
Il traffico client normale è in esecuzione, ma i servizi del firewall stesso no: Diventa più probabile il caso speciale Bridge VLAN. Controlla il design del bridge, la vecchia configurazione del tag CLI VLAN e l’interfaccia VLAN per il bridge.
Non ci sono voci di log corrispondenti: Controlla logging, filtro, servizio locale o bridge non registrato/NAT caso speciale. Combina Log Viewer, Packet Capture e i Sophos Firewall log di servizio pertinenti.

Per i problemi DNS è importante anche se i client utilizzano il firewall come risolutore o se il firewall stesso utilizza gli instradamenti delle richieste DNS ai server interni. Il secondo caso riguarda il traffico proveniente dal firewall e potrebbe apparire diverso dal normale traffico client per problemi di Bridge VLAN. Le nozioni di base si trovano in Configurazione dei percorsi di richiesta DNS su Sophos Firewall.

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

Includi il design esistente

Prima di apportare modifiche, è necessario documentare lo stato attuale. Particolarmente importanti sono:

Nome dell’interfaccia del bridge, ad esempio br0.
Membri del bridge, ovvero interfacce fisiche, VLAN, interfacce RED o LAG partecipanti.
IP indirizzo del bridge, se disponibile.
VLAN ID che passano sul ponte.
Cambia profilo porta: Tagged VLAN, Native VLAN, Trunk o porta di accesso.
Servizi che terminano sul firewall: DNS, Ping, HTTPS, SSH, User Portal, VPN Portale.
Servizi che il firewall deve raggiungere: AD, LDAP, RADIUS, DNS, NTP, Syslog, Centrale, Monitoraggio.

Se la struttura proviene da una vecchia migrazione, dovresti anche verificare se le VLAN sono state impostate tramite la configurazione CLI. È proprio questa eredità che spesso non viene più presa in considerazione quando il firewall nel corso degli anni è stato solo aggiornato.

⚠️ Non dovresti sperimentare spontaneamente interfacce bridge e VLAN durante le operazioni quotidiane. Una modifica errata può influire sull’accesso alla gestione, sul DNS, sull’autenticazione o su intere reti client. Prima della correzione sono necessari un backup, una finestra di manutenzione e un percorso di accesso alternativo.

Insidie specifiche del bridge prima della correzione

Sophos descrive tre limitazioni dei bridge che dovrebbero essere verificate consapevolmente prima della modifica.

Primo: un bridge senza indirizzo IP può scartare traffico se il traffico corrisponde a una regola firewall con filtro web proxy o a una regola NAT. Secondo Sophos, questi drop non vengono registrati nei log. Se una regola NAT è comunque necessaria, deve essere limitata in modo che la source translation per il bridge senza indirizzo IP resti su Original. Altrimenti si rischia di cercare in Log Viewer un drop che non compare mai.

Secondo: il VLAN filtering sul bridge si applica solo al traffico bridged, non al traffico routed. Se Filter VLANs è attivato ma non sono inseriti VLAN IDs consentiti, il traffico taggato di tutti i VLAN viene scartato; il traffico non taggato ne è escluso. Durante i test, questo può sembrare un problema VLAN incoerente.

Terzo: le interfacce bridge non sostituiscono qualsiasi design. Sophos indica limitazioni per Dynamic DNS, DHCP client, PPPoE e IPsec VPN. Se una di queste funzioni fa parte del design di destinazione, il workaround bridge non va applicato in modo isolato; il design delle interfacce deve essere rivalutato.

Soluzione alternativa e preparazione dell’upgrade

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

I design nuovi o ripuliti non dovrebbero più basarsi su system vlan-tag. Se questi tag CLI esistono ancora, è necessario documentarli, migrarli a interfacce VLAN in WebAdmin e solo dopo proseguire con l’upgrade firmware. Questo riduce sia il caso speciale bridge di SFOS 22 sia i blocchi di upgrade successivi.

Esempi:

VLAN 100: br0.100
VLAN 200: br0.200

Quando si crea il VLAN in WebAdmin, tre campi sono decisivi: Interface deve essere il bridge, Zone deve corrispondere allo scopo di sicurezza del VLAN e VLAN ID deve essere univoco. Sophos consente ID VLAN WebAdmin da 1 a 4094; lo stesso VLAN ID non dovrebbe essere pianificato più di una volta sullo stesso parent interface.

Il processo 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 utilizzato senza un proprio indirizzo IP. L’indirizzo IP per il VLAN interessato si trova quindi sull’interfaccia VLAN, ad esempio br0.100.

Processo pratico:

Crea backup.
Documentare il bridge corrente e la configurazione VLAN.
Aggiungi una nuova interfaccia VLAN in Network > Interfaces.
Seleziona il bridge come interfaccia principale, ad esempio br0.
Inserisci l’ID VLAN.
Scegli la tua zona consapevolmente.
Imposta l’indirizzo IP sull’interfaccia VLAN se il firewall deve trovarsi in questo VLAN Gateway o nel servizio locale.
Controlla Device Access per la zona.
Controlla le regole del firewall e le regole NAT.
Convalidare con un client di prova.

La zona non è solo ordinata in WebAdmin. Questa decisione influisce sulle regole del firewall, Device Access, sui registri e su molti passaggi successivi per la risoluzione dei problemi. Se una VLAN è intesa come rete di gestione, server o client, questa dovrebbe essere visibile nella zona.

Se il bridge aveva in precedenza l’indirizzo produttivo IP

Se il bridge attualmente utilizza l’indirizzo IP, che in futuro dovrà essere accessibile in VLAN, dovresti prestare particolare attenzione. Esistono due varianti pulite per la conversione: il bridge riceve un indirizzo IP diverso oppure il bridge rimane senza indirizzo IP. L’indirizzo produttivo precedente viene quindi assegnato all’interfaccia VLAN.

Si tratta di un cambiamento che rischia di fallire. È opportuno chiarire in anticipo:

Quale indirizzo viene utilizzato per raggiungere WebAdmin?
Quali client utilizzano il firewall come predefinito Gateway?
Quali impostazioni DNS o DHCP puntano a questo indirizzo?
Quali regole di accesso ai dispositivi si applicano alla zona precedente?
Esiste un secondo accesso di gestione da una rete non interessata?

Per le località remote, questo cambiamento non dovrebbe essere pianificato senza un percorso di ritorno locale. Se WebAdmin e SSH passano esattamente sul bridge interessato IP, un errore può interrompere l’accesso amministrativo.

Device Access e successivamente controlla le regole del firewall

Dopo aver creato l’interfaccia VLAN, non è sufficiente testare solo l’indirizzo IP. Device Access e le regole del firewall devono corrispondere alla nuova progettazione dell’interfaccia e della zona.

Per verificare:

Administration > Device access: i portali Ping/Ping6, DNS, HTTPS, SSH, User Portal o VPN sono consentiti solo nelle zone corrette?
Rules and policies > Firewall rules: Ci sono regole per la nuova zona?
Rules and policies > NAT rules: il traffico viene tradotto in modo imprevisto?
Network > DNS o percorsi di richiesta DNS: il firewall raggiunge i server DNS o AD corretti?
Authentication > Servers: AD, LDAP o RADIUS sono accessibili dopo la modifica? Per i servizi firewall locali, Device Access configurare in modo sicuro Sophos Firewall è l’articolo approfondito appropriato. Sophos Firewall Regola di prova con Log Viewer e Packet Capture aiuta nell’analisi delle regole.

Convalida dopo la correzione

Un test pulito dovrebbe contenere più di un ping.

Test dal VLAN interessato

Verifica da un client nelle VLAN interessate:

Raggiungi Gateway predefinito.
Testare il firewall IP sulla nuova interfaccia VLAN tramite ping, se consentito.
Testare il DNS rispetto al firewall se il firewall funge da risolutore DNS.
Testare WebAdmin o il portale solo dalle reti di gestione consentite.
Controllare un’applicazione tipica o una connessione al server.
Controlla Log Viewer per la corrispondenza tra ID regola e zona.

Prova dal firewall

Sono necessari test separati per il traffico generato dal firewall stesso:

Testare i server AD o LDAP in Authentication > Servers.
Controlla la risoluzione DNS tramite firewall.
Seleziona NTP, Syslog o il target di monitoraggio se questi servizi sono in VLAN.
Utilizzare Packet Capture sull’interfaccia VLAN quando non è chiaro se i pacchetti stanno lasciando il firewall.

Se sono interessate le regole STAS o basate sull’utente, è necessario selezionare anche Configura STAS su Sophos Firewall. Per gli aggiornamenti SFOS-22, questo punto appartiene anche al SFOS 22 Upgrade Check.

Errori comuni

Insidie tipiche:

Testare solo il traffico client-server: il bridge sembra integro, anche se i servizi firewall locali sono interessati. Testare anche il traffico da e verso il firewall.
Sposta bridge IP senza piano: WebAdmin, DNS o Gateway potrebbero non funzionare. Preparare backup, finestre di manutenzione e accessi alternativi.
Seleziona la zona in modo errato per la nuova interfaccia VLAN: Regole, Device Access e registri non si adattano. Scegli una zona in base a motivi di sicurezza, non in base all’abitudine.
Device Access aperto troppo: Il problema sembra risolto, ma i servizi di gestione sono inutilmente accessibili. Local Service ACL pianifica in modo specifico.
Non controllare la porta dello switch: VLAN arriva errato o senza tag. Convalida il profilo Tagged/Untagged, Native VLAN e Trunk.
Ignora la vecchia configurazione CLI: L’errore rimane inspiegabile dopo l’aggiornamento. Documenta il vecchio design ed esegui la migrazione alle interfacce WebAdmin-VLAN.

Lista di controllo

Verifica della pertinenza della versione SFOS e del problema noto.
Interfaccia del bridge, membri del bridge e ID VLAN documentati.
Chiarito se veniva utilizzata la vecchia configurazione del tag CLI VLAN.
Drop specifici del bridge tramite NAT/web proxy e VLAN filtering controllati.
Upgrade pianificato a SFOS 22.0 MR2 o successivo verificato rispetto ai legacy CLI VLAN tags.
Identificati i servizi interessati da e verso il firewall.
Disponibilità di backup e accesso alla gestione alternativa.
Interfaccia VLAN pianificata con bridge come interfaccia principale.
Zona, Device Access, regole firewall e NAT controllate.
Test effettuati dal VLAN e dal firewall.
Risultato registrato nel registro delle modifiche o nella documentazione di rete.

Domande frequenti

Perché il traffico normale funziona attraverso il bridge ma il DNS al firewall no?

In questo caso speciale SFOS-22, il traffico VLAN passato può continuare a funzionare, mentre il traffico contrassegnato con VLAN che termina o ha origine dal firewall viene influenzato. Pertanto, è necessario testare separatamente i servizi firewall locali.

In generale dovresti evitare le VLAN bridge su Sophos Firewall?

Non generalmente. I bridge possono essere utili per migrazioni o progetti trasparenti. Per le nuove reti segmentate, tuttavia, le interfacce VLAN separate con zone libere sono generalmente più chiare e più facili da utilizzare.

Il problema può essere risolto con una regola del firewall?

Non affidabile. Se la progettazione dell’interfaccia viene influenzata, un’ulteriore regola Consenti non modificherà la causa. Per prima cosa dovresti verificare se VLAN deve essere creato correttamente come interfaccia sul bridge.

Cosa dovresti controllare prima di apportare modifiche al bridge IP?

È necessario chiarire se WebAdmin, DNS, DHCP, Gateway predefinito, autenticazione o monitoraggio utilizzano questo indirizzo. Inoltre sono necessari un backup attuale e un percorso di accesso alternativo.