Configurare e testare una route statica su Sophos Firewall

Una route statica indica a Sophos Firewall tramite quale next hop fisso o interfaccia tunnel raggiungere una determinata destinazione. È adatta quando il percorso è definito e non occorre scegliere in base a source, service, applicazione o qualità della connessione.

Risposta breve

Una route IPv4 si crea qui:

Routing > Static routes > IPv4 unicast route > Add

Per una rete di destinazione 10.20.0.0/24, raggiungibile tramite il router 192.0.2.2 su Port4, inserire:

Destination IP / Netmask: 10.20.0.0/24
Gateway IP: 192.0.2.2
Interface: Port4
Administrative distance: 1
Metric: 10
Description: Branch_10.20_via_Core

Verificare quindi la destinazione 10.20.0.10 in Diagnostics > Tools > Route lookup. L’interfaccia prevista è Port4.

Affinché il traffico funzioni, occorrono anche una regola firewall adeguata e una route di ritorno sul dispositivo remoto. Una route statica non autorizza il traffico e non esegue automaticamente il NAT.

Comprendere l’esempio

L’esempio utilizza la seguente struttura:

La rete client dietro Sophos Firewall è 10.10.0.0/24.
Il client di test in questa rete è 10.10.0.10.
Port4 del firewall ha l’IP di transito 192.0.2.1/30.
Il router successivo ha l’IP 192.0.2.2 in questa rete.
Dietro questo router si trova la rete di destinazione 10.20.0.0/24.
Il sistema di test è 10.20.0.10.

La Destination è sempre la destinazione remota, non il router successivo. Gateway IP è il next hop direttamente raggiungibile che inoltra il pacchetto. Interface è la porta o l’interfaccia tunnel tramite cui si raggiunge il next hop.

In Gateway IP si inserisce direttamente l’indirizzo; non occorre un oggetto gateway in Routing > Gateways. Per adattare l’esempio al proprio ambiente, sostituire insieme rete di destinazione, gateway e interfaccia. Se si modifica un solo indirizzo di esempio, la route può essere salvata ma puntare alla rete errata o a un router non raggiungibile. L’IP del gateway deve appartenere alla rete dell’interfaccia selezionata.

Le basi relative a porta, zona e IP dell’interfaccia sono illustrate in Configurare zone e interfacce Sophos Firewall.

Quando è adatta una route statica

Una route statica è utile quando una rete è sempre raggiungibile tramite lo stesso next hop, ad esempio:

una rete di filiale dietro un Core Router interno
una rete server dietro uno switch Layer 3
una rete dietro un tunnel RED
una rete remota tramite l’interfaccia XFRM di un tunnel IPsec route-based

Se il firewall deve decidere anche in base a source, service o applicazione oppure cambiare percorso in funzione di latenza, jitter e perdita di pacchetti, una route SD-WAN è generalmente più adatta. Nelle reti più grandi e soggette a modifiche frequenti, OSPF o BGP riducono il lavoro di manutenzione manuale.

Configurare una route IPv4

Prima della modifica, documentare rete di destinazione, next hop, interfaccia di uscita, zona prevista, percorso di ritorno e un host di test raggiungibile. Quindi:

Aprire Routing > Static routes.
In IPv4 unicast route, fare clic su Add.
In Destination IP / Netmask, inserire 10.20.0.0/24.
In Gateway IP, inserire il router successivo 192.0.2.2.
Selezionare Port4 come Interface.
Impostare Administrative distance su 1.
In Metric, inserire 10.
Aggiungere una Description univoca, ad esempio Branch_10.20_via_Core.
Salvare con Save.

Per questa route, Sophos Firewall considera prima l’interfaccia selezionata e poi il gateway. Se uno dei due campi non è corretto, il next hop previsto non viene raggiunto.

Administrative Distance e Metric

L’Administrative Distance valuta le route provenienti da origini di routing concorrenti. Un valore inferiore ha la precedenza: una route con 1 è preferita a una route con 5.

Se più route statiche verso la stessa destinazione hanno la stessa Administrative Distance, decide la Metric. Anche in questo caso viene preferito il valore inferiore.

La Route Precedence globale tra Static, SD-WAN e VPN opera a un livello diverso rispetto ad Administrative Distance e Metric. Non dovrebbe essere modificata frettolosamente per una singola nuova route.

