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:

Definire gli IP di transito, gli ASN locali e remoti e le reti da annunciare.
Verificare la raggiungibilità IP diretta tra i due peer BGP.
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.
Impostare Router ID e Local AS in Routing > BGP.
Aggiungere l’IP del peer come Neighbor con il Remote AS.
Inserire in Networks solo i prefissi locali necessari.
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:

In Routing > Information > BGP-IPv4 > Neighbors, il peer deve comparire nello stato Established.
In Routes, Firewall A deve mostrare il prefisso 10.20.20.0/24; Firewall B deve mostrare 10.10.10.0/24.
In Summary, controllare la sessione e il numero di prefissi ricevuti.
In Diagnostics > Tools > Route lookup, verificare ad esempio la destinazione 10.20.20.10 su Firewall A.
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 di routing dopo l’accesso SSH. Non eseguire i comandi seguenti su un ambiente di esempio già configurato. Salvare lo stato corrente prima delle modifiche; cambiare ASN elimina Neighbors e Networks e richiede un backup e una finestra di manutenzione. L’accesso dipende dalla versione SFOS.

SFOS 22: il seguente percorso di menu apre bgp>. Solo questo accesso inizia con enable:

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

Su Firewall A senza ASN ancora assegnato:

enable
configure terminal
router bgp 65010

SFOS 23: 3. Route Configuration > 1. Configure Unicast Routing apre direttamente router#; né la terza selezione di menu né enable fanno parte di questo accesso. Per assegnare l’ASN per la prima volta su Firewall A:

configure terminal
router bgp 65010

Se l’ASN è già assegnato in SFOS 23, usare invece router bgp senza ASN dopo configure terminal per selezionare la configurazione esistente. router bgp 65010 serve per l’assegnazione iniziale o una modifica pianificata dell’ASN, non per una riassegnazione incontrollata.

Dopo una sola di queste sequenze di accesso, proseguire in modalità di configurazione BGP:

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
end
show running-config
write

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.

end esce dalla modalità di configurazione prima di questi due comandi. Per SFOS 23, Sophos documenta la conferma di salvataggio attesa Integrated configuration saved to /conf/routing/frr.conf; non è un output osservato qui su un’appliance. Confrontare quindi la configurazione e le voci WebAdmin con i valori previsti.

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.

SFOS 23.0: BFD sperimentale per BGP

Bidirectional Forwarding Detection (BFD) monitora la raggiungibilità di un Neighbor BGP tramite propri pacchetti di controllo. In questo modo, il firewall può rilevare un guasto prima rispetto all’utilizzo dei soli timer BGP. Questa procedura opzionale non fa parte della configurazione BGP di base descritta in precedenza e non si applica alle versioni SFOS precedenti.

⚠️ In SFOS 23.0, BFD è sperimentale. L’utilizzo documentato riguarda BGP in deployment standalone; questo non implica il supporto per cluster HA o altri protocolli di routing. Per altri protocolli è necessario coinvolgere Sophos Support. Avanet consiglia di iniziare in un ambiente di test isolato. BFD non deve essere attivato in produzione senza una procedura di ripristino confermata per la build installata.

Ambito di applicazione e preparazione

Sophos indica come casi d’uso BFD i Neighbor BGP IPv4 e IPv6, nonché eBGP, iBGP, eBGP multihop e i Neighbor Route Reflector. L’esempio seguente rimane sul Neighbor IPv4 198.51.100.2 già configurato su Firewall A. Non costituisce un’ulteriore garanzia per uno specifico servizio VPN cloud o una determinata topologia multihop.

Prima di iniziare, la sessione BGP, i prefissi previsti e il traffico applicativo devono funzionare senza BFD. La controparte deve essere predisposta per BFD; gli indirizzi dei peer, la raggiungibilità e i timer devono essere concordati con il suo amministratore. Registrare la build SFOS corrente e salvare show running-config, lo stato del Neighbor e il risultato di Route Lookup; predisporre inoltre un backup, una finestra di manutenzione e un accesso di gestione indipendente. Chiarire preventivamente con Sophos Support, per questa build, la procedura di rimozione dell’associazione BFD al Neighbor, di un eventuale profilo peer aggiuntivo e del servizio. La guida BFD non documenta comandi completi di rimozione o arresto a questo scopo.

