Modificare in sicurezza la route precedence di Sophos Firewall

La route precedence stabilisce se Sophos Firewall valuta prima le Static Routes, le SD-WAN Policy Routes o le route VPN. L’impostazione è globale e può influire immediatamente sul traffico di produzione e sull’accesso amministrativo.

Risposta breve

L’ordine predefinito è:

1. static
2. sdwan_policyroute
3. vpn

Questo ordine è adatto a molti ambienti, perché le reti direttamente connesse e le route statiche non vengono scavalcate da una route SD-WAN troppo ampia. Va modificato solo quando più tipi di routing competono per la stessa destinazione nel flusso di pacchetti concreto.

Prima di ogni modifica, documentare l’ordine attuale, garantire un accesso di gestione indipendente, verificare le route interessate e preparare il rollback esatto. Una normale route SD-WAN è spiegata in Configurare e testare una route SD-WAN su Sophos Firewall.

Quale ordine è adatto?

Ordine predefinito e differenza tra versioni

L’ordine predefinito è identico in SFOS 21.5 e 22.0. È però cambiata la classificazione di ipsec_route:

• SFOS 21.5: static comprende reti direttamente connesse, ipsec_route, Unicast Routes, Dynamic Routes e SSL VPN. Le route IPsec policy-based generate automaticamente appartengono a vpn.
• SFOS 22.0: static comprende reti direttamente connesse, Unicast Routes, Dynamic Routes e SSL VPN. vpn comprende le route IPsec policy-based generate automaticamente e ipsec_route.

Questo è importante negli upgrade: Un’indicazione relativa a ipsec_route per SFOS 21.5 non deve essere applicata senza modifiche a SFOS 22.0. In SFOS 22.0 il firewall elabora internamente le route IPsec policy-based. Le route VPN policy-based generate automaticamente e quelle definite con ipsec_route non sono visibili nella tabella di routing. ipsec_route non è necessario per il traffico generato dal sistema. Una route IPsec manuale è utile solo per lo specifico caso dipendente dalla versione.

Sui firewall migrati conta l’output effettivo, non il valore predefinito documentato. Una migrazione può ad esempio mantenere sdwan_policyroute vpn static. Le route SD-WAN migrate possono inoltre restare collegate all’ID della regola firewall originale e scomparire quando tale regola viene eliminata.

Static per primo

static sdwan_policyroute vpn è generalmente il punto di partenza corretto per LAN, DMZ, VLAN, SSL VPN e normali percorsi Internet SD-WAN. Le reti direttamente connesse vengono trattate come route statiche.

Questo protegge le destinazioni interne da route SD-WAN troppo ampie. Se sdwan_policyroute precede static e una route SD-WAN usa una destinazione come Any, il traffico interno o amministrativo può essere inviato inaspettatamente verso il gateway WAN.

SD-WAN per primo

sdwan_policyroute static vpn è adatto quando il policy routing deve avere deliberatamente priorità sulle route statiche. Va pianificato in base a origine, destinazione e servizio concreti. Le route SD-WAN si applicano ai reply packet e al traffico generato dal sistema solo se sono attive le relative opzioni CLI.

Verificare il routing SD-WAN Sophos Firewall per reply packets e system traffic spiega in dettaglio entrambe le opzioni.

VPN per primo

vpn static sdwan_policyroute è un’eccezione mirata, ad esempio per scenari L2TP documentati. La priorità di vpn su static vale solo per il traffico la cui route concorrente porta alla zona WAN. Non è una soluzione generale per ogni tunnel IPsec.

Le connessioni SSL VPN appartengono alla categoria static, non a vpn. IPsec route-based tramite interfacce XFRM viene controllato dalla route statica, dinamica o SD-WAN configurata. Sono quindi determinanti interfaccia XFRM, route, criteri SD-WAN, NAT, regola firewall e percorso di ritorno.

Una modifica globale non è adatta quando solo una rete di destinazione viene instradata in modo errato. Una route statica o SD-WAN più specifica, la configurazione VPN o un ipsec_route adeguato alla versione è generalmente un intervento più preciso.

Preparare la modifica in sicurezza

I comandi si eseguono nella Device Console, non nell’Advanced Shell. Se l’accesso non è ancora configurato, vedere Connettersi a Sophos Firewall tramite SSH. SSH deve essere consentito solo da reti attendibili.

Preparazione:

1. Garantire e testare attivamente un percorso indipendente verso il firewall prima della modifica, ad esempio console locale, interfaccia di gestione dedicata o percorso amministrativo confermato come non interessato.
2. Annotare origine, destinazione, servizio, zona e interfacce coinvolte.
3. Verificare route statiche, SD-WAN Policy Routes, route VPN e interfacce XFRM.
4. Identificare route SD-WAN ampie con Any e regole migrate.
5. Verificare NAT, regola firewall e percorso di ritorno della controparte.
6. Definire finestra di manutenzione, test di accettazione e rollback.

⚠️ Importante: La route precedence è globale. Non modificare contemporaneamente routing, NAT, regole firewall e SD-WAN, altrimenti non è possibile attribuire con certezza l’effetto.

Visualizzare l’ordine attuale e documentarlo esattamente:

system route_precedence show

Registrare l’output completo insieme a data, motivo, reti interessate e comportamento previsto. Prima della modifica, preparare l’esatto comando di rollback usando tutti e tre i valori.