I valori di esempio 1 e 10 sono semplici valori iniziali per una singola route, non un’impostazione generale consigliata dal prodotto. Prima di utilizzarli, confrontare le route esistenti verso la stessa destinazione. Per Primary/Backup o ECMP, Administrative Distance e Metric vengono scelti intenzionalmente in base alla priorità desiderata.

Due route con Administrative Distance diversa possono definire un percorso preferito e uno secondario. Administrative Distance e Metric non controllano però autonomamente la raggiungibilità del next hop. Per un semplice failover basato sulla raggiungibilità, è possibile utilizzare oggetti gateway monitorati con route statiche e Administrative Distance diverse. Per scegliere in base a latenza, jitter o perdita di pacchetti, utilizzare un SD-WAN Profile e una route SD-WAN.

Per IPv4 ECMP, creare più route verso la stessa destinazione con Administrative Distance e Metric identiche, ma next hop diversi. In questo modo il traffico viene distribuito; non si crea un percorso Primary/Backup basato sulla qualità.

Utilizzare Blackhole consapevolmente

Con Blackhole, il firewall scarta il traffico verso la destinazione specificata senza rispondere alla source. Può essere utile per reti intenzionalmente bloccate o aggregate, ma non sostituisce un normale next hop.

Se le route statiche vengono ridistribuite tramite RIP, OSPF o BGP, occorre filtrare in modo mirato le route Blackhole. In caso contrario, il firewall può annunciare questa route di blocco anche ad altri router.

IPv6 e casi particolari con tunnel

In IPv6 unicast route si inseriscono l’indirizzo di destinazione con prefix, il Gateway IP, l’Interface e la Metric. Sophos non documenta per il modulo IPv6 Administrative Distance, opzione Blackhole, Description, Clone o funzione di attivazione e disattivazione. Le impostazioni IPv4 non devono quindi essere applicate a IPv6 senza verificarle.

Con un tunnel IPsec route-based con subnet Any-to-Any, la route può puntare direttamente all’interfaccia XFRM senza un gateway separato. Se il tunnel utilizza Traffic Selector specifici, SFOS crea automaticamente la route; in questo caso non si configurano indirizzi IP propri o route aggiuntive sull’interfaccia XFRM. Una route XFRM non corrisponde inoltre al caso particolare CLI ipsec_route, che dipende dalla versione; la distinzione è illustrata in Creare una route IPsec su Sophos Firewall.

Per una rete dietro l’interfaccia peer di un tunnel RED Site-to-Site tra Sophos Firewall si applica un’ulteriore eccezione: inserire come gateway l’IP dell’interfaccia RED peer, ma non selezionare alcuna interfaccia. Il firewall può così determinare tramite ARP l’interfaccia raggiungibile. Questo non vale per i tunnel Legacy RED Server/Client verso Sophos UTM rimossi in SFOS 22.

Regola firewall, NAT e percorso di ritorno

Il routing determina il percorso. La regola firewall decide se il pacchetto può passare e il NAT ne modifica gli indirizzi quando necessario. Queste tre funzioni vengono configurate separatamente.

Per l’esempio è necessaria una regola dalla rete client 10.10.0.0/24 alla rete di destinazione 10.20.0.0/24. La Destination Zone corrisponde alla zona di Port4. Limitare la regola ai servizi realmente necessari e attivare il logging durante il test.

In una rete di sede normalmente instradata, in genere non si utilizza SNAT, perché il dispositivo remoto deve vedere l’IP reale del client. Il router 192.0.2.2 necessita quindi della seguente route di ritorno:

Zielnetz: 10.10.0.0/24
Next Hop: 192.0.2.1

Se non è possibile configurare una route di ritorno sul dispositivo remoto, SNAT può aiutare tecnicamente. Nasconde però l’IP originale del client e deve rimanere una decisione consapevole di progettazione. Le relazioni sono spiegate in Comprendere il NAT su Sophos Firewall.

Verificare la route

Una route salvata può considerarsi validata solo quando un client reale raggiunge il dispositivo remoto e il percorso di ritorno funziona.

