Configurare e testare un'interfaccia bridge su Sophos Firewall

Un’interfaccia bridge collega due o più interfacce a livello 2. Consente di inserire Sophos Firewall in un percorso di rete esistente senza modificare la subnet o il gateway predefinito dei client. Il bridge può operare in modo trasparente senza indirizzo IP oppure instradare il traffico con un proprio indirizzo IP.

Nell’esempio di questo articolo, il firewall viene inserito tra un router esistente e il core switch. Port4 è rivolta verso il router e appartiene alla zona WAN, mentre Port3 è rivolta verso lo switch interno e appartiene alla zona LAN. Al bridge non viene assegnato alcun indirizzo IP. WebAdmin rimane accessibile tramite una porta di gestione separata.

⚠️ Al momento del salvataggio, il bridge acquisisce le interfacce che ne fanno parte. Una zona errata, l’assenza di un percorso di gestione o un percorso Layer 2 ridondante possono interrompere l’accesso o generare un loop. Creare prima un backup, documentare il cablaggio e verificare un accesso amministrativo indipendente. Collegare un secondo percorso fisico soltanto dopo aver definito STP e l’eventuale architettura HA.

Quale modalità bridge è adatta all’obiettivo?

Bridge trasparente senza indirizzo IP

Un bridge trasparente inoltra i frame Ethernet tra le interfacce che ne fanno parte, ma non opera come gateway. Gli indirizzi IP, la subnet e il gateway predefinito dei dispositivi finali rimangono invariati. Questa soluzione è adatta a una migrazione controllata o all’aggiunta di un livello di sicurezza tra un router esistente e la rete interna. A seconda della regola e della licenza, SFOS può applicare DPI, IPS, scansione antimalware e controllo della posta elettronica, anche se il router esistente continua a fungere da gateway.

Trasparente non significa privo di filtri. Le zone dei membri determinano quale regola firewall può essere applicata. Per il percorso dell’esempio, da Port3 nella zona LAN a Port4 nella zona WAN, è necessaria una regola LAN-to-WAN appropriata. Se entrambi i membri si trovano nella zona LAN, occorre invece una regola LAN-to-LAN.

L’articolo Pianificare zone e interfacce su Sophos Firewall spiega come scegliere le aree di attendibilità, creare zone personalizzate e assegnare le interfacce. Tutte le decisioni specifiche per il bridge sono trattate nel presente articolo; l’articolo introduttivo è utile quando il modello delle zone è nuovo o non uniforme.

Se il bridge non ha un indirizzo IP, l’amministrazione deve avvenire tramite un’altra interfaccia. Nell’esempio, Port2 utilizza una rete di gestione separata. WebAdmin rimane così accessibile anche se il bridge, le relative regole o il cablaggio non sono ancora configurati correttamente.

Bridge instradato con indirizzo IP

Con Enable routing on this bridge pair, al bridge viene assegnato un indirizzo IP e può operare come gateway o endpoint locale del firewall. Il suo ruolo cambia radicalmente: oltre all’inoltro a livello 2, entrano in gioco traffico instradato, servizi locali ed eventuali dipendenze dal gateway.

Il filtro VLAN sul bridge continua ad applicarsi soltanto ai frame sottoposti a bridging. Non filtra il traffico instradato dal bridge. Chi utilizza il bridge come gateway deve quindi verificare anche il routing, Device Access, le regole firewall e il NAT.

La guida di SFOS 22 non è univoca riguardo al DHCP. Per l’assegnazione IP di un bridge instradato elenca Static e DHCP, ma nello stesso documento indica i client DHCP tra le funzioni bridge non supportate. Per un’architettura di produzione prevedibile si utilizza pertanto un indirizzo statico. Il DHCP su un bridge deve essere impiegato soltanto dopo aver verificato la versione specifica di SFOS e aver ottenuto conferma da Sophos.

Bridge Mode nella procedura guidata di configurazione