L’ordine attuale è visibile anche qui in WebAdmin:

Routing > SD-WAN routes

La modifica avviene tramite Device Console. Se è coinvolto SD-WAN, registrare prima anche lo stato del traffico generato dal sistema e dei reply packet:

show routing sd-wan-policy-route system-generate-traffic
show routing sd-wan-policy-route reply-packet

Questi valori non devono essere confusi con l’effetto della route precedence. Una combinazione particolarmente critica si verifica quando sdwan_policyroute precede static, una route SD-WAN corrispondente usa la destinazione Any e SD-WAN è attivo sia per il traffico generato dal sistema sia per i reply packet. WebAdmin e SSH possono allora diventare irraggiungibili dalla subnet interna interessata, mentre il firewall può restare raggiungibile da altre subnet.

Modificare la route precedence

La sintassi contiene sempre tutti e tre i valori:

system route_precedence set [sdwan_policyroute] [static] [vpn]

Impostare l’ordine predefinito:

system route_precedence set static sdwan_policyroute vpn

Se questo ordine è già attivo, l’errore riguarda probabilmente route lookup, criteri SD-WAN, configurazione VPN, NAT, regola firewall o percorso di ritorno.

⚠️ Prima di SD-WAN-First: Verificare se route SD-WAN ampie includono reti interne o accesso di gestione. Eseguire il comando solo con un percorso di recupero preparato.

Valutare prima le SD-WAN Policy Routes:

system route_precedence set sdwan_policyroute static vpn

⚠️ Prima di VPN-First: Usare questo ordine solo per un caso VPN confermato. Non risolve route mancanti, traffic selector errati, NAT o problemi del percorso di ritorno.

Valutare prima le route VPN:

system route_precedence set vpn static sdwan_policyroute

Testare e ripristinare la modifica

Dopo la modifica, confermare innanzitutto che sia attivo l’ordine previsto:

system route_precedence show

Testare quindi il flusso di pacchetti interessato:

• Testare applicazione, connessione TCP o ping verso la destinazione.
• Filtrare Log Viewer per origine, destinazione e regola firewall.
• Eseguire Packet Capture sulle interfacce di ingresso e uscita.
• Controllare route lookup e la route SD-WAN interessata.
• Controllare NAT e l’IP sorgente tradotto.
• Confermare il percorso di ritorno della controparte.
• Testare WebAdmin e SSH dalle reti amministrative rilevanti.

Uno stato VPN verde o una route esistente non provano che il flusso funzioni. I passaggi pratici sono in Testare regole Sophos Firewall con Log Viewer e Packet Capture e Usare Packet Capture in Sophos Firewall WebAdmin.

Se sono interessati più siti o percorsi di routing, testare almeno un client per ogni rete rilevante, una destinazione server e i percorsi Remote Access o VPN coinvolti.

Per il rollback, impostare esclusivamente l’ordine originale completo documentato in precedenza. Non è possibile ricavarlo dal solo primo valore, perché sono possibili sei combinazioni. Usare il comando preparato secondo questo modello:

system route_precedence set <primo valore> <secondo valore> <terzo valore>

Sostituire i placeholder con tutti e tre i valori dell’output salvato. Verificare quindi di nuovo:

system route_precedence show

Ripetere gli stessi test funzionali, di routing e di gestione. Se l’errore originale ritorna dopo il rollback, probabilmente era coinvolta la route precedence. Se non cambia nulla, la causa è altrove.

Errori frequenti

La route SD-WAN è troppo ampia

Una route SD-WAN con grandi intervalli di rete o destinazione Any può includere più traffico del previsto. Se SD-WAN precede Static, destinazioni interne e accessi di gestione possono essere inviati inaspettatamente al gateway WAN. Reply packet e traffico generato dal sistema sono interessati se le opzioni SD-WAN corrispondenti sono attive.

Lo stato VPN viene confuso con il routing

Un tunnel attivo conferma solo la negoziazione. Non prova che routing, traffic selector, regole firewall, NAT e percorso di ritorno siano corretti. Per IPsec route-based controllare prima interfaccia XFRM e route; per IPsec policy-based anche la gestione di ipsec_route dipendente dalla versione. Troubleshooting VPN IPsec Sophos Firewall guida l’analisi.

NAT viene trascurato

Il routing determina il percorso del pacchetto, mentre NAT ne modifica l’indirizzo di origine o destinazione. Se la route è corretta ma il ritorno non funziona, spesso la causa è NAT o la route di ritorno. Vedere Capire NAT su Sophos Firewall.

Vengono effettuate più modifiche contemporaneamente

Modificando insieme route precedence, SD-WAN, NAT, regole firewall e parametri VPN non è più possibile separare chiaramente causa ed effetto. Meglio: una modifica, test completo, modifica successiva.

Lista di controllo

• Route precedence attuale documentata.
• Versione SFOS e classificazione di ipsec_route considerate.
• Origine, destinazione, reti e servizi interessati annotati.
• Static, SD-WAN, VPN e XFRM verificati.
• Reti direttamente connesse e percorsi di gestione considerati.
• Route SD-WAN ampie con Any identificate.
• Stato di System Traffic e reply packet registrato.
• NAT, regole firewall e percorso di ritorno verificati.
• Accesso di gestione indipendente e rollback preparati.
• Modifica eseguita singolarmente.
• Applicazione, Log Viewer, Packet Capture e accesso di gestione testati.

Domande frequenti