Creare una rotta IPsec su Sophos Firewall

Una rotta IPsec manuale non è uno standard per ogni tunnel. Serve soprattutto con IPsec policy-based quando il traffico inoltrato e tradotto deve essere associato a un tunnel specifico.

IPsec route-based: non creare una ipsec_route. Il traffico usa interfacce XFRM e rotte statiche, SD-WAN o dinamiche. IPsec policy-based senza un caso NAT particolare: verificare prima il tunnel, le regole firewall, il NAT e il percorso di ritorno. IPsec policy-based con traffico DNAT o SNAT inoltrato: i passaggi seguenti aiutano nella verifica e nella configurazione.

⚠️ Una rotta IPsec errata può indirizzare il traffico di produzione nel tunnel sbagliato. Prima di ogni modifica, documentare lo stato iniziale e preparare un rollback preciso.

Verificare, creare e rimuovere una rotta IPsec

I comandi per visualizzare, creare e rimuovere le rotte si eseguono nella Device Console. Se l’accesso non è ancora configurato, Connettersi a Sophos Firewall tramite SSH spiega come aprire la Device Console.

Documentare lo stato iniziale

Prima di eseguire un comando di aggiunta, il percorso concreto deve essere chiaro:

• Si tratta di un tunnel policy-based attivo, non di IPsec route-based.
• L’host o la rete di destinazione corrisponde ai traffic selector del tunnel e alla traduzione pianificata.
• Le regole firewall e NAT corrispondono al traffico di test definito; per SNAT, Outbound interface è impostato su Any.
• Route Precedence e le rotte concorrenti sono state verificate.
• Il peer remoto si aspetta l’indirizzo sorgente visibile e dispone di una rotta di ritorno.

Per prima cosa, documentare tutte le rotte IPsec manuali:

system ipsec_route show

In caso di problemi di routing o NAT, documentare anche Route Precedence e il NAT del traffico di sistema:

system route_precedence show
show advanced-firewall

Nell’Advanced Shell può essere utile anche questa vista di troubleshooting precedente:

ip route show table 220

Secondo Sophos, con SFOS 22 le rotte IPsec policy-based e le voci ipsec_route non sono visibili in questa tabella. L’assenza di una voce non dimostra quindi che non esista una rotta IPsec. Restano determinanti system ipsec_route show, la configurazione e un test del traffico.

Creare una rotta per un host

Sintassi:

system ipsec_route add host <host-ip> tunnelname <tunnelname>

Esempio per l’host 10.33.46.69 tramite il tunnel Azure_CH:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Creare una rotta per una rete

Sintassi:

system ipsec_route add net <network>/<netmask> tunnelname <tunnelname>

Esempio per la rete 10.33.46.0/24:

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

La netmask deve corrispondere esattamente alla destinazione prevista. Una rotta troppo ampia può inoltrare involontariamente altro traffico nel tunnel.

Rimuovere una rotta in sicurezza

⚠️ I comandi di eliminazione non contengono il nome del tunnel. Prima di rimuovere una rotta, usare system ipsec_route show per verificare che l’host o la rete siano univoci e tenere pronto il comando di aggiunta completo per il rollback. Non eliminare voci ambigue sulla base di una supposizione.

Rimuovere una rotta host:

system ipsec_route del host <host-ip>

Rimuovere una rotta di rete:

system ipsec_route del net <network>/<netmask>

Quindi verificare nuovamente l’elenco:

system ipsec_route show

Se il risultato del test peggiora, ripristinare la rotta con il comando di aggiunta documentato in precedenza.

Quando usare ipsec_route

IPsec policy-based e route-based

Con IPsec policy-based, le reti locali e remote definiscono i traffic selector del tunnel. Una ipsec_route manuale può associare host o reti aggiuntivi a un tunnel esistente, ma non sostituisce traffic selector corretti, regole firewall o una rotta di ritorno.

Con IPsec route-based, il traffico viene instradato verso l’interfaccia XFRM. In base al design, si usa una rotta statica, una rotta SD-WAN o il routing dinamico. Una ipsec_route è lo strumento sbagliato. Configurare una VPN IPsec Site-to-Site su Sophos Firewall e Configurare zone e interfacce su Sophos Firewall spiegano le basi di entrambe le varianti.