Se il Neighbor monitorato diventa irraggiungibile, il firewall rimuove immediatamente dalla tabella di routing tutte le route apprese da quel Neighbor. Il traffico può passare a un percorso alternativo solo se questo è disponibile; in sua assenza, le reti interessate perdono la propria route. Al ritorno del Neighbor, Sophos descrive il ripristino delle route e il ritorno al percorso originale. Occorre quindi verificare sia il guasto sia il ripristino, inclusa la route effettivamente selezionata.

Avviare il servizio e monitorare il Neighbor

Il servizio BFD è disattivato per impostazione predefinita. I comandi seguenti modificano il funzionamento del routing; prima di eseguirli, devono essere disponibili lo stato iniziale salvato e la procedura di ripristino confermata. Accedere tramite CLI a 5. Device Management > 3. Advanced shell e avviare il servizio:

service -ds nosync bfdd:start

Quindi, nella stessa Advanced Shell, passare alla CLI di routing con vtysh:

vtysh

Nella CLI di routing, aggiungere l’associazione BFD per il Neighbor già esistente su Firewall A. Router ID, Local AS, Remote AS e Networks rimangono invariati:

configure terminal
router bgp
neighbor 198.51.100.2 bfd
end
write

Sostituire 198.51.100.2 con l’indirizzo effettivo del Neighbor, non con la sua LAN o il suo Router ID. Su Firewall B, l’indirizzo corrispondente nell’esempio è 198.51.100.1. Configurare la controparte secondo la documentazione del relativo prodotto. Se il Neighbor BGP non è ancora presente, completare prima la configurazione BGP di base di questo articolo; BFD non la sostituisce. write salva la configurazione di routing, ma non dimostra né il corretto funzionamento della sessione BFD né l’avvio automatico del servizio dopo un riavvio.

Modificare i timer solo quando necessario

Per il primo test, Avanet consiglia i valori predefiniti documentati: Detect multiplier 3, Transmit interval 300 ms e Receive interval 300 ms. Intervalli molto brevi o un moltiplicatore troppo sensibile possono aumentare il carico di elaborazione. Questi valori non garantiscono un tempo di commutazione fisso.

I timer vengono impostati nella configurazione BFD, non nel comando del Neighbor BGP. Se è necessario un profilo peer esplicito, il seguente blocco nella CLI di routing mostra i valori predefiniti documentati per lo stesso peer dell’esempio:

configure terminal
bfd
peer 198.51.100.2
 detect-multiplier 3
 transmit-interval 300
 receive-interval 300
end
write

peer avvia il monitoraggio del peer con i timer predefiniti; questo blocco aggiuntivo non è necessario per configurare soltanto l’associazione BGP. Per detect-multiplier, Sophos documenta l’intervallo 1–155; per entrambi gli intervalli, 10–4294967 ms. Il valore Transmit indica l’intervallo minimo di invio senza jitter, mentre il valore Receive indica l’intervallo minimo di ricezione previsto. La controparte calcola il proprio tempo di rilevamento utilizzando il moltiplicatore locale e il maggiore tra l’intervallo di invio locale e quello di ricezione remoto. Occorre quindi coordinare entrambi i lati, anziché scegliere soltanto il valore locale più basso possibile. Aggiungere timer direttamente dopo neighbor … bfd non è una sintassi valida.

Collaudare insieme BFD, route e applicazione

Nella CLI di routing, queste due verifiche sono di sola lettura:

show bfd peers
show bfd peers brief

Per il peer previsto, lo stato atteso è Status: up. L’output dettagliato deve mostrare timer locali e remoti appropriati, oltre a Diagnostics: ok e Remote diagnostics: ok; la vista sintetica associa l’indirizzo del peer al suo stato. Verificare quindi nuovamente la sessione BGP in Routing > Information > BGP-IPv4 oppure BGP-IPv6, i prefissi previsti, Route Lookup e il traffico applicativo reale. BFD up da solo non conferma né la route BGP corretta né il percorso dei dati.

Eseguire un test di guasto solo in un ambiente di test autorizzato o durante una finestra di manutenzione pianificata, senza compromettere l’accesso di gestione indipendente. Prima del test, documentare i prefissi appresi dal Neighbor monitorato e il percorso sostitutivo previsto. Durante il guasto controllato del peer, le route interessate devono scomparire e, se disponibile, la route sostitutiva deve essere utilizzabile e il traffico applicativo deve funzionare. Dopo il ripristino, verificare nuovamente BFD up, BGP, i prefissi ripristinati, il percorso selezionato e l’applicazione. Nessun output del dispositivo o esito positivo della commutazione viene qui presentato come già verificato mediante test.