La modalità Bridge Mode della procedura guidata iniziale e un’interfaccia bridge creata successivamente in Network > Interfaces si basano sullo stesso principio Layer 2, ma non costituiscono la stessa procedura operativa.

Su una nuova appliance, per impostazione predefinita Port A utilizza 172.16.16.16/24, mentre Port B ottiene l’indirizzo tramite DHCP. Per la configurazione iniziale, è possibile ad esempio assegnare a un computer 172.16.16.2/24 e collegarlo a Port A. WebAdmin è quindi raggiungibile all’indirizzo https://172.16.16.16:4444. Nella procedura guidata si seleziona Internet gateway (Bridge Mode). Dopo la registrazione e la configurazione delle impostazioni di protezione e notifica, SFOS applica la configurazione e si riavvia.

Questa modalità è destinata a una distribuzione iniziale completa. Per aggiungere una singola nuova coppia bridge a un firewall già operativo non si esegue nuovamente la procedura guidata. Se la procedura viene eseguita dopo aver già configurato HA, disattiva HA.

Bridge Mode supporta HA. Tuttavia, finché HA è attivo, la funzione STP di SFOS non può essere abilitata su alcuna interfaccia bridge. Questa limitazione va distinta dall’inoltro dei pacchetti STP, RSTP e di routing multicast. Un bridge trasparente può lasciar passare questi frame senza partecipare direttamente alla prevenzione dei loop mediante l’opzione SFOS Turn on Spanning Tree Protocol (STP).

Pianificare l’esempio prima della configurazione

Topologia e valori di esempio

Il router esistente rimane il gateway predefinito per la rete 10.20.0.0/24. Il firewall viene inserito in modo trasparente nel relativo percorso LAN:

Internet
   |
Router esistente: 10.20.0.1
   |
Port4, zona WAN
[ Bridge_Inline / brinline / nessun indirizzo IP ]
Port3, zona LAN
   |
Core switch e client: 10.20.0.0/24

Percorso di gestione separato:
Port2, zona LAN, 10.99.0.1/24

Dopo l’inserimento, un client con 10.20.0.50/24 continua a utilizzare 10.20.0.1 come gateway. Al bridge non viene assegnato né un indirizzo della rete 10.20.0.0/24 né una route predefinita. Occorre adattare numeri di porta, zone, rete di gestione e regole. La rete di esempio non deve essere replicata senza verifiche in un ambiente di produzione.

Prima dell’intervento si documentano due condizioni: quali connessioni funzionano prima dell’inserimento e attraverso quale percorso è possibile amministrare il firewall in caso di guasto del percorso dati di produzione. Le verifiche devono includere almeno DNS, gateway, un’applicazione tipica, il throughput previsto e l’accesso a WebAdmin.

Verificare membri, zone e dipendenze

Un bridge può includere fino a 64 membri. Possono essere utilizzati come membri:

• interfacce fisiche;
• interfacce RED;
• LAG;
• interfacce VLAN su un’interfaccia fisica, RED o LAG.

Un numero maggiore di membri non è indice di qualità. Ogni collegamento aggiuntivo amplia il dominio Layer 2, la tabella MAC e il numero di loop possibili. Per un percorso inline sono normalmente sufficienti due membri.

Prima di aggiungere un’interfaccia, verificare la presenza di indirizzi IP, VLAN, DHCP, gateway, NAT, regole firewall, routing, Device Access e Object Usage. La funzione precedente di una porta non viene rimossa automaticamente da tutti gli oggetti dipendenti soltanto perché la porta entra a far parte di un bridge.

Secondo Sophos, le interfacce bridge non supportano Dynamic DNS, PPPoE o IPsec VPN. Anche le indicazioni relative al DHCP sono contraddittorie, come descritto sopra. Un bridge non è quindi un sostituto universale di un’interfaccia WAN o VPN. Per reti nuove e nettamente segmentate, VLAN e routing sono spesso più semplici da gestire.

