Vai al contenuto
Avanet

Configurare e testare route SD-WAN Sophos Firewall

Sophos Firewall

Con una route SD-WAN si controlla attraverso quale gateway passa un flusso di traffico definito su Sophos Firewall. È utile con più connessioni Internet, MPLS, VPN IPsec route-based, VoIP o servizi cloud. La route deve essere definita in modo preciso e testata con traffico reale, altrimenti può includere reti interne o usare la Public IP errata durante il failover.

Se Sophos Central deve generare tunnel route-based e percorsi tra sedi per più firewall gestiti, occorre invece seguire Configurare e verificare un gruppo di connessioni SD-WAN in Sophos Central. Questo articolo spiega la route SD-WAN locale, che resta importante anche per verificare i percorsi distribuiti centralmente.

Risposta breve

Una route SD-WAN si crea qui:

Routing > SD-WAN routes > IPv4 / IPv6 > Add

Prima devono essere chiari quattro punti:

  • quale traffico deve corrispondere in base a incoming interface, source, destination e service
  • quale primary/backup gateway o SD-WAN profile deve essere utilizzato
  • se sono consentiti esclusivamente questi gateway e quale NAT è adatto
  • come verificare route, gateway e percorso di ritorno con Log Viewer e Packet Capture

Per destinazioni IPv4 pubbliche non si dovrebbe usare Any indiscriminatamente, ma quando possibile Internet IPv4 group o destinazioni specifiche. Se SD-WAN precede Static nella route precedence, una route Any troppo ampia può inviare anche traffico interno al gateway WAN.

Il video integra la guida alla pianificazione, configurazione e verifica delle route SD-WAN su Sophos Firewall.

Utilizzo e pianificazione

Quando preferire SD-WAN a una route statica

Una route statica è sufficiente se una rete di destinazione è sempre raggiungibile tramite un next hop fisso. Le route SD-WAN aggiungono criteri come source, service, utente o applicazione e possono scegliere i gateway in base a disponibilità o qualità.

Casi tipici:

  • instradare determinati client o servizi tramite WAN2 e passare a WAN1 in caso di guasto
  • inviare VoIP o applicazioni cloud su un percorso con bassa latenza e perdita di pacchetti
  • utilizzare MPLS, LTE/5G o un tunnel IPsec route-based come percorso primario o di backup
  • vincolare il traffico a un provider la cui Public IP è autorizzata su un sistema remoto

Esempio di pianificazione e requisiti

Prima di creare la route si descrive un flusso concreto. Per il traffico Microsoft 365, la pianificazione potrebbe essere:

  • Incoming interface: interfaccia LAN interna
  • Source network: Client_Net_10.20.0.0_24
  • Destination: gruppo di destinazioni Microsoft 365 gestito internamente o Internet IPv4 group
  • Services: HTTPS e, se necessario, un gruppo di servizi per UDP 3478-3481
  • Primary gateway: WAN2
  • Backup gateway: WAN1
  • Fallback: consentire la default route o attivare Route only through specified gateways
  • NAT: MASQ o IP SNAT fisso adatto al gateway selezionato
  • Test: IP client, destinazione, gateway previsto e voce di log prevista

Servono inoltre regole firewall adeguate, regole NAT per il traffico da tradurre, logging firewall attivo e accesso a Log viewer e Diagnostics > Packet capture. I gateway WAN sono in Network > WAN link manager; i custom gateway per MPLS, RED o XFRM si creano in Routing > Gateways.

Il comportamento generale Active/Backup del percorso WAN predefinito è descritto in Configurare il failover WAN su Sophos Firewall; per le basi relative a interfacce e gateway, consultare Configurare zone e interfacce Sophos Firewall.

Con IPsec route-based, la direzione è importante: Un’interfaccia XFRM come Incoming interface corrisponde al traffico che entra dal tunnel. Per traffico da LAN a VPN si seleziona invece il gateway dell’interfaccia XFRM come primary gateway o in un SD-WAN profile. Le basi sono in Creare una route IPsec su Sophos Firewall.