Individuare gli errori e annullare la modifica

Il peer manca o rimane down: verificare l’avvio del servizio e l’associazione BFD in show running-config, quindi confrontare l’indirizzo effettivo del peer, la raggiungibilità e la configurazione BFD della controparte. Rilevare le diagnosi locali e remote e i timer con show bfd peers. Non aggiungere un’autorizzazione Any-to-Any estesa come soluzione generica; se i requisiti di accesso non sono chiari, coinvolgere Sophos Support.
BFD non funziona più dopo una modifica: le modifiche a impostazioni correlate, come l’indirizzo di destinazione o il Remote Gateway, possono rimuovere le impostazioni BFD. Confrontare la configurazione con lo stato salvato, configurare nuovamente BFD per il Neighbor interessato ed eseguire un collaudo completo.
Sessione instabile o aumento del carico dopo una modifica dei timer: nello stesso contesto del peer BFD, reimpostare i valori documentati in precedenza e salvarli con write. Se lo stato iniziale utilizzava il profilo predefinito, il blocco precedente mostra 3 e 300 ms. Verificare quindi le diagnosi di entrambi i peer, le route BGP e il traffico prima di modificare altri valori.
Rimozione completa: applicare esclusivamente il piano di ripristino confermato preventivamente per questa build, quindi confrontare la configurazione BGP senza BFD con lo stato iniziale salvato. Né un comando no inventato né l’arresto indiscriminato del servizio sostituiscono questo piano. La rimozione dell’intero Neighbor BGP non sarebbe un rollback BFD equivalente, perché eliminerebbe anche le sue route. Concludere il ripristino solo quando la sessione BGP, i prefissi necessari, l’accesso di gestione e l’applicazione sono nuovamente nello stato previsto.

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

SFOS 23: verificare prima i nomi. Prima di creare o riutilizzare Access Lists, Prefix Lists o Route Maps, inventariarne i nomi in tutti i protocolli di routing dinamico. Sono memorizzati in un unico file di configurazione e i nomi devono essere univoci tra protocolli. Evitare collisioni e verificare le associazioni Neighbor/policy previste rispetto alla configurazione corrente e salvata. Questo requisito non sostituisce il piano di rollback MED confermato per la build installata richiesto di seguito; la configurazione MED eseguibile resta sospesa fino a tale conferma.

Upgrade a SFOS 23.0: Da questa versione, tutti i protocolli di routing dinamico utilizzano una configurazione integrata. Durante l’upgrade da una versione precedente, il firewall aggiunge automaticamente prefissi di protocollo ai nomi di Route Maps, Prefix Lists e Access Lists, ma solo in caso di conflitto di nomi. Aggiorna inoltre automaticamente tutti i riferimenti alle configurazioni rinominate. Questo non significa che tutti gli oggetti vengano rinominati.

Dopo l’upgrade, confrontare i nomi degli oggetti e i riferimenti salvati in precedenza con il show running-config corrente e documentare la corrispondenza tra nomi precedenti e attuali. Verificare che le associazioni Neighbor/Route Map previste puntino ancora alle policy corrette, comprese le associazioni MED esistenti. Non ripristinare alla cieca i nomi precedenti. In Routing > Information > BGP-IPv4 > Routes e con show ip bgp sul peer, verificare che siano presenti i prefissi di rete previsti, che quelli non consentiti siano assenti e che sia selezionato il percorso desiderato; controllare anche il percorso effettivamente utilizzato con Route Lookup. Questa verifica non sostituisce il piano di rollback MED richiesto di seguito per la build installata e non rimuove la sospensione della configurazione MED.

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 > Routes. 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 pagine introduttive BGP esaminate per SFOS 22 e 23 mostrano una sintassi per disattivare la configurazione di routing BGP. Questo però non convalida il contesto completo di esecuzione né un rollback sicuro per la build installata. La sintassi anomala della fonte non viene riprodotta come comando eseguibile né corretta silenziosamente; non se ne deduce un arresto confermato del daemon o l’eliminazione del processo. Non viene raccomandato alcun comando CLI distruttivo. 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.