LAN Bypass è una funzione hardware distinta e non il normale comportamento di un bridge qualsiasi. L’articolo Configurare LAN Bypass e testarlo in modo controllato illustra quali modelli e coppie di porte supportano questa funzione e come si comportano in caso di guasto.

Creare il bridge in WebAdmin

Nome, nome hardware e membri

1. Aprire Network > Interfaces > Add interface > Add bridge.
2. In Name, inserire ad esempio Bridge_Inline. Il nome visualizzato può contenere fino a 58 caratteri e può essere modificato in seguito.
3. In Hardware name, inserire ad esempio brinline. Il valore può contenere al massimo 10 caratteri, esclusivamente lettere, numeri e _. Dopo il salvataggio non può più essere modificato.
4. Per l’esempio trasparente, lasciare disabilitata l’opzione Enable routing on this bridge pair.
5. Aggiungere Port3 con zona LAN e Port4 con zona WAN come Member interfaces.
6. Verificare le impostazioni relative a VLAN, ARP, STP, MAC, MTU, MSS ed EtherType.
7. Selezionare Save soltanto quando l’accesso di gestione separato funziona e i due cavi sono contrassegnati in modo inequivocabile.

SFOS impedisce l’uso dei nomi hardware riservati. L’elenco completo riportato nella guida di SFOS 22 è il seguente:

all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp,
imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port,
MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos,
GuestAP, spq, Halink

Per un bridge instradato si specifica inoltre un indirizzo IPv4 o IPv6. Se il bridge include membri WAN, vengono visualizzati anche i campi relativi al gateway. Questi valori devono corrispondere all’architettura di routing effettiva. Per il bridge trasparente dell’esempio rimangono vuoti.

Filtri VLAN ed EtherType

Filter VLANs limita il traffico con tag agli ID specificati in Permitted VLAN ID or ID range. Sono ammessi valori singoli e intervalli, ad esempio 20-35. Se il filtro è attivo ma l’elenco è vuoto, SFOS scarta tutto il traffico VLAN con tag. Il traffico senza tag continua a transitare. Proprio questa combinazione può risultare fuorviante durante la risoluzione dei problemi.

Il filtro VLAN si applica soltanto ai frame inoltrati dal bridge. Non sostituisce né le regole firewall né il controllo del traffico instradato. I tag VLAN storici configurati tramite CLI richiedono una verifica specifica con SFOS 22. La procedura descritta in Verificare le VLAN bridge dopo l’aggiornamento a SFOS 22 tratta questo caso particolare e le relative indicazioni sulle versioni.

L’opzione Filter Ethernet frames consente di limitare gli EtherType. Senza il filtro, il bridge accetta tutti i frame Ethernet. Se il filtro è attivo e non contiene tipi autorizzati, rimangono consentiti soltanto ARP, IPv4, IPv6, 8021Q ed EXTE. Gli altri protocolli vengono inseriti come ID esadecimale di quattro cifre, ad esempio 809B per AppleTalk, 8138 per Novell e 8863 e 8864 per PPPoE.

Non si autorizza preventivamente un EtherType. Prima occorre verificare in Packet Capture quale protocollo manca effettivamente. In caso contrario, si crea un elenco di eccezioni difficile da ricostruire, che in seguito nessuno sarà più in grado di attribuire con certezza.

ARP, STP e MAC aging

Permit ARP broadcast è abilitata per impostazione predefinita. Il bridge necessita di ARP per apprendere le associazioni tra indirizzi IP e MAC e costruire la propria tabella di inoltro. Disabilitare questa opzione non costituisce una protezione generale contro i broadcast. È opportuno soltanto in presenza di un ARP storm comprovato e richiede associazioni statiche in Network > Neighbors (ARP–NDP).