Configurare la route SD-WAN

Definire i criteri di corrispondenza

  1. Aprire Routing > SD-WAN routes.
  2. Selezionare IPv4 o IPv6 e fare clic su Add.
  3. Inserire un nome univoco come Clients_M365_WAN2.
  4. Selezionare l’Incoming interface da cui entra il traffico da controllare.
  5. Se necessario, selezionare un valore DSCP se i pacchetti in ingresso sono marcati in modo affidabile.
  6. Definire le Source networks e aggiungere Users or groups se necessario.
  7. Limitare il più possibile le Destination networks.
  8. Limitare i Services ai protocolli e alle porte necessarie.
  9. Se necessario, selezionare gli Application objects.
  10. In Link selection settings, scegliere un SD-WAN profile o primary/backup gateway.
  11. Attivare o disattivare consapevolmente Route only through specified gateways.
  12. Salvare la route e spostarla nella posizione corretta; vince la prima route SD-WAN corrispondente.
  13. Testare con un client e una destinazione definiti.

Gli Application Objects richiedono una Web Protection License attiva. La prima connessione viene instradata in base a destination IP, porta, protocollo e incoming interface tramite un’altra route SD-WAN corrispondente oppure, in mancanza, tramite la default route. L’Application Object si applica alle connessioni successive solo dopo il riconoscimento dell’applicazione. I dati di classificazione hanno una TTL di 3600 secondi dall’avvio della sessione. Per le Micro Apps, solo DPI Engine Mode supporta tutte le applicazioni; Web Proxy Mode supporta solo Pattern Applications e Synchronized Security Applications.

In un cluster HA, SFOS sincronizza questa cache di Application Routing tramite il link HA dedicato usando multicast 226.1.1.1 sulla porta 4455. Un riavvio del firewall cancella i dati di classificazione. Dopo un riavvio o un problema HA, non basta quindi controllare lo stato del tunnel o del gateway; occorre generare di nuovo una prima connessione applicativa e una connessione successiva.

Scegliere gateway o SD-WAN profile

I primary/backup gateway sono sufficienti per un percorso preferito e un fallback. Per utilizzare un SD-WAN profile si creano almeno due gateway, quindi il profile in Routing > SD-WAN profiles e infine lo si seleziona nella route. Un profile è utile con più percorsi, load balancing o criteri SLA:

  • First available gateway usa il primo gateway disponibile nell’ordine definito.
  • Load balancing distribuisce le connessioni; Session Persistence e Gateway Weights controllano affinità e distribuzione.
  • Best quality confronta un solo criterio: latenza, jitter o perdita di pacchetti.
  • Custom SLA richiede soglie per tutti e tre i criteri e usa la strategia di routing scelta se non vengono rispettate.

Gli Health Checks verificano tramite ping o TCP fino a due Probe Targets. Questi target devono rappresentare il percorso rilevante, ma non dimostrano che un’intera applicazione funzioni. Con Best Quality, il failback avviene solo se il gateway originale è migliore di 10 ms per la latenza o di 5 ms per il jitter; per la perdita di pacchetti non esiste un margine simile.

Un profile può contenere da due a otto gateway. Con Load balancing sono disponibili Round-robin o Session Persistence in base a source IP, destination IP, source e destination oppure a una singola connessione; i Gateway Weights opzionali rappresentano capacità differenti dei collegamenti. Se sono configurati due Probe Targets, SFOS verifica prima il primo. Se non risponde, passa al secondo e vi rimane finché questo risponde. Il semplice ritorno del primo target non provoca un passaggio immediato.

Se Route only through specified gateways è attivo, il firewall scarta il traffico quando i percorsi indicati non sono disponibili. Senza questa opzione controlla altre route SD-WAN e poi la default route. Se si elimina un backup gateway, Sophos Firewall lo imposta su None; eliminando il primary gateway o l’SD-WAN profile viene eliminata anche la route e può subentrare la default route.

