Modificare in sicurezza la route precedence di Sophos Firewall

La route precedence stabilisce globalmente se Sophos Firewall valuta prima le Static Routes, le SD-WAN Policy Routes o le route VPN. L’ordine si applica quando più categorie corrispondono allo stesso flusso. Un’eccezione importante: vpn prima di static prevale sulle route statiche o locali solo per destinazioni nella zona WAN.

Perché è necessaria la route precedence

Sophos Firewall non mantiene Static, SD-WAN e VPN in un’unica lista di routing. Sono categorie separate e più categorie possono contenere contemporaneamente un percorso corrispondente verso la stessa destinazione. La route precedence determina in quale categoria viene cercata per prima una route corrispondente.

Esempio tipico: un client della LAN deve raggiungere la rete remota 10.20.0.0/16 tramite un tunnel IPsec policy-based. Allo stesso tempo, anche una route SD-WAN con destinazione Any corrisponde a questo traffico.

• Con static sdwan_policyroute vpn, il firewall controlla prima Static. Se non trova un percorso corrispondente, la route SD-WAN generale corrisponde subito dopo e il traffico può andare al gateway WAN invece che nel tunnel VPN.
• Con static vpn sdwan_policyroute, il firewall controlla le route VPN subito dopo Static. La route verso la rete remota ha quindi priorità sulla route SD-WAN generale.

Sostituire la rete di esempio 10.20.0.0/16 con la rete remota effettiva. La domanda importante non è quale ordine sembri generalmente «migliore», ma quale tipo di routing debba avere la priorità per il flusso di pacchetti concreto.

La route precedence ordina soltanto le categorie. Non modifica l’ordine delle singole Static Routes o SD-WAN Routes all’interno della loro categoria. Prima di cambiarla, rispondere a tre domande:

1. Quale traffico concreto segue attualmente il percorso errato?
2. Quali delle tre categorie contengono una route corrispondente?
3. Quale categoria deve avere priorità per questo traffico?

Se corrisponde una sola categoria, modificare la route precedence non risolve il problema. Occorre invece correggere la route interessata, la Policy SD-WAN, la configurazione VPN, la regola NAT o il percorso di ritorno. La route precedence non autorizza inoltre il traffico tra zone: resta necessaria una regola firewall appropriata.

Visualizzare e modificare direttamente la route precedence

I comandi si eseguono nella Device Console, non nell’Advanced Shell. Dopo l’accesso tramite SSH, selezionare l’opzione di menu 4. Se l’accesso non è ancora configurato, vedere Connettersi a Sophos Firewall tramite SSH.

Annotare innanzitutto l’intero ordine attuale e usarlo per creare il comando di rollback. Il default Sophos odierno non lo sostituisce, perché firewall migrati o personalizzati possono avere un ordine iniziale diverso.

⚠️ Importante: La modifica è globale. Prima del comando set devono essere disponibili l’ordine iniziale e un accesso di gestione indipendente. Un ordine inadeguato può influire sul traffico di produzione e sugli accessi WebAdmin e SSH.

Il seguente esempio imposta Static al primo posto, VPN al secondo e SD-WAN all’ultimo:

system route_precedence show
system route_precedence set static vpn sdwan_policyroute
system route_precedence show

Il primo comando mostra l’ordine attuale, il secondo lo modifica e il terzo controlla il risultato. La posizione dei valori ne determina la priorità. L’output finale deve mostrare static, vpn, sdwan_policyroute esattamente in quest’ordine; quindi va testato il flusso reale.

L’ordine predefinito attuale di Sophos è:

system route_precedence set static sdwan_policyroute vpn

Questo comando è un rollback solo se system route_precedence show mostrava esattamente quest’ordine prima della modifica.

WebAdmin mostra l’ordine attuale anche in Routing > SD-WAN routes, ma la modifica è possibile solo tramite la Device Console.

Significato di Static, SD-WAN e VPN

I tre valori rappresentano categorie di routing, non singole route:

• static comprende reti direttamente connesse, Unicast Routes, Dynamic Routes e SSL VPN.
• sdwan_policyroute comprende le Policy Routes configurate in Routing > SD-WAN routes.
• vpn comprende le route IPsec policy-based generate automaticamente. In SFOS 22.0 comprende anche le route definite con ipsec_route.

Le route IPsec policy-based e le voci ipsec_route non compaiono nella tabella di routing di WebAdmin. Nell’analisi dei conflitti vanno considerate anche la configurazione VPN e le route create nella Device Console. La guida sulle route IPsec di Sophos Firewall spiega la classificazione completa.

SSL VPN appartiene a static, non a vpn. IPsec route-based tramite interfacce XFRM è controllato dalla route statica, dinamica o SD-WAN configurata. Sono determinanti l’interfaccia XFRM, la route e la sua Administrative Distance, non soltanto la posizione di vpn. Se nessuna route corrisponde, WAN Link Manager fornisce la route predefinita.

Static, SD-WAN, VPN

system route_precedence set static sdwan_policyroute vpn

Questo è l’ordine predefinito e il punto di partenza corretto per molti ambienti. Impedisce che route SD-WAN troppo ampie scavalchino reti direttamente connesse, LAN, DMZ, VLAN e SSL VPN.

Static, VPN, SD-WAN

system route_precedence set static vpn sdwan_policyroute

Questo ordine mantiene Static al primo posto, valuta poi le route VPN e utilizza SD-WAN per ultimo. È utile quando i percorsi statici e direttamente connessi devono conservare la priorità mentre una route VPN policy-based concorrente deve essere controllata prima di SD-WAN. Sophos lo usa anche per il failover VPN route-based con due connessioni Internet e per MTA con più connessioni WAN.