Turn on Spanning Tree Protocol (STP) protegge dai loop quando esiste più di un percorso Layer 2 tra le stesse aree. STP può bloccare un percorso ridondante e commutare su di esso in caso di guasto del percorso attivo. L’opzione non è disponibile sulle interfacce bridge finché HA è attivo. Un cluster HA con cablaggio ridondante richiede quindi un’architettura in cui switch, percorsi delle porte e prevenzione dei loop siano pianificati congiuntamente.

Per impostazione predefinita, STP max age è impostato su 20 secondi. SFOS utilizza le BPDU per scambiare informazioni sulla topologia tra i bridge. Il valore non deve essere ottimizzato sul firewall in modo isolato, ma deve essere coerente con l’intero dominio STP.

Per impostazione predefinita, MAC aging rimuove gli indirizzi MAC inattivi dopo 300 secondi. Un valore inferiore può reagire più rapidamente al cambio dei dispositivi in una rete guest o di test molto dinamica. In una rete di data center stabile, un valore superiore evita di ripetere inutilmente l’apprendimento. Il valore va modificato soltanto se giustificato da MAC flapping, frequenti spostamenti dei dispositivi o da un requisito operativo concreto.

MTU e MSS

Se la MTU del bridge e quella dei suoi membri sono diverse, il bridge adotta il valore più basso. Un bridge con MTU 9000 rimane di fatto limitato a 1500 se un membro supporta soltanto 1500. Il valore ereditato è visibile nella tabella delle interfacce.

Override MSS riguarda il traffico TCP. Il valore limita il payload di ciascun segmento TCP affinché header aggiuntivi o l’incapsulamento di un tunnel non superino la MTU effettiva. È utile in presenza di un problema MTU o di frammentazione comprovato, ma non corregge una VLAN errata, una regola mancante o un percorso di ritorno interrotto. L’MSS clamping non riduce le dimensioni del traffico UDP. La procedura diagnostica dettagliata è disponibile in Verificare MTU e MSS in caso di problemi VPN.

Regole firewall, NAT e Web Proxy

Il bridge non aggira il firewall stateful. Nell’esempio, il traffico dei client richiede una regola da LAN a WAN. Come Source Network si utilizza 10.20.0.0/24 o un oggetto più specifico; Destination e Service devono essere limitati a quanto effettivamente necessario. Durante il collaudo, il logging rimane attivo.

Per definire l’ordine delle regole, la corrispondenza delle zone o le funzioni di protezione, consultare la procedura introduttiva completa in Configurare le regole firewall su Sophos Firewall. Per il bridge è determinante la zona del membro attraverso il quale il frame specifico entra e quella del membro attraverso il quale esce.

I pacchetti di risposta di una connessione consentita e stabilita dall’interno ritornano sfruttando lo stato esistente. Non è necessaria un’ampia regola WAN-to-LAN. Le nuove connessioni in ingresso richiedono invece una regola distinta e deliberatamente limitata.

Un bridge senza indirizzo IP presenta una classe di errore insolita. Se il traffico corrisponde a una regola firewall con Web Proxy Filtering o a una regola NAT, SFOS può scartare i pacchetti senza registrare alcuna voce nel Log Viewer. In questo caso, un log vuoto non dimostra che non sia coinvolta alcuna regola.

Se la regola NAT è necessaria, abilitare al suo interno Override source translation for specific outbound interfaces. Impostare Outbound interface sul bridge e Translated source (SNAT) su Original. In questo modo l’indirizzo sorgente viene mantenuto per questa specifica uscita. Una modifica globale del NAT sarebbe un test inadeguato, perché influirebbe su altri percorsi dati e nasconderebbe l’errore effettivo.

Web Proxy Filtering deve essere utilizzato su un bridge trasparente senza IP soltanto se l’architettura e la versione di SFOS in uso lo prevedono espressamente. Per la normale ispezione inline, le regole basate su DPI costituiscono il punto di partenza più comprensibile.

Collaudare il percorso dati e circoscrivere gli errori

Collaudo dopo il salvataggio