Coordinare route precedence e NAT

Route precedence determina l’ordine tra Static, SD-WAN e VPN. Le reti direttamente connesse e SSL VPN appartengono alla categoria Static. L’ordine attuale è visibile in Routing > SD-WAN routes o nella Device Console; modifiche e rollback sono spiegati in Modificare in modo sicuro la route precedence di Sophos Firewall.

Il routing sceglie il percorso, mentre NAT modifica gli indirizzi. Il traffico Internet tramite WAN2 può quindi richiedere MASQ o un IP SNAT fisso su quel percorso. Per reti interne e VPN, invece, NAT è spesso indesiderato. Le relazioni sono spiegate in Capire NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Testare e approvare la route

Test standard con traffico reale

  1. Scegliere un client di test con IP noto e una destinazione univoca.
  2. Attivare il logging nella regola firewall corrispondente.
  3. Avviare una connessione reale.
  4. In Log viewer, controllare source, destination, service, rule ID, NAT ID e gateway.
  5. Controllare il traffic count della route SD-WAN: OUT conta le request e IN le reply solo se source e destination corrispondono nella rispettiva direzione.
  6. In System services > Log settings, attivare il tipo SD-WAN e controllare il modulo SD-WAN in Log Viewer per gli eventi di profile, SLA e route.
  7. In caso di dubbi, impostare in Diagnostics > Packet capture un filtro preciso su client, destinazione e porta.

Il Policy tester non considera le route SD-WAN. Può verificare i match delle policy, ma non conferma né la route SD-WAN scelta né il gateway effettivo. Per un’analisi completa, vedere Testare regole Sophos Firewall con Log Viewer, Policy Test e Packet Capture.

Valutare SD-WAN performance

In Diagnostics > SD-WAN performance si seleziona il SD-WAN profile utilizzato. In alternativa, si apre Routing > SD-WAN profiles, si seleziona il profile e, in Status, si fa clic su Historical performance. Per ogni gateway, la vista mostra il numero totale di connessioni, i dati trasferiti, i pesi di load balancing assegnati, oltre a latenza, jitter e perdita di pacchetti per Live, 24h, 48h, Week o Month.

Secondo Sophos, No data to display significa che nessuna route utilizza ancora il profile selezionato oppure che non passa traffico attraverso una route di questo tipo. Il messaggio non dimostra quindi un errore di misurazione. Si genera prima un flusso controllato sulla route prevista e lo si conferma con Log Viewer o Packet Capture.

Reset data transfer and connection count modifica i contatori. Prima del reset si documentano valori e orario. Anche un grafico senza anomalie non dimostra ancora che regola firewall, NAT, applicazione e percorso di ritorno funzionino; questi livelli rimangono parte del test reale.

Testare failover e failback in sicurezza

Un test di guasto controllato si esegue durante una finestra di manutenzione, con rollback documentato e un percorso di gestione indipendente verso il firewall. Prima si controllano nella Device Console gli attuali valori di stato in sola lettura:

system route_precedence show
show routing reroute-connection
show routing reroute-snat-connection

Successivamente si avvia traffico applicativo reale, si rende indisponibile in modo controllato il primary gateway e si verificano percorso, sessioni, Public Source IP e ritorno. Per questo test non si devono eliminare primary gateway o SD-WAN profile, perché ciò rimuove la route e verifica solo il fallback sulla default route. Anche la modifica della route o del profile e un cambiamento della Route Precedence possono instradare nuovamente le connessioni esistenti e non devono far parte dello stesso test di riferimento. Con selezione diretta primary/backup, le nuove connessioni tornano al primary quando rientra; quelle esistenti restano generalmente sul backup gateway.