In Diagnostics > Tools > Route lookup, inserire 10.20.0.10. L’output deve mostrare Port4.
Nella Device Console, verificare le route IPv4 o IPv6 configurate e, in caso di concorrenza con SD-WAN o VPN, la Route Precedence:
```
show static-route
show static-route6
system route_precedence show
```
Dal client 10.10.0.10, avviare una connessione reale verso 10.20.0.10, ad esempio Ping o TCP 443, in linea con la regola firewall.
Nel Log viewer, controllare source, destination, service, Firewall Rule ID e un’eventuale NAT Rule ID.
In Diagnostics > Packet capture, utilizzare host 10.20.0.10 per verificare se le richieste escono da Port4 e se arrivano le risposte.

Se Route Lookup mostra il percorso corretto ma il traffico non passa, la causa è generalmente una regola firewall, il NAT, la route di ritorno o il sistema di destinazione. Il test completo del flusso di pacchetti è illustrato in Testare una regola Sophos Firewall con Log Viewer e Packet Capture.

Per problemi di routing più approfonditi, nella Device Console sono utili le ultime voci del log Unicast e del log del kernel:

show logs staticd.log lines 50
show logs zebra.log lines 50

staticd.log riguarda le route Unicast statiche; zebra.log mostra l’installazione delle route Unicast statiche IPv4 nel kernel. Service e file di log Sophos Firewall associa ulteriori file di log ai servizi responsabili.

Dopo il riavvio di un’interfaccia o di un tunnel, una route che specifica solo il gateway può inizialmente non comparire nella tabella di routing. Appare quando il traffico corrisponde alla destinazione e al gateway e il firewall seleziona l’interfaccia. L’assenza della voce subito dopo il riavvio non dimostra quindi ancora un malfunzionamento.

Individuare gli errori ed eseguire il rollback

Route Lookup mostra l’interfaccia errata

Verificare indirizzo di destinazione e prefix; un errore di digitazione può corrispondere a un’altra rete.
Il gateway deve essere direttamente raggiungibile tramite l’interfaccia selezionata.
Confrontare le route statiche concorrenti, Administrative Distance e Metric.
In presenza di SD-WAN o VPN, verificare l’ordine attuale con system route_precedence show. La modifica globale è illustrata in Modificare Route Precedence in sicurezza.

La richiesta esce, ma non arriva alcuna risposta

Verificare la route di ritorno sul router successivo e sul sistema di destinazione.
Verificare la regola firewall per la direzione iniziale e le regole NAT esistenti. Una regola nella direzione opposta è necessaria solo se il dispositivo remoto avvia autonomamente nuove connessioni.
Utilizzare Packet Capture per verificare se la risposta torna su Port4.
Verificare il firewall locale e il default gateway del sistema di destinazione.

Rollback sicuro

Una nuova route IPv4 viene prima disattivata anziché eliminata. Verificare quindi di nuovo Route Lookup, una nuova connessione client e il percorso precedente. Solo dopo aver confermato lo stato iniziale, eliminare se necessario la route e le regole o gli oggetti NAT creati esclusivamente per questa modifica.

Per IPv6, Sophos non documenta una funzione di attivazione e disattivazione. Annotare quindi in anticipo i valori precedenti e, in caso di rollback, modificare o eliminare la nuova route. In un cluster HA, ripetere il test dopo un failover sul nuovo Primary; i log non vengono sincronizzati tra i dispositivi.

Domande frequenti

Devo sempre specificare insieme gateway e interfaccia?

Per una normale route Ethernet, generalmente sì. IPsec route-based può utilizzare solo l’interfaccia XFRM; nel caso particolare RED descritto si inserisce solo l’IP RED peer come gateway.

Perché la connessione non funziona nonostante Route Lookup sia corretto?

Route Lookup conferma solo il percorso selezionato. Spesso mancano la regola firewall, il percorso di ritorno, una decisione NAT adeguata o l’autorizzazione sul sistema di destinazione.

Una route statica monitora automaticamente il gateway?

Administrative Distance e Metric non monitorano il gateway. Un semplice failover basato sulla raggiungibilità è possibile con oggetti gateway monitorati e route statiche con priorità diverse; per criteri di qualità come latenza, jitter o perdita di pacchetti, utilizzare SD-WAN.