Dopo il salvataggio, verificare separatamente la configurazione, il traffico utente e la condizione di errore:

1. In Network > Interfaces, confrontare con il progetto il nome del bridge, il nome hardware, i membri, le zone, la modalità IP, la MTU ereditata e lo stato del collegamento.
2. Dal client di test, avviare un servizio necessario e confermare nel Log Viewer la Firewall Rule ID prevista.
3. Confrontare ingresso e uscita in Packet Capture. Gli indirizzi MAC sorgente e destinazione, il tag VLAN, l’EtherType e l’interfaccia devono corrispondere alla topologia.
4. Testare un servizio consentito in entrambe le direzioni. Avviare quindi un servizio deliberatamente non consentito e verificare lo scarto previsto.
5. Verificare DNS, gateway predefinito e un’applicazione aziendale tipica. Un singolo ping non è sufficiente.
6. Verificare nuovamente l’accesso di gestione tramite la porta indipendente.
7. Se si utilizza STP, attivare un percorso ridondante soltanto durante una finestra di manutenzione e misurare il tempo di commutazione e la perdita di pacchetti.
8. In presenza di HA, dopo un cambio di ruolo controllato verificare nuovamente bridge, membri, apprendimento MAC e applicazioni.

Nessun traffico e nessuna voce di log

Se nel Log Viewer non compaiono né Allow né Drop, verificare innanzitutto i casi particolari del bridge:

• Il bridge è privo di indirizzo IP?
• Il flusso corrisponde a una regola NAT?
• La regola firewall utilizza Web Proxy Filtering?
• L’override SNAT per questo bridge è impostato su Original?
• Packet Capture rileva il frame sul membro di ingresso, ma non su quello di uscita?

Soltanto in seguito conviene cercare un normale problema nell’ordine delle regole o nel percorso di ritorno. In questo modo si evita di rispondere a uno scarto del bridge non registrato introducendo regole Allow sempre più permissive.

Una VLAN o un EtherType viene scartato

In System services > Log settings > Firewall, abilitare il componente Bridge ACLs. Nel Log Viewer sarà quindi possibile filtrare per Log component > Bridge ACLs e, in aggiunta, per i sottotipi ARP broadcasts, EtherType filtering o VLAN filtering.

Per i problemi VLAN, verificare congiuntamente lo stato tagged/untagged, l’elenco delle VLAN consentite e il profilo della porta dello switch. Per i problemi EtherType, Packet Capture mostra quale ID esadecimale di quattro cifre è effettivamente presente. Il filtro e il dispositivo all’altro capo devono descrivere lo stesso percorso dati.

Il traffico funziona in una sola direzione

Un flusso unidirezionale indica in genere una zona errata, una regola mancante, un routing asimmetrico o una voce MAC non appresa. In Packet Capture, confrontare il percorso di andata e quello di ritorno su entrambi i membri. Verificare quindi Rule ID, Source NAT, gateway e tabella MAC.

Loop o indirizzi MAC instabili

Un numero elevato di broadcast, associazioni MAC che cambiano e collegamenti instabili indicano un loop o una ridondanza cablata in modo errato. Scollegare il secondo percorso prima di modificare altri filtri. Verificare quindi come un’unica architettura lo STP degli switch, lo STP di SFOS, il cablaggio HA e i membri effettivi del bridge.

Un’architettura HA non deve presupporre che il firewall possa abilitare contemporaneamente la propria opzione STP. Se la prevenzione dei loop è affidata agli switch, il test di failover deve dimostrare che non si generi né un loop né il blocco permanente di un percorso di produzione.

Per interpretare nel dettaglio Interface, Rule ID, Status e Reason, è possibile utilizzare anche la procedura descritta in Packet Capture su Sophos Firewall. Il collaudo del bridge è comunque descritto per intero in questa pagina.

Controlli avanzati nella Device Console

