SFOS 22: redistribute kernel non annuncia più le route IPsec

Dopo un upgrade a SFOS 22, il tunnel IPsec può rimanere attivo e il Neighbor OSPF o BGP può continuare a sembrare operativo. Tuttavia, le reti dietro un tunnel IPsec policy-based possono improvvisamente scomparire dai router adiacenti.

La causa tipica è redistribute kernel: fino a SFOS 21.5, le route VPN policy-based utilizzate in questa procedura potevano essere acquisite dalla tabella di routing del kernel. Con SFOS 22.0 GA, il firewall elabora queste route internamente nel backend VPN. redistribute kernel non riesce quindi più a trovarle.

⚠️ Non creare una route statica dummy, null o blackhole solo per far ricomparire il prefisso in OSPF o BGP. In base a Route Precedence, una route di questo tipo può assumere il controllo del data path e deviare il traffico di produzione dal tunnel oppure scartarlo.

Risposta rapida: cosa fare ora

Se dopo l’upgrade manca una rete VPN annunciata in precedenza, verificare innanzitutto se valgono tutti i punti seguenti:

1. Il firewall è stato aggiornato da SFOS 21.5 o una versione precedente a SFOS 22.
2. Il tunnel interessato è policy-based.
3. OSPF o BGP acquisiva in precedenza le reti VPN tramite redistribute kernel.
4. Il Neighbor rimane Full oppure Established, ma il prefisso previsto manca sul lato ricevente.

In tal caso, una nuova voce ipsec_route non è la soluzione: in SFOS 22 non genera a sua volta una normale route del kernel. Per un design trasparente nel tempo, è consigliabile utilizzare IPsec route-based Any-to-Any con interfacce XFRM indirizzate e una configurazione OSPF o BGP esplicita.

Il controllo per l’upgrade a SFOS 22 aiuta nella preparazione. La configurazione del tunnel è descritta in Configurare una VPN IPsec Site-to-Site.

Perché la route scompare dopo l’upgrade

Una route del kernel è una voce nella normale tabella di routing del sistema operativo. I servizi di routing possono acquisire queste voci come sorgente e, ad esempio, annunciarle ai Neighbor tramite redistribute kernel.

SFOS 22 gestisce IPsec policy-based in modo diverso: il percorso dei pacchetti viene determinato tramite un lookup interno del backend che utilizza marcature, zone e flag. Il tunnel può quindi inoltrare correttamente il traffico anche se la rete VPN associata non compare come una normale route del kernel.

Questo spiega il comportamento apparentemente contraddittorio:

• Il tunnel IPsec è attivo.
• OSPF è Full o BGP Established.
• Il traffico diretto attraverso il tunnel può continuare a funzionare.
• Tuttavia, il prefisso VPN remoto non viene più acquisito dalla tabella di routing del kernel in OSPF o BGP.

La modifica non riguarda OSPF o BGP in generale. Interessa solo un design che si basava sulla disponibilità delle route IPsec policy-based come route del kernel.

Riconoscere la dipendenza prima dell’upgrade

Prima dell’upgrade, una configurazione esistente non deve essere valutata soltanto in base allo stato verde del tunnel. È essenziale capire da dove OSPF o BGP ricava il prefisso da annunciare.

Come esempio viene utilizzata la rete VPN remota 10.60.0.0/16. Si tratta di un valore specifico dell’ambiente, da sostituire con la rete effettivamente annunciata.

Registrare lo stato del firewall e della VPN

In 4. Device Console, documentare innanzitutto Route Precedence e le route IPsec manuali:

system route_precedence show
system ipsec_route show

L’output risponde a due domande differenti: Route Precedence mostra l’ordine globale delle classi di routing. system ipsec_route show mostra le associazioni manuali ai tunnel policy-based. Nessuno dei due comandi dimostra da solo che OSPF o BGP stia effettivamente annunciando il prefisso.

In SFOS 21.5, nell’Advanced Shell si può inoltre registrare se la rete di esempio compare nella tabella di routing utilizzata per IPsec policy-based:

ip route show table 220 | grep '10.60.0.0/16'

Il comando è di sola lettura; il prefisso di ricerca deve essere adattato alla rete reale. In SFOS 22, l’assenza di risultati per IPsec policy-based è prevista e non dimostra che il tunnel stesso sia guasto.

Documentare separatamente OSPF o BGP

Nella CLI di routing corrispondente, salvare la configurazione in esecuzione. Per OSPF sono utili anche questi comandi di sola lettura:

show running-config
show ip ospf neighbor
show ip ospf route

Per BGP, documentare la configurazione insieme ai prefissi BGP noti:

show running-config
show ip bgp

Sul router ricevente, registrare anche se 10.60.0.0/16 viene appreso e quale Next Hop viene utilizzato. Solo così, dopo l’upgrade, è possibile distinguere se il problema riguarda il tunnel, l’adiacenza di routing o l’annuncio del prefisso.

Le procedure complete di verifica sono descritte in Configurare e verificare OSPF e Configurare e verificare BGP.

Scegliere un design di destinazione sicuro

Routing dinamico tramite un’interfaccia XFRM

Quando le reti remote devono essere apprese o ridistribuite dinamicamente, IPsec route-based Any-to-Any rappresenta il design di destinazione più trasparente:

1. Entrambe le estremità del tunnel utilizzano Route-based (Tunnel interface) con sottoreti Any-to-Any.
2. Le interfacce XFRM create automaticamente ricevono indirizzi IP univoci da una rete di transito dedicata.
3. OSPF o BGP stabilisce l’adiacenza tramite questi indirizzi di transito.
4. Le reti previste vengono annunciate esplicitamente nel protocollo di routing oppure ridistribuite da una route realmente esistente e limitata con filtri rigorosi.
5. Le regole firewall consentono il traffico dati tra le zone LAN e VPN.

In questo modo, la route non è più un effetto secondario del tunnel policy-based. XFRM, protocollo di routing e prefissi annunciati possono essere controllati e modificati separatamente.

Preparare la migrazione in una finestra di manutenzione. Le connessioni policy-based e route-based con gli stessi prefissi non devono rimanere attive contemporaneamente senza controllo, perché selector e route sovrapposti possono falsare il test.

Mantenere temporaneamente IPsec policy-based

Non è necessario migrare immediatamente ogni connessione esistente. Se il tunnel rimane policy-based, tuttavia, l’annuncio dei prefissi richiede un design specifico per la topologia e pianificato consapevolmente. Le procedure pubbliche documentate per SFOS 22 non includono un comando di sostituzione generale che renda nuovamente disponibili le route VPN del backend come route del kernel per OSPF o BGP.

redistribute static è appropriato solo se la route statica costituisce il data path effettivamente desiderato e se un’ACL o una Route Map limita la ridistribuzione ai prefissi previsti. Una route aggiuntiva creata solo come sorgente per la ridistribuzione non è un metodo standard sicuro.

Neppure la modifica di system route_precedence ripristina la route del kernel mancante. L’ordine è globale e può cambiare altri percorsi statici, SD-WAN e VPN. Se un conflitto di routing specifico richiede una modifica, Modificare Route Precedence in sicurezza spiega le verifiche e il rollback.

Collaudare la migrazione e il funzionamento

Un test riuscito comprende più livelli distinti:

1. L’interfaccia XFRM è attiva e configurata con l’IP di transito previsto.
2. OSPF raggiunge Full o BGP Established.
3. Vengono annunciati solo i prefissi previsti, che risultano appresi sul lato remoto.
4. Route Lookup e Routing Information mostrano il percorso pianificato per una destinazione concreta.
5. Log Viewer e Packet Capture mostrano la regola firewall prevista e le interfacce di ingresso e uscita.
6. Un servizio reale funziona in entrambe le direzioni e utilizza il percorso di ritorno corretto.
7. Con connessioni WAN ridondanti o HA, testare separatamente un failover controllato.

Route Lookup verifica il percorso di inoltro locale, ma non l’annuncio del prefisso a un Neighbor OSPF o BGP. Occorre quindi valutare insieme Route Lookup, prefisso ricevuto, Neighbor di routing, flusso dei pacchetti e test reale dell’applicazione.

Circoscrivere gli errori in modo sistematico

Il Neighbor è attivo, ma manca il prefisso VPN

Controllare innanzitutto in show running-config se in precedenza la rete raggiungeva OSPF o BGP esclusivamente tramite redistribute kernel. Identificare quindi il tipo di tunnel e il build SFOS. Se si tratta di IPsec policy-based in SFOS 22, la mancanza dell’input dal kernel è la spiegazione più probabile; il Neighbor può rimanere attivo.

Il prefisso viene annunciato, ma il traffico non funziona

In questo caso, la mancata ridistribuzione del kernel non è più la causa immediata. Controllare separatamente Route Lookup, regole firewall, NAT, percorso di ritorno, indirizzo XFRM e Traffic Selectors. Un prefisso annunciato non dimostra che i percorsi di andata e ritorno siano corretti.

ipsec_route è presente, ma OSPF o BGP non acquisisce la rete

Questo comportamento è previsto in SFOS 22. system ipsec_route show mostra l’associazione manuale configurata per il tunnel, ma non conferma né una normale route del kernel né un data path funzionante. Un’altra ipsec_route per la stessa rete non ripristina quindi redistribute kernel. Creare una route IPsec su Sophos Firewall spiega la classificazione esatta e la sintassi Add/Delete sicura.

Il traffico si interrompe dopo l’aggiunta di una route statica sostitutiva

La nuova route può prevalere sul percorso VPN reale. Annullare la modifica utilizzando il comando e il piano di manutenzione documentati in precedenza, controllare Route Precedence e ripetere l’ultimo test riuscito. Non modificare contemporaneamente altre impostazioni di routing, NAT e VPN.

Eseguire il rollback in sicurezza

Prima della migrazione, salvare la connessione policy-based, la configurazione di routing, Route Precedence, le regole e i prefissi ricevuti. Durante il rollback, annullare solo il percorso che è stato modificato:

• rimuovere in modo controllato i nuovi annunci e filtri OSPF o BGP,
• rimuovere le route XFRM solo quando il data path precedente è nuovamente attivo e verificato,
• ripristinare esattamente la Route Precedence originale, se è stata modificata,
• rimuovere completamente le route ausiliarie artificiali,
• verificare nuovamente tunnel, stato del Neighbor, prefissi e traffico reale.

Il rollback è completo solo quando l’accesso di gestione e le connessioni di produzione funzionano nuovamente tramite il percorso iniziale documentato.

FAQ