SD-WAN, Static, VPN

system route_precedence set sdwan_policyroute static vpn

Questa variante va usata solo quando il Policy Routing deve deliberatamente avere priorità sulle route statiche. Occorre particolare attenzione con una route SD-WAN avente destinazione Any: può includere anche reti interne o l’accesso di gestione e inviare tale traffico verso il gateway WAN. Una route SD-WAN deve quindi usare destinazioni il più possibile specifiche ed essere testata.

VPN, Static, SD-WAN

system route_precedence set vpn static sdwan_policyroute

Mettere VPN al primo posto è un’eccezione mirata, non una soluzione generale ai problemi IPsec. Per L2TP Remote Access, vpn deve essere al primo posto; static e sdwan_policyroute possono seguire in entrambi gli ordini. Tuttavia, vpn prima di static assegna priorità a VPN rispetto a Static solo quando la route statica concorrente porta alla zona WAN. Per le destinazioni in altre zone, il firewall continua a utilizzare la route statica o locale.

Anche il design policy-based che instrada il traffico Internet di una filiale attraverso la sede centrale richiede esattamente questo ordine. Combina selettori Any, una regola VPN-to-WAN, MASQ e una decisione separata per il traffico generato dal sistema.

Modificare la route precedence in sicurezza

Prima di una modifica in produzione, preparare sia il comando sia il flusso di pacchetti interessato:

1. Salvare l’intero ordine attuale con system route_precedence show e usarlo per preparare il comando di rollback.
2. Identificare origine, destinazione, servizio, zona e interfacce coinvolte. Verificare Static Routes, SD-WAN Routes, route VPN e interfacce XFRM con destinazioni concorrenti.
3. Testare un percorso indipendente verso il firewall, ad esempio una console locale, un’interfaccia di gestione separata o un percorso amministrativo non interessato.
4. Modificare solo la route precedence. Non cambiare contemporaneamente regole NAT, firewall, VPN e SD-WAN, in modo da poter distinguere causa ed effetto.

Se è coinvolto SD-WAN, verificare anche se è attivo per il traffico generato dal sistema o per i reply packet:

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

Queste opzioni non modificano l’ordine. Estendono il traffico a cui si applicano le SD-WAN Routes: il routing dei Reply Packets non si applica se l’andata ha usato soltanto la route predefinita di WAN Link Manager. Per il traffico generato dal sistema, usare solo reti di destinazione e servizi, perché Incoming Interface e Source Network non sono noti. Almeno un gateway di WAN Link Manager deve essere Active; i gateway impostati soltanto su Backup non bastano. Il traffico RED generato dal sistema su UDP 3410 resta escluso dal routing SD-WAN in quanto Layer 2. Verificare il routing SD-WAN Sophos Firewall per Reply Packets e System Traffic spiega i dettagli.

Dopo il comando set, confermare prima l’ordine con system route_precedence show. Testare quindi il caso concreto:

• Testare l’applicazione, una connessione TCP o il ping verso la destinazione.
• Controllare Route Lookup, Log Viewer e Packet Capture quando necessario.
• Controllare NAT e il percorso di ritorno della controparte.
• Testare WebAdmin e SSH dalle reti di gestione pertinenti.

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

Rollback

Per il rollback, ripristinare esattamente l’ordine iniziale registrato prima della modifica:

system route_precedence set <erster Wert> <zweiter Wert> <dritter Wert>

Sostituire tutti e tre i placeholder. Lo stato precedente non può essere dedotto dal solo primo valore, perché sono possibili sei ordini. Ripetere quindi system route_precedence show e gli stessi test funzionali e di gestione.

Se la modifica non risolve il problema

• È interessata una sola rete di destinazione: Una route statica più specifica, una route SD-WAN più limitata o una configurazione VPN corretta sono generalmente più precise di una modifica globale.
• Il tunnel VPN è verde, ma il traffico segue il percorso errato: Per IPsec route-based controllare prima interfaccia XFRM e route. Per IPsec policy-based verificare anche i Traffic Selectors e la gestione di ipsec_route dipendente dalla versione. Seguire la guida al troubleshooting VPN IPsec.
• Il percorso di andata è corretto, quello di ritorno no: Il routing determina il percorso, mentre NAT modifica l’indirizzo di origine o destinazione. Controllare la route di ritorno e la configurazione NAT.
• Un firewall migrato mostra un ordine inatteso: Fa fede l’output di system route_precedence show, non il valore predefinito attuale. Le route SD-WAN migrate possono inoltre restare collegate alla regola firewall originale e scomparire quando questa viene eliminata.
• WebAdmin o SSH non sono raggiungibili dopo una modifica SD-WAN: Spesso coincidono tre condizioni: SD-WAN precede Static, una route SD-WAN corrispondente usa Any e System Traffic o Reply Packets sono attivi per SD-WAN. Ripristinare l’ordine iniziale tramite il percorso di gestione preparato e restringere la route SD-WAN.
• Una richiesta SSL VPN raggiunge la destinazione interna, ma la risposta non torna al client: SSL VPN appartiene a static. Se SD-WAN viene prima, una route SD-WAN troppo ampia può deviare dal tunnel la risposta verso il pool di indirizzi. Limitare la route in modo mirato; la procedura completa è descritta in Configurare e testare SSL VPN Remote Access.

Domande frequenti