Configurare e verificare BGP su Sophos Firewall

BGP scambia route selezionate tra router. Su Sophos Firewall è particolarmente utile con più sedi, collegamenti ridondanti e VPN AWS o Azure. Per una singola rete di destinazione con Next Hop fisso, una route statica rimane generalmente più semplice.

Nell’esempio seguente, due Sophos Firewall stabiliscono una sessione eBGP attraverso una rete di transito. Al termine, il Neighbor è Established, Firewall A conosce la LAN dietro Firewall B e viceversa.

⚠️ Dynamic Routing dovrebbe essere raggiungibile solo dal peer previsto. Una modifica del Router ID interrompe tutte le sessioni BGP; una modifica del Local AS elimina inoltre tutti i Neighbors e Networks configurati. Entrambe le modifiche devono quindi essere eseguite in una finestra di manutenzione pianificata e con un backup aggiornato.

BGP in sette passaggi

Per una semplice configurazione IPv4 sono necessari questi passaggi:

1. Definire gli IP di transito, gli ASN locali e remoti e le reti da annunciare.
2. Verificare la raggiungibilità IP diretta tra i due peer BGP.
3. In Administration > Device access, consentire Dynamic Routing solo per la zona del peer oppure tramite una Local Service ACL Exception restrittiva; verificare separatamente le regole firewall richieste dal design.
4. Impostare Router ID e Local AS in Routing > BGP.
5. Aggiungere l’IP del peer come Neighbor con il Remote AS.
6. Inserire in Networks solo i prefissi locali necessari.
7. In Routing > Information > BGP-IPv4, verificare lo stato Established, la route appresa e infine il traffico reale.

Cosa decide BGP sul firewall

BGP risponde alla domanda su quali reti siano raggiungibili tramite quale router. Ogni partecipante necessita di alcuni valori chiaramente distinti:

• Il Local AS identifica il proprio sistema autonomo. Due ASN diversi formano una connessione eBGP; lo stesso ASN su entrambi i lati corrisponderebbe a iBGP.
• Il Remote AS è l’ASN del peer.
• Il Router ID identifica il router BGP all’interno della topologia BGP. Ha l’aspetto di un indirizzo IPv4, ma non deve necessariamente essere un indirizzo di interfaccia e dovrebbe rimanere univoco e stabile.
• Un Neighbor è l’indirizzo IPv4 o IPv6 della controparte verso cui viene stabilita la sessione BGP. Nell’esempio è l’IP di transito.
• Un Network è un prefisso locale che il firewall deve annunciare al peer.

BGP non autorizza il traffico dati e non lo cifra. Dynamic Routing in Device Access o una Local Service ACL controlla il servizio BGP locale. Il traffico inoltrato sulle route apprese richiede inoltre regole firewall adeguate, un percorso di ritorno funzionante e, a seconda del design, una configurazione NAT consapevole.

Per il routing dinamico all’interno di un dominio di routing interno continuo, OSPF è spesso la scelta più naturale. BGP è più adatto tra sistemi autonomi diversi, verso provider cloud o quando le route devono essere influenzate in modo mirato tramite policy.

Pianificare la topologia di esempio

L’esempio utilizza due sedi:

• Firewall A: Local AS 65010, Router ID 192.0.2.10, IP di transito 198.51.100.1/30, LAN 10.10.10.0/24
• Firewall B: Local AS 65020, Router ID 192.0.2.20, IP di transito 198.51.100.2/30, LAN 10.20.20.0/24
• Rete di transito: 198.51.100.0/30

Gli intervalli 192.0.2.0/24 e 198.51.100.0/24 sono reti di documentazione. Devono essere sostituiti con i valori effettivi dell’ambiente. I due ASN privati sono adatti a un esempio interno; per una connessione ad AWS, Azure o a un provider si utilizzano i valori ASN e peer indicati dalla controparte.

Il Router ID dovrebbe essere scelto consapevolmente e rimanere univoco e stabile. Con Automatic, SFOS utilizza l’IP di interfaccia più alto. Se questo cambia in seguito, anche l’identità del router può cambiare in modo imprevisto. Un valore manuale evita questa dipendenza.

Preparare BGP in modo sicuro

Prima della configurazione devono essere soddisfatti i seguenti requisiti:

• Il firewall funziona in Gateway Mode. BGP non è disponibile in Transparent Mode.
• I due IP di transito si raggiungono direttamente. Con un tunnel XFRM, anche l’interfaccia del tunnel deve essere up.
• Local AS, Remote AS, IP dei peer e prefissi consentiti sono stati concordati con la controparte.
• La tabella di routing locale e i Networks pianificati sono documentati, in modo da poter verificare in modo mirato ogni annuncio dopo la configurazione.
• Sono disponibili un backup aggiornato della configurazione e un accesso di gestione indipendente.
• Le regole firewall e i percorsi di ritorno per il successivo traffico dati sono stati pianificati.

Configurare zone e interfacce su Sophos Firewall spiega le basi dell’interfaccia di transito e della zona. Prima di modificare un ambiente di routing produttivo, dovrebbe inoltre essere disponibile un backup aggiornato del firewall al di fuori dell’appliance.

Autorizzare Dynamic Routing in modo mirato

In Administration > Device access, Dynamic Routing è disattivato per impostazione predefinita in tutte le zone. Per una rete dedicata esclusivamente al transito, il servizio può essere attivato nella relativa zona.

Se l’interfaccia del peer condivide la propria zona LAN o WAN con altre reti, una Local Service ACL Exception per l’IP specifico del peer o per la rete di transito è più restrittiva dell’abilitazione estesa all’intera zona. In Administration > Device access > Local service ACL exception rule > Add, creare una regola Accept con i valori appropriati per IP version, Source zone, Source networks and hosts, Destination hosts, il servizio Dynamic Routing e Rule position. Verificare quindi l’accesso dall’IP autorizzato del peer e da una sorgente non autorizzata.

La guida BGP di Sophos richiede inoltre regole firewall per il traffico BGP in entrata e in uscita. Allo stesso tempo, la guida di Device Access afferma che i servizi locali non sono controllati dalle regole firewall. Queste formulazioni non sono perfettamente coerenti. Occorre quindi tenere separati la Local Service ACL per il servizio BGP locale, le regole richieste dal design del tunnel o del provider e le normali regole per il traffico dati instradato. Ciò non giustifica una regola generale Any-to-Any per TCP 179. Proteggere Device Access su Sophos Firewall descrive più in dettaglio il livello di accesso locale.

Configurare BGP in WebAdmin

I passaggi seguenti vengono eseguiti su entrambi i firewall. Vengono scambiati solo i valori locali e remoti.

1. Impostare Router ID e Local AS

In Routing > BGP, inserire in Global configuration i seguenti valori su Firewall A:

Se esiste già una configurazione BGP, documentare lo stato corrente prima di applicare le modifiche: una modifica del Router ID reimposta tutte le sessioni BGP; una modifica del Local AS elimina tutti i Neighbors e Networks. Queste modifiche devono essere applicate solo in una finestra di manutenzione pianificata.

• Router ID assignment: Manual
• Router ID: 192.0.2.10
• Local AS: 65010

Su Firewall B utilizzare ugualmente Manual, insieme a 192.0.2.20 e 65020. Applicare quindi la configurazione globale.

Local AS accetta valori da 1 a 4294967295. Per ambienti interni senza ASN pubblico, Sophos indica l’intervallo privato da 64512 a 65535.

2. Aggiungere la controparte come Neighbor

In Routing > BGP > Neighbors, fare clic su Add e inserire su Firewall A:

• IP version: IPv4
• IP address: 198.51.100.2
• Remote AS: 65020

Firewall B utilizza 198.51.100.1 come Neighbor e 65010 come Remote AS. Salvare ogni voce con Save.

L’indirizzo del Neighbor non è la LAN remota né il Router ID, ma l’IP di transito direttamente raggiungibile del peer. Se questo IP non è raggiungibile o gli ASN sono invertiti, la sessione non può raggiungere lo stato Established.

3. Annunciare la LAN locale

In Routing > BGP > Networks, fare clic su Add. Firewall A annuncia:

• IP version: IPv4
• IP address: 10.10.10.0
• Subnet mask: 255.255.255.0 (/24)

Su Firewall B vengono inseriti invece 10.20.20.0 e 255.255.255.0 (/24).