Differenza tra SFOS 21.5 e 22

La classificazione in Route Precedence è cambiata:

• Con SFOS 21.5, le rotte IPsec policy-based create automaticamente appartengono alla categoria vpn, mentre le voci ipsec_route manuali appartengono a static.
• Con SFOS 22, sia le rotte IPsec policy-based automatiche sia quelle manuali appartengono alla categoria vpn. Non compaiono come normali rotte del kernel e vengono elaborate internamente tramite marcature, zone e flag.

Dopo un aggiornamento da SFOS 21.5, testare nuovamente Route Precedence e i casi particolari esistenti. Il controllo per l’aggiornamento a SFOS 22 include le verifiche generali. Modificare Route Precedence su Sophos Firewall in sicurezza spiega l’ordine globale.

Se in precedenza le reti VPN policy-based venivano ridistribuite a OSPF o BGP tramite redistribute kernel, questo controllo non è sufficiente: a partire da SFOS 22, le route VPN non sono più normali route del kernel. Perché redistribute kernel non annuncia più le route IPsec dopo l’upgrade a SFOS 22 spiega il comportamento e il design di destinazione XFRM route-based.

Una rotta manuale ha senso solo se il tunnel, i traffic selector, la regola firewall, la regola NAT e il percorso di ritorno sono corretti. Non risolve una netmask errata, una rotta mancante sul peer remoto o una regola bloccante.

NAT per il traffico inoltrato

Il NAT modifica gli indirizzi, ma non cambia automaticamente la decisione di routing. Se un tunnel policy-based trasporta traffico aggiuntivo tradotto tramite DNAT o SNAT, può quindi essere necessaria una rotta IPsec corrispondente verso l’host o la rete remota.

Per SNAT con IPsec policy-based, la regola NAT corrispondente deve usare Any come Outbound interface. Se è limitata a una specifica interfaccia WAN, non corrisponde al traffico IPsec. Comprendere il NAT su Sophos Firewall spiega in modo più dettagliato l’ordine di elaborazione, il matching e il percorso di ritorno.

Eseguire la modifica durante una finestra di manutenzione o con un caso di test controllato. Prima devono essere noti questi valori:

• indirizzi sorgente e destinazione originali e tradotti,
• reti locale e remota della connessione IPsec,
• nome del tunnel e regola firewall prevista,
• rotta di ritorno e indirizzi consentiti sul peer remoto.

Gestire separatamente il traffico generato dal sistema

Le richieste DNS, di autenticazione o di altro tipo generate dal firewall non seguono automaticamente la stessa logica del traffico client inoltrato. Con SFOS 22, normalmente non serve una ipsec_route per questo traffico. Solo la procedura Sophos specifica per le richieste di autenticazione la indica come fallback condizionale quando la richiesta non entra in modo dimostrabile nel tunnel policy-based a causa della Route Precedence concreta.

Se necessario, sys-traffic-nat consente di definire l’indirizzo sorgente per questo traffico. Esempio: il firewall deve raggiungere il server 10.10.2.15 con l’indirizzo SNAT/interfaccia definito 10.10.1.1. Questo indirizzo deve corrispondere alle subnet IPsec e deve avere una rotta di ritorno sul peer remoto.

I comandi seguenti si eseguono nella Device Console:

set advanced-firewall sys-traffic-nat add destination 10.10.2.15 snatip 10.10.1.1
show advanced-firewall

Rollback:

set advanced-firewall sys-traffic-nat delete destination 10.10.2.15 snatip 10.10.1.1

Se durante l’aggiunta sono stati usati anche interface o netmask, in fase di eliminazione devono essere specificati gli stessi selettori. Verificare il routing SD-WAN per Reply Packets e System Traffic contiene altri esempi.

Il DHCP richiede una valutazione separata:

• Con IPsec policy-based, il relay richiede l’opzione Relay through IPsec, subnet IPsec locali e remote corrispondenti, sys-traffic-nat e le regole e rotte di ritorno necessarie sul peer remoto. Se le richieste continuano a non entrare nel tunnel a causa della specifica configurazione di routing, può essere necessaria una ipsec_route come fallback verificato.
• Con IPsec route-based, non attivare Relay through IPsec. È supportato un relay verso il lato server DHCP tramite un’interfaccia XFRM con subnet Any-to-any, rotte statiche, SD-WAN o dinamiche e regole corrispondenti su entrambi i firewall. Una ipsec_route non fa parte di questo percorso.
• Se il firewall della sede principale opera direttamente come server DHCP per reti remote in una configurazione IPsec policy-based, è necessario attivare Lease over IPsec. Secondo Sophos, le interfacce firewall utilizzate come server DHCP non sono supportate per questa configurazione route-based.

Anche questo comando si esegue nella Device Console:

system dhcp lease-over-IPSec enable

Le procedure precedenti per SFOS 21.5 menzionavano più spesso ipsec_route per autenticazione e DHCP. Verificare tali configurazioni durante un aggiornamento e non riprodurle senza controllo.

Testare e validare la modifica

Un tunnel verde o un ping riuscito non costituiscono una prova sufficiente. Un test ICMP può funzionare anche se TCP, NAT o il percorso di ritorno sono ancora errati.

1. Definire sorgente, destinazione, servizio, direzione e tunnel previsto.
2. Attivare il logging della regola firewall interessata.
3. Documentare system ipsec_route show prima del test.
4. Generare una sola volta e in modo controllato il traffico applicativo reale.
5. Filtrare Log Viewer per sorgente, destinazione e regola.
6. Eseguire Packet Capture con un filtro preciso su entrambi i lati del percorso.
7. Verificare l’indirizzo sorgente, la rotta di ritorno e il firewall locale sul peer remoto.
8. Documentare il risultato, la modifica e il comando di rollback.

Nell’Advanced Shell, questi comandi mostrano le SA negoziate, i contatori di byte e le policy XFRM:

ipsec statusall
ip xfrm policy

Tuttavia, questi comandi da soli non dimostrano che il NAT, la regola firewall e il percorso di ritorno siano corretti. Testare una regola firewall con Log Viewer, Policy Test e Packet Capture aiuta nell’analisi sistematica. Se si bloccano solo i trasferimenti più grandi, verificare anche MTU e MSS nei problemi VPN.

Circoscrivere gli errori ed eseguire il rollback

Il tunnel è attivo, ma il traffico non passa

Verificare la regola firewall, il NAT, i traffic selector e la rotta di ritorno. Confrontare quindi Log Viewer, Packet Capture e i contatori di ipsec statusall. Troubleshooting della VPN IPsec su Sophos Firewall descrive la procedura completa.

Il traffico viene inviato verso la WAN

Verificare Route Precedence, le rotte SD-WAN e system ipsec_route show. Con SFOS 22, l’assenza di una voce nella tabella 220 non deve essere usata come prova che non esista una rotta IPsec.

SNAT non viene applicato

Con IPsec policy-based, verificare che Outbound interface sia impostato su Any e che gli indirizzi originali e tradotti corrispondano al tunnel e al peer remoto.

Un host funziona, ma una rete no

Confrontare la netmask, l’oggetto host/rete e i traffic selector su entrambi i lati. Non creare una rotta più ampia prima di aver compreso la differenza.

Il percorso cambia dopo l’aggiornamento a SFOS 22

Verificare nuovamente Route Precedence e tutti i casi particolari policy-based che coinvolgono NAT, SD-WAN o MPLS. Non eliminare o ricreare automaticamente le vecchie rotte.

Il traffico generato dal firewall non raggiunge la destinazione

Determinare prima se il problema riguarda autenticazione, DNS, DHCP o un altro servizio. Verificare quindi Route Precedence, SD-WAN, sys-traffic-nat e il relativo workflow SFOS 22.

Se un errore inizia subito dopo la modifica, rimuovere la nuova rotta, controllare con system ipsec_route show e ripetere il test precedente. Se il problema persiste, ripristinare completamente lo stato iniziale documentato.

FAQ