reroute-connection è attivo per impostazione predefinita e riguarda connessioni senza SNAT. Le connessioni SNAT non vengono reindirizzate per impostazione predefinita; anche con reroute-snat-connection attivato separatamente, funziona solo se entrambi i percorsi usano lo stesso Source IP tradotto. Con MASQ o indirizzi Override Source Translation diversi, la connessione SNAT non viene reindirizzata e la sessione esistente si interrompe quando il percorso cade.

Individuare i problemi in modo sistematico

La route non corrisponde

  • Confrontare incoming interface, source network, destination e service con il flusso reale.
  • Controllare l’ordine; vince la prima route SD-WAN corrispondente.
  • Per gli Application Objects, verificare licenza, riconoscimento DPI e una seconda connessione dopo la classificazione.
  • Non usare il traffic count come unica prova, perché request e reply vengono contate solo con criteri source/destination corrispondenti.
  • Con Direct Web Proxy non basta un service HTTP/HTTPS: usare Any o un service per la porta configurata in Web > General settings > Web proxy listening port. In questo caso speciale, source network e incoming interface non corrispondono per i reply packet; il ritorno del proxy richiede inoltre un WAN default gateway o una route statica adeguata.
  • Per una route SD-WAN migrata da SFOS 17.5 o precedente, verificare se è stata eliminata la regola firewall originale. Queste route migrate restano collegate alla vecchia regola e vengono eliminate insieme ad essa.
  • Per IPv6, Dead Gateway Detection nelle route SD-WAN non monitora traffico di rete di terze parti come SNMP. L’assenza di una misurazione esterna non è quindi una prova affidabile dello stato DGD.

Configurare Direct Web Proxy con un file PAC descrive listener, distribuzione ai client, regola di protezione e test con traffico reale.

Per reply packet e system-generated traffic si applicano switch e regole di corrispondenza separati. Questi casi sono spiegati in Verificare il routing SD-WAN Sophos Firewall per reply packets e system traffic.

Il traffico prende il percorso sbagliato

  • Per destinazioni IPv4 pubbliche, sostituire Any con Internet IPv4 group o destinazioni specifiche.
  • Controllare route precedence, soprattutto se sono interessate reti interne, SSL VPN o IPsec policy-based.
  • Controllare lo stato di gateway e SLA e gli Health Check Targets.
  • Confrontare la regola NAT e il Source IP tradotto con il gateway effettivamente utilizzato.
  • Verificare se un primary gateway o SD-WAN profile è stato eliminato, rimuovendo anche la route.

L’applicazione o la risposta non funziona dopo il failover

Per prima cosa, con Packet Capture verificare se il pacchetto esce dal gateway previsto e se la risposta torna. Controllare poi NAT, allowlist di IP pubblici, Session Persistence, MTU/MSS e lo stato del percorso VPN o MPLS. SIP/RTP, portali bancari e API con Source IP fisso devono essere testati soprattutto con traffico applicativo reale.

Se il problema è iniziato dopo un aggiornamento firmware, consultare le note di rilascio attuali di SFOS 22.0 prima di apportare modifiche estese alle regole. SFOS 22.0 MR1 corregge, tra gli altri problemi, interruzioni SD-WAN casuali e audio unidirezionale tramite VPN route-based con SD-WAN routing.

Gestione e documentazione

Per ogni route SD-WAN in produzione si documentano scopo, incoming interface, source/destination, services, gateway o profile, fallback, comportamento NAT previsto, client di test, destinazione di test, owner e data di revisione. Dopo modifiche a provider, VPN, interfacce o servizi cloud si verificano nuovamente match, log e failover.

Una route è approvata solo quando:

  • i criteri di corrispondenza includono solo il traffico previsto
  • regola firewall, NAT e route precedence corrispondono al design
  • Log Viewer e Packet Capture confermano il percorso previsto
  • failover, failback e Public Source IP si comportano come documentato
  • sono registrati un responsabile e la prossima data di revisione