La voce Network definisce il prefisso da annunciare; non sostituisce né la route locale né una regola firewall. Verificare il prefisso annunciato e quello ricevuto dal peer. Inserire solo i prefissi necessari.

Inquadrare Neighbor e reti IPv6

SFOS supporta IPv6 anche nelle sezioni Neighbors e Networks. L’esempio precedente rimane volutamente su IPv4; per IPv6 occorre inserire separatamente la versione IP, un indirizzo IPv6 del peer direttamente raggiungibile e il prefisso IPv6.

WebAdmin aggiunge automaticamente la separazione necessaria. In una configurazione solo CLI, i default sono asimmetrici: i Networks IPv4 sono inizialmente attivi per tutti i Neighbors, inclusi quelli IPv6. I Networks IPv6 non sono attivi per alcun Neighbor. Per un Neighbor IPv6 impostare esplicitamente questi stati:

address-family ipv4 unicast
no neighbor <ipv6-neighbor> activate
exit
address-family ipv6 unicast
neighbor <ipv6-neighbor> activate

Per riprodurre i default WebAdmin in CLI, Sophos indica anche no bgp ebgp-requires-policy e bgp log-neighbor-changes. show running-config mostra solo valori diversi dai default; una Router ID automatica e, per esempio, maximum-paths ibgp 16 possono non apparire. Collaudare IPv4 e IPv6 separatamente in Routing > Information > BGP-IPv4 e BGP-IPv6, comprese regole IPv6 e percorsi di ritorno.

Verificare e collaudare BGP

Una sessione stabilita da sola non conferma che il flusso dei pacchetti funzioni. Il collaudo avviene quindi a più livelli:

1. In Routing > Information > BGP-IPv4 > Neighbors, il peer deve comparire nello stato Established.
2. In Routes, Firewall A deve mostrare il prefisso 10.20.20.0/24; Firewall B deve mostrare 10.10.10.0/24.
3. In Summary, controllare la sessione e il numero di prefissi ricevuti.
4. In Diagnostics > Tools > Route lookup, verificare ad esempio la destinazione 10.20.20.10 su Firewall A.
5. Eseguire quindi un test con un servizio reale tra un host di ciascuna LAN. Log Viewer e Packet Capture devono mostrare la regola prevista, l’interfaccia di transito corretta e il traffico di ritorno.

Un Neighbor in stato Established dimostra solo che lo scambio BGP funziona. Solo la route appresa, un Route Lookup corretto e una connessione reale confermano l’intera configurazione. Testare una regola Sophos Firewall con Log Viewer e Packet Capture aiuta a verificare il flusso dei pacchetti.

Lo stesso esempio tramite CLI

In alternativa a WebAdmin, la stessa configurazione di base può essere inserita nella CLI BGP dopo l’accesso tramite SSH. I comandi seguenti non devono essere eseguiti in aggiunta su un ambiente di esempio già completamente configurato. Il percorso di menu è:

3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP

Su Firewall A, l’esempio completo è il seguente:

enable
configure terminal
router bgp 65010
no bgp ebgp-requires-policy
bgp log-neighbor-changes
bgp router-id 192.0.2.10
neighbor 198.51.100.2 remote-as 65020
address-family ipv4 unicast
network 10.10.10.0/24
exit
show running-config
write
end

Su Firewall B, Local AS, Router ID, Neighbor, Remote AS e Network vengono sostituiti rispettivamente con 65020, 192.0.2.20, 198.51.100.1, 65010 e 10.20.20.0/24.

show running-config serve per il controllo. write salva in modo permanente la configurazione CLI, rende visibili le voci in WebAdmin e le mantiene dopo un riavvio. Senza write, la modifica non è completamente conclusa.

Il controllo aggiuntivo documentato ufficialmente è:

show ip bgp

Mostra i prefissi BGP conosciuti e le relative informazioni sul percorso. Lo stato del Neighbor e Summary vengono verificati in modo affidabile in Routing > Information > BGP-IPv4.

⚠️ Non combinare senza controllo la configurazione CLI avanzata e WebAdmin. La modifica di un Neighbor in WebAdmin può rimuovere valori CLI aggiuntivi, come una password del Neighbor o una Route Map. Quando vengono utilizzate queste impostazioni, salvare prima show running-config e continuare a gestire la configurazione BGP tramite CLI.

Weight, MED e Route Precedence globale

