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 Fusion (in precedenza 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 Fusion. 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.

Per un esempio Teams più mirato, aggiungere il gruppo fittizio Sales_Team in Users or groups e Teams_VoIP in Application objects. Sostituire entrambi i nomi con il proprio gruppo utenti e le applicazioni effettivamente necessarie. Insieme all’interfaccia LAN, a Client_Net_10.20.0.0_24, alle destinazioni e ai servizi previsti, questi criteri indirizzano solo il flusso corrispondente tramite WAN2/WAN1. Verificare separatamente una regola di autorizzazione restrittiva da LAN a WAN per questa sorgente, destinazioni e servizi, i permessi utente previsti e NAT su entrambi i percorsi. La route SD-WAN non concede accesso; il test deve confermare utente, applicazione, Firewall Rule ID e NAT ID previsti.

MPLS tra filiale e sede centrale

Un esempio circoscritto collega 10.20.0.0/24 nella filiale ai server web della rete centrale 10.30.0.0/24: l’interfaccia in ingresso è la LAN della filiale, il primary gateway è MPLS-1, il backup è MPLS-2 e i servizi sono limitati ai TCP 80/TCP 443 necessari. Il firewall centrale richiede la corrispondente route di ritorno da 10.30.0.0/24 a 10.20.0.0/24 tramite i propri gateway MPLS. Reti, interfacce, gateway e servizi sono valori di esempio da adattare alla topologia reale. La regola firewall separata della filiale consente LAN verso la zona MPLS effettiva, qui MPLS_DMZ, solo per queste reti e servizi; anche le regole centrali devono consentire il flusso previsto. Questo design instradato mantiene gli indirizzi privati originali senza SNAT. Non è una regola NAT universale per ogni installazione MPLS. Verificare entrambe le direzioni e il Source IP invariato con traffico reale sui due firewall.

Configurare la route SD-WAN

Definire i criteri di corrispondenza

Per IPv6, selezionare host IP di destinazione specifici anziché una destinazione generica Any. Se una route generale Any deve rimanere, creare sopra di essa una route per gli host IP di destinazione specifici e il gateway previsto; mantenere limitati anche incoming interface, source e services. Prima di modificare qualcosa, registrare l’ordine installato con system route_precedence show, la posizione e le impostazioni della route, verificare un accesso di gestione indipendente e pianificare il ripristino di questi valori. Una route più specifica non giustifica il reset indiscriminato della precedenza globale.

  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.

Creare un Application Object

Il motore DPI può riclassificare un’applicazione nella stessa connessione, ad esempio passando da un sito web alla sua chat. La nuova decisione si applica alle connessioni successive; non garantisce il reindirizzamento della connessione in corso. Se non inizia un’altra sessione entro la TTL di 3600 secondi dall’avvio della sessione, i dettagli di sessione memorizzati vengono eliminati.

Gli Application Objects possono includere applicazioni web, micro app, Synchronized Security Applications rilevate sugli endpoint, applicazioni personalizzate e categorie di applicazioni. Scegliere il tipo in base al riconoscimento necessario e rispettare i limiti di licenza e DPI/proxy descritti sopra; una categoria intera è più ampia di una singola applicazione necessaria.

Un Application Object raggruppa solo le applicazioni che devono utilizzare lo stesso percorso SD-WAN. Aprire Applications > Application object, selezionare Add, assegnare un nome e restringere i risultati tramite Category, Risk, Characteristics, Technology, Classification o la ricerca per nome. Selezionare quindi le applicazioni effettivamente necessarie e salvare l’oggetto. Sophos aggiorna dinamicamente l’elenco delle applicazioni disponibili tramite gli aggiornamenti IPS e Synchronized Application Control; è quindi opportuno ricontrollare la selezione dopo modifiche ai pattern o alle applicazioni.

Il filtro Technology distingue browser-based, client-server, network protocol, P2P e synchronized application control. In Classification sono disponibili new, sanctioned, unsanctioned e tolerated. Questi criteri facilitano la selezione, ma non dimostrano che la route successiva funzioni. Per verificarlo servono prima la connessione di classificazione e poi una nuova connessione di test.

Per Microsoft 365, un unico oggetto collettivo è spesso troppo ampio. Un oggetto come Teams_VoIP può contenere solo le applicazioni Teams destinate alla comunicazione in tempo reale, mentre OneDrive o SharePoint utilizza un altro percorso. Selezionare poi l’oggetto salvato nel campo Application objects della route SD-WAN.

Scegliere gateway o SD-WAN profile

I primary/backup gateway sono sufficienti per un percorso preferito e un fallback. Un SD-WAN profile separa due decisioni: Routing strategy sceglie il percorso con First available gateway o Load balancing; il Service Level Agreement (SLA) opzionale aggiunge misure di qualità a tale strategia. Best quality e Custom SLA non sono quindi due ulteriori strategie di routing.

Configurare un SD-WAN profile in Routing > SD-WAN profiles > Add come segue:

  1. Inserire nome e descrizione, quindi scegliere First available gateway o Load balancing in Routing strategy.
  2. Assegnare da due a otto gateway e trascinarli nell’ordine desiderato. Gateway weights compare solo con il load balancing; pesi diversi possono rappresentare capacità differenti dei collegamenti.
  3. Per il load balancing scegliere Round-robin o un Session persistence type adatto. La persistenza può basarsi su source IP, destination IP, source e destination oppure su una singola connessione.
  4. Attivare SLA solo se latenza, jitter o perdita di pacchetti devono influire sulla scelta. Best quality confronta un solo criterio. Custom SLA verifica latenza, jitter e perdita di pacchetti rispetto alle soglie impostate.
  5. Attivare Health check, scegliere Ping o TCP in Protocol e inserire fino a due Probe targets. Con TCP indicare anche una porta sulla quale il target risponde in modo affidabile. SFOS attiva obbligatoriamente l’Health Check quando lo SLA è attivo.
  6. Impostare Interval between checks, Response time-out, Deactivate gateway after, Activate gateway after e Sample size for SLA in base al servizio. Valori brevi reagiscono più velocemente, ma possono commutare inutilmente durante perdite transitorie; valori maggiori sono più stabili, ma rilevano più tardi un guasto reale.
  7. Salvare il profile, selezionarlo nella route SD-WAN e verificare il percorso con traffico reale.

I due Probe Targets costituiscono un unico test di disponibilità: SFOS considera il gateway attivo se almeno uno risponde. Se il primo non risponde, passa al secondo e continua a usarlo finché risponde. Il ritorno del primo, da solo, non provoca un ritorno immediato al primo target. I target devono quindi trovarsi dietro il gateway e rappresentare il percorso utile; un ping riuscito non dimostra che DNS, TLS o l’intera applicazione funzionino.

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 equivalente. In Routing > SD-WAN profiles, un profile attivo indica che almeno un gateway è disponibile. Link status riepiloga la configurazione, Historical performance apre le misure e Object usage mostra quali route usano il profile. Controllare questi utilizzi prima di modificarlo o eliminarlo.

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.

Con Load balancing e Best quality, il traffico viene distribuito solo se almeno due gateway condividono le migliori prestazioni per il criterio scelto; non tutti i gateway raggiungibili sono idonei. Con Custom SLA, la distribuzione avviene tra i gateway che rispettano le soglie SLA configurate. Un percorso raggiungibile fuori dallo SLA non equivale a un gateway irraggiungibile; questo non stabilisce una regola universale di fallback quando nessun gateway rispetta lo SLA.

Gateway weights descrive un rapporto tra richieste: nell’esempio documentato, 3:1 significa tre richieste su quattro attraverso il primo gateway e una attraverso il secondo. Scegliere i pesi in base alla capacità e alle risorse dei collegamenti; non garantiscono la stessa quota di byte, un throughput specifico o l’aggregazione delle linee.

Per Custom SLA, Maximum latency e Maximum jitter sono espressi in millisecondi e Maximum packet loss in punti percentuali. Interval between checks definisce l’intervallo tra le sonde e Response time-out il tempo di risposta consentito. Deactivate gateway after conta i tentativi di sondaggio consecutivi falliti; Activate gateway after, le risposte consecutive riuscite. Sample size for SLA definisce il numero di campioni delle sonde usati per determinare le prestazioni medie del gateway. Scegliere questi valori per il proprio servizio, senza trasformare un singolo esempio temporale in un valore predefinito universale.

Coordinare route precedence e NAT

L’ordine predefinito documentato è Static → SD-WAN → VPN. Non è necessariamente lo stato di un’installazione esistente: verificare sempre system route_precedence show prima di decidere e non applicare il default automaticamente.

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.

DNAT verso un server dietro IPsec route-based

Una pubblicazione DNAT pubblica può puntare a un server interno che non è collegato localmente, ma si trova dietro un firewall remoto tramite IPsec route-based. In questo caso particolare, DNAT e la route SD-WAN devono riconoscere lo stesso flusso in entrata prima della traduzione e il percorso di ritorno deve passare di nuovo attraverso il firewall che pubblica il servizio.

Il flusso operativo affidabile per SFOS 22 è composto da cinque parti collegate:

  1. In Hosts and services > IP host, creare un oggetto IP preciso per il server remoto.
  2. In Routing > Gateways, creare un gateway con l’IP del gateway remoto e l’interfaccia XFRM corrispondente. Come destinazione di monitoraggio si usa un host stabile e raggiungibile dietro tale gateway.
  3. Configurare la regola DNAT in modo che corrisponda all’interfaccia WAN pubblica e al servizio offerto esternamente, quindi selezionare il server remoto come Translated destination. L’esempio Sophos usa MASQ affinché le risposte tornino al firewall che pubblica il servizio; tuttavia, il server non vede più l’IP originale del client.
  4. Nella route SD-WAN inserire la stessa interfaccia WAN pubblica in Destination networks e la porta esterna in Services. Con PAT si tratta esplicitamente della porta esterna, non della porta di destinazione interna tradotta. Come primary gateway si seleziona il gateway dell’interfaccia XFRM.
  5. Verificare una regola firewall restrittiva per la pubblicazione e testare il flusso da una rete esterna. NAT Rule ID, Firewall Rule ID, la route SD-WAN, il gateway XFRM selezionato, i percorsi di andata e ritorno e l’IP sorgente visibile sul server devono corrispondere al design.

MASQ non è un’opzione cosmetica. Nell’esempio documentato risolve il percorso di ritorno, ma nasconde al server di destinazione l’IP reale del client. Se il sito remoto dispone di un percorso di ritorno verificato verso le reti client originali e l’IP originale deve essere mantenuto, occorre un design di routing pianificato e testato separatamente. La pubblicazione e la protezione generali sono descritte in Pubblicare un server tramite DNAT su Sophos Firewall.

Più server remoti possono usare la stessa route SD-WAN se sono raggiungibili tramite lo stesso gateway e possono essere distinti chiaramente per indirizzo WAN o porta TCP esterna. Se usano gateway diversi, si configurano route SD-WAN separate. Se corrisponde una porta, un oggetto WAN o un gateway errato, la route non va ampliata a Any; occorre prima dimostrare il flusso pre-DNAT con Log Viewer e Packet Capture.

Testare e approvare la route

Controllare l’elenco delle route e lo stato dei gateway

In Routing > SD-WAN routes si può cercare per nome della route, oggetto o valore dell’oggetto; ad esempio, 443 trova le route che usano il servizio HTTPS. Il trascinamento cambia l’ordine. Si tratta di una modifica al traffico, perché SFOS valuta dall’alto verso il basso e si ferma alla prima corrispondenza.

In More options si può attivare o disattivare una route, modificarla o clonarla, azzerare il contatore dei dati oppure eliminarla. Prima dell’azzeramento annotare valore e ora. Una route clonata è autonoma: controllare nome, criteri, posizione, gateway e NAT prima di salvarla o attivarla, quindi verificarne lo stato On/Off effettivo.

Il tooltip dell’icona nella colonna Active mostra stati come In use, Available, Unavailable, In use, but SLA isn't met o Available and SLA isn't met. La disponibilità di un gateway o profile non dimostra né che questa route sia stata effettivamente selezionata né che il percorso di ritorno funzioni.

Con selezione diretta primary/backup, l’icona Active distingue tre stati: almeno un gateway è raggiungibile e la route è attiva; la route non è attiva e Route only through specified gateways è disattivato; oppure non è attiva e l’opzione è attivata. Nell’ultimo caso, il traffico resta scartato se i percorsi indicati sono irraggiungibili, anziché usare altri gateway. Leggere insieme tooltip e casella di controllo, senza equipararli a uno stato SLA di un profile.

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.

Per i log di profile e route nella vista firewall, selezionare il modulo Firewall in Log viewer, aprire la selezione estesa con il pulsante di espansione accanto all’elenco dei moduli, selezionare i log SD-WAN necessari e fare clic su Apply. Questo integra la vista del modulo SD-WAN separato.

Valutare SD-WAN performance

L’asse x dei grafici di qualità mostra il tempo; l’asse y mostra latenza e jitter in millisecondi e perdita di pacchetti in punti percentuali. Assigned weights for load balancing apre i pesi assegnati ai gateway. Misure e pesi non costituiscono l’approvazione dell’applicazione.

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

Prima di una modifica annotare la posizione e lo stato On/Off attuali della route, i primary/backup gateway o il profile usato, l’ordine dei gateway nel profile, i valori SLA e Health Check e la traduzione NAT prevista. Il rollback consiste nel ripristinare esattamente tali valori e poi ricontrollare stato, log e traffico reale.

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.

Modificare consapevolmente il rerouting

Queste impostazioni modificano il traffico; non sono prerequisiti del test di riferimento. Modificarle solo in una finestra di manutenzione con accesso di gestione indipendente verificato e rollback documentato: salvare prima i due stati di rerouting mostrati sopra e verificare che i due percorsi usino lo stesso Source IP tradotto per SNAT. In Device Console sono disponibili le seguenti alternative; eseguire solo il comando necessario alla modifica prevista, non tutti in sequenza:

  • Attivare senza SNAT: set routing reroute-connection enable; disattivare: set routing reroute-connection disable.
  • Attivare per SNAT: set routing reroute-snat-connection enable; disattivare: set routing reroute-snat-connection disable.

Poi verificare con show routing reroute-connection e show routing reroute-snat-connection e testare separatamente sessioni, Source IP e entrambe le direzioni del traffico. Per il rollback, ripristinare ogni impostazione modificata nello stato enable/disable registrato e ripetere i controlli di stato e traffico reale. Questi comandi documentati e questo rollback non sono stati testati qui su un firewall; attivare il rerouting SNAT non elimina i limiti MASQ/IP.

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.

Web Admin e SSH non sono raggiungibili dopo una nuova route

Uno scenario documentato combina quattro impostazioni: SD-WAN precede Static, una nuova route per una rete sorgente interna specifica ha destination Any, il routing SD-WAN per il traffico generato dal sistema è attivo e lo è anche per i reply packet. L’accesso di gestione dalla rete interna interessata può quindi interrompersi, restando disponibile da altre sottoreti. Non sono condizioni necessarie per ogni interruzione della gestione.

Tramite un accesso alternativo già verificato, controllare sorgente, destinazione e precedenza della route, insieme a questi valori in sola lettura nella Device Console:

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

Verificare prima che la gestione da una sottorete non interessata sia effettivamente consentita e raggiungibile. Quindi limitare in modo mirato la destinazione oppure ripristinare una delle impostazioni precedentemente modificate al valore originale documentato. Non eseguire un reset globale alla cieca: salvare prima posizione, impostazioni e precedenza, pianificare il rollback e ricontrollare Web Admin, SSH e il traffico interessato. Senza un accesso alternativo sicuro, non proseguire la modifica da remoto.

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 subito dopo l’upgrade a SFOS 22.0 GA, verificare innanzitutto la build installata. SFOS 22.0 MR1 Build 490 corregge NC-173667, che causava la disconnessione casuale di una route SD-WAN, e NC-177603, per cui l’audio VoIP tramite una VPN route-based funzionava in una sola direzione dopo l’upgrade a 22.0 GA. Se è già installata MR1 o una build successiva, non attribuire il guasto soltanto alla versione firmware; ripetere il test con traffico reale descritto sopra e verificare route, sessioni, NAT e traffico in entrambe le direzioni.

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