La configurazione ordinaria deve essere eseguita in WebAdmin. system bridge offre tre controlli aggiuntivi. Questi comandi non sostituiscono una regola firewall mancante né un’architettura Layer 2 non definita. Prima di apportare modifiche, documentare nome del bridge, nome hardware, membri, ID delle porte, tabella MAC, percorso di gestione e stato CLI corrente.

Gestire il traffico sconosciuto non instradabile

bypass-firewall-policy riguarda il traffico bridge non instradabile al quale non viene applicata alcuna Security Policy. SFOS distingue tra dynamic e static. Per visualizzare lo stato corrente, utilizzare:

system bridge bypass-firewall-policy unknown-network-traffic show dynamic
system bridge bypass-firewall-policy unknown-network-traffic show static

Le azioni possibili sono allow e drop. allow inoltra esplicitamente il traffico interessato senza applicare una Firewall Policy. La guida di SFOS 22 non specifica né un valore predefinito né l’esatta distinzione tra dynamic e static. Qualsiasi modifica deve pertanto rientrare in un caso concreto seguito dal supporto Sophos. Successivamente, verificare lo stato CLI, Packet Capture e un flusso di test consentito e uno bloccato.

Questa opzione non equivale né a LAN Bypass né a una stateful Firewall Bypass Rule. Non attiva un percorso fail-to-wire e non esclude una connessione nota dalla stateful inspection.

Impostare in modo mirato voci MAC statiche

La Bridge Forwarding Table apprende normalmente gli indirizzi MAC in modo dinamico. static-entry associa in modo permanente un indirizzo MAC a bridge, interfaccia e porta. Il modello di comando ufficiale è:

system bridge static-entry [add | delete | show] [interface] {interface ID} [bridge name] [Port] {PortID} [macaddr] {MAC Address} [priority] [dynamic | static]

Le parentesi descrivono la sintassi e non devono essere incluse nel comando. Prima di utilizzare add, verificare gli ID effettivi mediante show e la corrispondenza in WebAdmin. Una voce errata o obsoleta può indirizzare i frame verso la porta sbagliata. Per il rollback, rimuovere con delete esattamente la voce documentata. Verificare quindi nuovamente l’apprendimento MAC, i percorsi di andata e ritorno e l’accesso di gestione.

Non utilizzare il limite dei membri come obiettivo di scalabilità

Per visualizzare il limite interno corrente, utilizzare:

system bridge max_bridge_members show

La Device Console accetta per max_bridge_members valori compresi tra 2 e 256 e mette a disposizione anche reset:

system bridge max_bridge_members set limit <2-256>
system bridge max_bridge_members reset

I due limiti ufficiali non coincidono e non viene fornita alcuna spiegazione. La guida di WebAdmin indica un massimo di 64 membri, mentre quella della Device Console documenta valori da 2 a 256. Non viene chiarita la relazione tra queste indicazioni. Pertanto, dal solo intervallo della CLI non si può dedurre che un valore superiore a 64 sia ammesso per un’architettura di produzione.

Prima di apportare una modifica, registrare lo stato corrente mediante show. Se in precedenza era attivo il valore predefinito, il ripristino avviene tramite reset. Se era impostato un limite personalizzato, ripristinare esattamente quel valore con set limit <valore precedente>. Eseguire quindi nuovamente show per confermare lo stato previsto.

Rimuovere il bridge in sicurezza

Prima dell’eliminazione, documentare Object Usage, regole, NAT, VLAN, DHCP, route, host, zone dei membri e accesso di gestione. Creare innanzitutto un percorso sostitutivo e collaudarlo con traffico reale. Soltanto in seguito rimuovere le dipendenze di produzione, eliminare il bridge e riassegnare i membri in modo controllato.

Dopo la rimozione, verificare nuovamente gateway, DNS, gestione, applicazioni di produzione, Firewall Rule ID e percorso di ritorno. La modifica è conclusa soltanto quando questi test corrispondono allo stato iniziale documentato.

Domande frequenti