La Route Precedence globale ordina static, sdwan_policyroute e vpn. Tenerla separata dagli attributi utilizzati da BGP per selezionare i propri percorsi. system route_precedence show visualizza il valore corrente; modificarla solo quando queste categorie competono realmente. Modificare la priorità di routing su Sophos Firewall spiega la verifica e il rollback.

L’Administrative Distance è uno dei criteri che determinano la scelta tra protocolli di routing diversi. All’interno di BGP vengono valutati gli attributi BGP. Sophos indica ad esempio che un Weight più alto è preferito; tra percorsi altrimenti confrontabili viene preferito un MED più basso.

Questo aspetto è particolarmente importante quando lo stesso prefisso è disponibile tramite redistribute ospf e viene anche appreso da un BGP Neighbor. Per impostazione predefinita, la route redistribuita e generata localmente ha Weight 32768, mentre la route appresa dal Neighbor ha Weight 0. Senza una modifica intenzionale, prevale quindi la route redistribuita. Per preferire il percorso tramite il peer, impostarne un Weight più alto e verificare poi la route risultante.

Usare MED per più percorsi di ingresso

Il Multi-Exit Discriminator (MED) indica a un AS vicino diretto quale di più percorsi di ingresso nell’AS locale deve preferire. Un MED inferiore è migliore e il default è 0. Sul percorso meno desiderato si annuncia quindi un valore superiore. Per default, MED viene confrontato solo quando lo stesso prefisso arriva su più link dallo stesso AS vicino.

MED non è transitivo. Se l’AS ricevente inoltra la route a un altro AS, il valore torna a 0. BGP valuta prima Weight, Local Preference, origine locale, lunghezza AS Path e Origin Type. MED decide solo se questi attributi sono uguali. Un valore configurato non prova che vinca il percorso desiderato.

Sophos imposta MED tramite una Route Map in uscita con un numero di sequenza fisso e la associa a un Neighbor specifico nell’IPv4 Address Family. out modifica l’annuncio inviato a quel peer; non impone direttamente il percorso del traffico in uscita da Sophos Firewall. La pagina ufficiale di SFOS 22 documenta la configurazione, ma non una procedura di rollback completa. Applicare la modifica solo dopo aver confermato separatamente i comandi di rimozione esatti per la build installata e averli documentati in un piano di ripristino insieme al show running-config salvato in precedenza.

Dopo una modifica approvata, show ip bgp sul router ricevente deve mostrare il MED previsto e il percorso preferito. Su un peer Sophos, la route è disponibile anche in Routing > Information > BGP-IPv4 > Routing. Senza questo confronto prima e dopo, la sezione rimane un supporto decisionale e non una modifica di produzione direttamente eseguibile.

BGP tramite IPsec route-based e VPN cloud

BGP può funzionare su un’interfaccia XFRM indirizzata di un tunnel IPsec site-to-site route-based. A entrambe le interfacce XFRM vengono assegnati IP di transito appropriati. Dynamic Routing viene autorizzato in modo mirato per la zona VPN; le regole per il traffico dati rimangono comunque necessarie.

Per le connessioni cloud, i valori non vengono scelti liberamente:

• Per AWS Site-to-Site VPN, gli indirizzi inside del tunnel, il Remote AS e gli altri valori del tunnel provengono dalla configurazione AWS. Entrambi i tunnel AWS vengono verificati separatamente.
• Con Azure VPN Gateway, l’IP XFRM locale deve corrispondere all’IP previsto del peer BGP; l’ASN locale e quello Azure devono essere diversi.

Un tunnel IPsec verde e un BGP Neighbor in stato Established sono due controlli distinti. Successivamente devono funzionare i prefissi previsti e il traffico applicativo reale.

Individuare gli errori in modo sistematico

Neighbor rimane su Active o non viene visualizzato

Active non significa che la sessione funzioni. Il firewall continua a tentare di stabilire una connessione BGP. Verificare prima la raggiungibilità diretta dell’IP del peer, lo stato dell’interfaccia e del tunnel, Local AS, Remote AS e l’IP del Neighbor. Controllare quindi se Dynamic Routing è autorizzato nella zona corretta o tramite una Local Service ACL Exception appropriata.

