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.
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’IP direttamente raggiungibile del peer con cui viene stabilita la sessione BGP.
• Un Network è un prefisso locale che il firewall deve annunciare al peer.

BGP non autorizza il traffico dati e non lo cifra. La sessione BGP stessa viene stabilita tramite TCP 179 e autorizzata verso il firewall mediante Device Access o una Local Service ACL. Il traffico dati che utilizza una route appresa necessita comunque di regole firewall appropriate, di un percorso di ritorno funzionante e, a seconda del design, di 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.
• Le reti da annunciare esistono già come route corrispondenti nella tabella di routing locale.
• 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ù sicura di un’autorizzazione estesa all’intera zona. In Administration > Device access > Local service ACL exception rule > Add, creare una regola Accept per la zona del peer, l’IP specifico del peer o una rete di transito restrittiva, l’indirizzo firewall necessario e il servizio Dynamic Routing. Verificare quindi l’accesso dall’IP autorizzato del peer e da una sorgente non autorizzata.

Device Access controlla solo la connessione BGP verso il firewall. Le connessioni produttive tra le due LAN necessitano successivamente di normali regole firewall. Proteggere Device Access su Sophos Firewall spiega questa separazione.

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).

Un Network non crea una route. Il prefisso deve già esistere esattamente nella tabella di routing locale, ad esempio come rete connessa direttamente o route statica. Se manca o la maschera non corrisponde, la sessione BGP può rimanere Established, ma il Network non viene annunciato.

Devono essere inseriti solo i prefissi realmente necessari. Una ridistribuzione indiscriminata delle route connesse o statiche può includere anche reti WAN, di gestione o blackhole e deve essere utilizzata in produzione solo con filtri verificati.

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
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.

Route Precedence e selezione del percorso BGP

system route_precedence non decide tra BGP e una route statica. L’impostazione globale ordina soltanto le categorie static, sdwan_policyroute e vpn; in questo contesto BGP e le altre route dinamiche appartengono alla categoria static.

La 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.

L’ordine globale attuale può essere visualizzato in 4. Device Console:

system route_precedence show

Dovrebbe essere modificato solo quando le categorie di routing sono realmente in concorrenza. Modificare la priorità di routing su Sophos Firewall spiega le relazioni e fornisce esempi sicuri.

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. Sul firewall che invia, il Network deve esistere nella tabella di routing locale con esattamente la stessa maschera. Controllare quindi Networks, filtri e show running-config. Una route locale mancante deve essere corretta e non nascosta disattivando BGP Network Import Check.

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. Confrontare la configurazione salvata, ripristinare i valori tramite CLI e salvarli con write.

Verificare i log BGP e di routing

In 5. Device Management > 3. Advanced Shell, due file di log mostrano i diversi livelli:

tail -f /log/bgpd.log

bgpd.log registra gli eventi BGP e BGPv6. L’output in tempo reale viene terminato con Ctrl+C. Se BGP conosce una route ma questa non compare nel sistema, utilizzare:

tail -f /log/zebra.log

Per leggere il log senza seguirlo in tempo reale, utilizzare ad esempio:

less /log/bgpd.log

Con IPsec route-based, /log/xfrmi.log può inoltre spiegare lo stato dell’interfaccia XFRM. La classificazione degli altri file è disponibile in Servizi e file di log di Sophos Firewall.

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.

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.