Con XFRM, verificare inoltre che entrambi gli indirizzi del tunnel siano corretti e che il tunnel IPsec sia up. Nelle configurazioni cloud e XFRM, controllare anche le regole previste dal rispettivo design VPN. Se i relativi servizi sono limitati, devono includere TCP 179 tra i due IP dei peer. Device Access o la Local Service ACL per il servizio BGP locale rimangono separati da queste regole.

Neighbor è Established, ma manca la rete remota

La sessione funziona, ma il prefisso non viene annunciato o accettato. Controllare la voce Network, la relativa versione IP e la maschera, nonché show running-config; quindi verificare in Routes e Summary sul peer se il prefisso arriva o viene rifiutato da una policy.

Se dopo un upgrade a SFOS 22 manca una rete dietro un tunnel IPsec policy-based, la causa può essere la precedente dipendenza da redistribute kernel. La sessione BGP può rimanere Established; SFOS 22: route IPsec e redistribute kernel spiega il cambiamento di versione e il design di destinazione XFRM route-based.

La route BGP è visibile, ma non viene utilizzata

Utilizzare prima Route Lookup per determinare quale route vince per uno specifico IP di destinazione. Una route più specifica ha la precedenza su un prefisso più ampio. Se più sorgenti sono in concorrenza, valutare separatamente Administrative Distance e attributi BGP e solo successivamente la categoria globale Route Precedence.

La route è corretta, ma il traffico non funziona

BGP ha completato il proprio compito quando è installata la route corretta. Gli errori si trovano quindi generalmente nella regola firewall, nel NAT, nel percorso di ritorno o nel sistema di destinazione. Per reti di sedi normalmente instradate, spesso non è necessario SNAT perché entrambi i lati dovrebbero conoscere i reali prefissi LAN.

Le impostazioni avanzate sono scomparse dopo una modifica in WebAdmin

WebAdmin espone solo i valori di base. Se un Neighbor è stato salvato da WebAdmin dopo una configurazione CLI avanzata, la password, la Route Map o i default modificati potrebbero essere stati rimossi. Anche l’applicazione della Global configuration rimuove le modifiche a bgp log-neighbor-changes e no bgp ebgp-requires-policy. Confrontare la configurazione salvata, ripristinare i valori tramite CLI e salvarli con write.

Associare i log BGP e di routing

La documentazione di riferimento dei log di SFOS 22 associa BGP e BGPv6 al file bgpd.log. zebra.log riguarda l’installazione delle route dinamiche IPv4 e IPv6 nel kernel; per IPsec route-based, xfrmi.log riguarda l’interfaccia del tunnel XFRM. Questa associazione consente una diagnosi per fasi: prima la sessione BGP e l’annuncio, poi l’inserimento nella tabella di routing del sistema e, se necessario, lo stato del tunnel. Servizi e file di log di Sophos Firewall spiega come accedere a questi e ad altri file. Per questa verifica non sono necessari comandi Live Shell non documentati.

Annullare la modifica in modo sicuro

Prima di rimuovere BGP, per ogni rete di destinazione appresa deve essere disponibile un percorso alternativo o una finestra di manutenzione. Vengono rimossi prima i Networks e Neighbors interessati; la configurazione BGP globale viene modificata solo se nessun altro peer dipende da essa. Dynamic Routing può essere disattivato solo quando la zona non necessita più di alcun altro servizio di routing dinamico.

In WebAdmin, rimuovere prima gli annunci BGP non più necessari in Routing > BGP > Networks, quindi i peer interessati in Neighbors. Verificare le route sostitutive dopo ogni passaggio. Lasciare invariati Router ID e Local AS finché altre connessioni BGP dipendono da essi; una modifica del Local AS eliminerebbe tutti i Neighbors e Networks rimanenti.

Le fonti SFOS 22 esaminate non documentano alcun comando CLI completo per l’eliminazione dell’intero processo BGP; tale comando non viene quindi dedotto né raccomandato. Le policy CLI avanzate richiedono i comandi di rimozione confermati per la build installata e il blocco di configurazione precedente salvato.

Successivamente vengono ricontrollati Routing Information, Route Lookup, accesso di gestione e traffico reale. Un rollback è concluso solo quando non soltanto la sessione BGP è scomparsa, ma tutte le reti di destinazione necessarie rimangono raggiungibili tramite il percorso sostitutivo previsto.