Configurare e testare route SD-WAN Sophos Firewall

Le SD-WAN routes su Sophos Firewall controllano quale percorso deve prendere un determinato traffico. Sono utili con più linee WAN, MPLS, VPN IPsec route-based, VoIP, servizi cloud o applicazioni che devono usare un provider specifico.

Nella pratica, i problemi SD-WAN raramente dipendono dal pulsante di configurazione. Di solito i criteri sono troppo ampi, i gateway sono valutati male, le regole NAT non sono coerenti, la route precedence sorprende oppure i test sono troppo imprecisi. Questo articolo copre quindi configurazione, pianificazione, validazione e troubleshooting tipico.

Video guida

Risposta breve

Una SD-WAN route si crea in Routing > SD-WAN routes. Prima dovrebbe essere chiaro:

• quale traffico deve essere indirizzato
• quali source, destination, services e utenti sono interessati
• se DSCP, applicazione o utente sono criteri di match davvero stabili
• quale gateway o SD-WAN profile viene usato
• se il traffico può passare solo dai gateway specificati
• se route statiche, VPN routes o route precedence entrano in conflitto
• se NAT corrisponde alla route
• se le connessioni esistenti possono davvero continuare durante il failover
• come verificare il percorso in Log viewer e Packet capture

Una buona SD-WAN route è abbastanza precisa da indirizzare solo il traffico desiderato. Una route ampia con Any può altrimenti influenzare reti interne, accesso di management o traffico VPN.

Quando le SD-WAN routes hanno senso

Le SD-WAN routes sono policy routing. Si usano quando la normale tabella di routing non basta per indicare quale traffico deve usare quale percorso.

Casi tipici:

• Due o più linee Internet: inviare applicazioni specifiche su una linea preferita o su un percorso di failover.
• VoIP o Teams: preferire una linea con bassa latenza o jitter ridotto.
• Servizi cloud: guidare consapevolmente traffico Microsoft 365, ERP o backup.
• VPN IPsec route-based: instradare traffico tramite interfaccia XFRM o gateway profile.
• MPLS o collegamento di sede: raggiungere reti interne tramite percorso dedicato.
• Provider con vincolo di IP sorgente: inviare traffico tramite la WAN che corrisponde alla public IP consentita.

Se bisogna raggiungere solo una rete di destinazione statica tramite un next hop chiaro, una route statica può essere più semplice e robusta. SD-WAN è utile quando servono criteri, selezione del gateway, failover o valutazione delle performance.

Come Sophos valuta le SD-WAN routes

Sophos Firewall elabora le SD-WAN routes secondo una logica chiara, non come un elenco casuale:

1. Controllare l’ordine in Routing > SD-WAN routes. Le regole vengono valutate dall’alto verso il basso. Vince la prima route corrispondente.
2. Controllare i criteri di match. Incoming interface, DSCP, source, destination, service, utente o applicazione decidono se la route corrisponde.
3. Controllare la selezione del gateway. La route usa gateway primary/backup fissi o un SD-WAN profile.
4. Considerare stato gateway e SLA. Con SD-WAN profiles, latenza, jitter, packet loss e obiettivi di health check possono influenzare la scelta.
5. Controllare route precedence. Static, SD-WAN e VPN vengono valutati secondo l’ordine globale.
6. Comprendere il fallback. Se non è disponibile un percorso SD-WAN adatto, può essere usata un’altra SD-WAN route o la default route, secondo il design.

Per questo non basta aprire solo la singola route. Ordine, stato gateway, SLA, NAT, regola firewall e route precedence vanno controllati insieme.

Pianificazione e requisiti

Prima di creare la route, il flusso desiderato deve essere descritto in modo concreto. Una frase come “Teams deve uscire da WAN2” è troppo vaga. Meglio una piccola matrice:

• Source zone: LAN
• Source network: Client_Net_10.20.0.0_24
• Destination: gruppo Microsoft 365, Internet IPv4 group, gruppo FQDN o rete specifica
• Services: HTTPS, UDP 3478-3481 o servizi definiti
• DSCP o applicazione: usare solo se marcatura o rilevamento applicativo possono essere verificati in modo affidabile
• Utente/gruppo: opzionale, solo se User Matching è stabile
• Gateway primario: WAN2
• Fallback: WAN1
• Regola di fallback: consentire la Default Route o imporre Route only through specified gateways
• NAT: MASQ o IP SNAT fisso coerente con il gateway
• Test: IP client, destinazione, gateway atteso, log atteso

Più questa matrice è chiara, meno si dovrà indovinare dopo. Soprattutto con VoIP, VPN, servizi cloud e più sedi, non conviene iniziare con Any solo perché è più rapido da cliccare.

Requisiti

• Sophos Firewall in modalità gateway.
• Almeno un gateway configurato in Network > WAN link manager o un percorso VPN/XFRM adatto.
• Reti source e destination note.
• Regole firewall coerenti per il traffico.
• Regole NAT coerenti, se il traffico deve essere tradotto.
• Logging sulle regole firewall rilevanti.
• Accesso a Log viewer e Diagnostics > Packet capture.

Per zone, interfacce e gateway, vedere Configurare zone e interfacce Sophos Firewall. Se la SD-WAN route riguarda una VPN IPsec route-based, leggere anche Creare una route IPsec su Sophos Firewall.

Configurazione e dipendenze

Creare una SD-WAN route

Percorso menu:

Routing > SD-WAN routes

Procedura:

1. Aprire Add.
2. Selezionare IPv4 o IPv6.
3. Usare un nome chiaro, ad esempio Clients_M365_WAN2.
4. Selezionare Incoming interface o il contesto source coerente con il design. Con IPsec route-based può essere anche un’interfaccia XFRM.
5. Selezionare opzionalmente DSCP se i pacchetti in ingresso sono marcati in modo affidabile.
6. Impostare source networks o utenti solo quanto necessario.
7. Scegliere consapevolmente destination networks, FQDN Hosts, Internet Services o Internet IPv4 group.
8. Limitare services ai protocolli necessari.
9. Usare application objects solo se rilevamento applicativo e prima connessione possono essere testati.
10. Selezionare gateway o SD-WAN profile.
11. Decidere se Route only through specified gateways deve essere attivo.
12. Salvare la regola e posizionarla correttamente nell’ordine.
13. Testare con un client definito.

L’interfaccia può variare leggermente in base alla versione SFOS. L’importante è che la route corrisponda al flusso voluto e non catturi per errore più traffico del previsto.

Per destinazioni Internet, Destination networks non dovrebbe restare su Any per comodità. Sophos consiglia il gruppo standard Internet IPv4 group o i singoli intervalli standard come Internet IPv4 (1-9) per destinazioni IPv4 pubbliche. Questo riduce il rischio che reti interne vadano improvvisamente verso un WAN gateway a causa di una SD-WAN route troppo ampia.

Gli application objects sono utili, ma meno deterministici di una rete di destinazione e di un service. Sophos Firewall usa dettagli della prima sessione per associare sessioni successive di un’applicazione a una SD-WAN route. Queste informazioni di sessione applicativa hanno una TTL di 3600 secondi dall’inizio della sessione. Per percorsi critici, quindi, conviene testare con traffico applicativo reale e non solo con un singolo ping o policy test.

Scegliere gateway e SD-WAN profile

Le SD-WAN routes possono puntare direttamente a gateway oppure usare SD-WAN profiles. La scelta dipende dall’obiettivo.

• Gateway fisso: utile quando il traffico deve usare deliberatamente una linea.
• Gateway con backup: utile quando una linea è preferita, ma deve essere possibile il failover.
• SD-WAN profile con First available gateway: utile quando i gateway devono essere controllati in un ordine definito.
• SD-WAN profile con Load balancing: utile quando più link devono essere usati contemporaneamente e session persistence o ponderazione sono adatte al servizio.
• SD-WAN profile con SLA: utile quando latenza, jitter o packet loss devono decidere la selezione del gateway.
• Interfaccia XFRM o percorso VPN: utile quando IPsec route-based fa parte del routing.

Con più linee WAN, verificare anche se gateway monitoring, criteri di failover e routing del provider sono realistici. Un gateway può essere tecnicamente “up” anche se una specifica applicazione target non funziona correttamente tramite quel provider.

Nei SD-WAN profiles, il target di health check deve essere coerente con l’applicazione. Un ping generico verso Internet non prova che Microsoft 365, VoIP, un ERP cloud o un gateway remoto funzionino bene tramite quel provider. Per applicazioni critiche è utile una breve baseline: latenza normale, jitter, packet loss, gateway atteso e comportamento in caso di guasto provider.

Con First available gateway, la firewall controlla i gateway nell’ordine definito e usa il primo percorso disponibile. Con Load balancing, distribuisce il traffico su più gateway adatti; Session Persistence e Gateway Weights decidono poi quanto una sessione resti stabile sullo stesso gateway e quanto siano ponderate le singole linee.

Con Best quality, la firewall valuta solo il criterio selezionato, ad esempio latenza o packet loss. Con Custom SLA, devono corrispondere i valori limite definiti per latenza, jitter e packet loss. Se nessun gateway soddisfa lo SLA, la decisione ricade sulla strategia di routing scelta. Questo comportamento dovrebbe essere provocato volutamente nel test, altrimenti in caso di guasto resta solo un’ipotesi.

Se Route only through specified gateways è attivo, il traffico viene scartato quando i gateway indicati o il profile non sono disponibili. Se l’opzione non è attiva, la firewall può usare altre SD-WAN routes corrispondenti o alla fine la Default Route. Entrambe le scelte possono essere corrette: per compliance o provider IP binding lo scarto rigido è spesso migliore; per un normale Internet failover spesso è desiderato un ulteriore fallback.

Un altro caso operativo viene facilmente trascurato: se un backup gateway viene eliminato, Sophos Firewall imposta il valore backup su None. Se il primary gateway si guasta, la firewall usa il backup gateway. Quando il primary torna disponibile, le nuove connessioni tornano al primary, ma le connessioni esistenti possono restare sul backup. Se invece viene eliminato un primary gateway o un SD-WAN profile, la route associata può scomparire e il traffico può ricadere sulla Default Route.

Sophos descrive il passaggio dinamico come zero-impact failover. Nella pratica non va letto come garanzia per ogni applicazione. Per connessioni normali, reroute-connection può preservare le connessioni durante un cambio gateway. Con SNAT, la limitazione è più chiara: se si usa MASQ o Override Source Translation con source IP tradotti diversi, la firewall non reroutea deliberatamente tali connessioni SNAT, perché la source IP modificata causerebbe errori di comunicazione. Per provider IP binding, SIP/RTP, portali bancari, API cloud e allowlist fisse, il failover va quindi testato con traffico applicativo reale.

Controllare ordine e route precedence

Le SD-WAN routes non sono isolate. A seconda del design, competono con reti direttamente connesse, route statiche, VPN routes e route precedence globale.

Domande importanti:

• Esiste una route statica più specifica verso la destinazione?
• Una SD-WAN route più ampia più in alto corrisponde al traffico?
• SD-WAN deve essere valutato prima o dopo Static?
• È coinvolta una VPN IPsec policy-based o route-based?
• È coinvolto traffico SSL VPN, che dal punto di vista routing appartiene alla categoria static?
• La route riguarda solo traffico client inoltrato o anche reply packets e system-generated traffic?

L’ordine globale è spiegato in Modificare in modo sicuro la route precedence di Sophos Firewall. Per i casi speciali Reply Packets e System Traffic, vedere Verificare il routing SD-WAN Sophos Firewall per reply packets e system traffic.

Attivare e usare i log SD-WAN

Per semplici test di percorso, i firewall log spesso non bastano. Sophos Firewall può scrivere log specifici SD-WAN che rendono visibili stato health check, decisioni SLA, eventi di profilo e cambi di route.

Controllare:

1. Aprire System services > Log settings.
2. Attivare logging per SD-WAN.
3. In base alle necessità, attivare SD-WAN profile, SD-WAN SLA e SD-WAN route.
4. In Log viewer, controllare il modulo SD-WAN.
5. Nei firewall log, aprire le selezioni avanzate e visualizzare le informazioni SD-WAN.

Questo è particolarmente utile quando un gateway risulta disponibile in WAN Link Manager, ma la SD-WAN route passa a un altro percorso per SLA, health check o decisione del profile.

Non dimenticare NAT

Routing decide dove va un pacchetto. NAT decide se l’indirizzo source o destination viene modificato. Entrambi devono essere coerenti.

Esempi tipici:

• Il traffico Internet su WAN2 può richiedere MASQ o un IP SNAT fisso su WAN2.
• Provider o servizi cloud possono consentire solo una determinata public IP.
• Per reti interne o VPN, NAT è spesso errato perché l’IP source reale deve essere preservato.
• Dopo un failover, la public source IP può cambiare e i sistemi remoti possono scartare le sessioni.

Se una SD-WAN route sembra corretta ma l’applicazione continua a fallire, NAT va controllato presto. Le basi sono in Capire NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Validazione e troubleshooting

Test e validazione

Un gateway verde non dimostra che la SD-WAN route stia colpendo il traffico atteso. Il test deve verificare un flusso reale.

Procedura utile:

1. Usare un client di test con IP noto.
2. Definire esattamente destinazione e servizio.
3. Attivare logging sulla regola firewall.
4. Avviare la connessione.
5. In Log viewer, controllare source, destination, service, Rule ID, NAT ID e gateway.
6. Controllare il contatore della SD-WAN route.
7. Con SD-WAN profiles, controllare anche i log SD-WAN per decisioni SLA o health check.
8. In caso di dubbio, usare Diagnostics > Packet capture con filtro stretto.
9. Far fallire temporaneamente il gateway primario se bisogna validare failover.
10. Dopo il failback, verificare se sessioni e nuove connessioni si comportano come previsto.

Per l’analisi del flusso pacchetti, vedere Testare regole Sophos Firewall con Log Viewer, Policy Test e Packet Capture. Importante: Policy Tester non sostituisce un vero test del flusso pacchetti per SD-WAN.

Errori comuni

• Destination Any per comodità: SD-WAN cattura troppo traffico. Meglio scegliere reti target, FQDN Hosts o Internet Services più stretti.
• Traffico Internet con Any invece di Internet IPv4 group: possono essere inclusi anche target interni, soprattutto se route precedence valuta SD-WAN prima di Static.
• SD-WAN route troppo in alto: un’applicazione o route più specifica viene sovrascritta. Meglio controllare ordine e contatori.
• NAT non coerente con il gateway: l’applicazione vede l’IP source sbagliato o il ritorno si rompe. Meglio verificare NAT e MASQ/SNAT.
• Gateway monitoring troppo generico: il gateway sembra attivo anche se l’applicazione target non è raggiungibile. Meglio scegliere target SLA/monitoring coerenti con il servizio.
• Application objects fraintesi: le route basate su applicazione richiedono traffico applicativo reale e possono dipendere dalla prima sessione. Meglio validare con destination, service, Log Viewer e test ripetuti.
• Direct Web Proxy testato male: il traffico Direct Web Proxy non corrisponde a SD-WAN come il normale traffico client HTTP/HTTPS. Se i client usano il proxy diretto, un service match su HTTP/HTTPS spesso non basta. In quel caso va usata come service la porta del proxy diretto da Web > General settings > Web proxy listening port, oppure il caso speciale va testato consapevolmente con Any. Per reply packets, anche source network e incoming interface non sempre corrispondono alle aspettative.
• Log SD-WAN disattivati: i cambi di percorso sono difficili da capire. Meglio attivare logging di SD-WAN profile, SLA e route.
• Route precedence ignorata: una route statica o VPN route si comporta diversamente dal previsto. Meglio documentare e testare route precedence.
• Reply traffic classificato male: le risposte non passano dal percorso atteso. Meglio verificare Packet Capture e l’opzione reply packet.
• Usage Counter interpretato male: il contatore mostra solo traffico che corrisponde a source e destination della route. Reply traffic può usare lo stesso percorso e comunque non apparire nel contatore atteso.
• Gateway o profile eliminato: una SD-WAN route può cambiare o sparire se vengono eliminati gateway o profile dipendenti. Il traffico può poi ricadere sulla Default Route.
• Più modifiche contemporanee: la causa resta poco chiara. Meglio fare una modifica, testarla e poi continuare.

Troubleshooting

Se la SD-WAN route non funziona come previsto, non conviene “risolvere” subito allargando le regole. È meglio isolare il problema.

Controllare:

1. Il pacchetto arriva alla firewall?
2. Colpisce la regola firewall attesa?
3. La SD-WAN route mostra match nel contatore?
4. Un’altra SD-WAN route più in alto è più specifica o più ampia?
5. Il service corrisponde davvero, ad esempio TCP/UDP e porta?
6. NAT viene applicato ed è voluto?
7. Il pacchetto lascia la firewall dal gateway atteso?
8. La risposta torna indietro?
9. Esistono route statica, VPN route o route precedence che influenzano il percorso?
10. I log SD-WAN mostrano un cambio SLA, health check o profile?
11. Route only through specified gateways è attivo e il traffico viene quindi scartato deliberatamente?
12. È stato eliminato un gateway, un SD-WAN profile o una regola firewall collegata migrata?
13. Con Direct Web Proxy: viene controllata la porta del proxy diretto invece di solo HTTP/HTTPS?
14. Con SNAT/MASQ: cambia la source IP tradotta durante il failover?

Se Packet Capture non vede alcun pacchetto, il problema è prima della firewall: gateway client, VLAN, switch, routing locale o test errato. Se il pacchetto arriva ma prende il percorso sbagliato, i prossimi controlli sono criteri SD-WAN, ordine, NAT e route precedence.

Controllo operativo

Le SD-WAN routes dovrebbero essere documentate e controllate regolarmente dopo l’introduzione. È particolarmente importante con cambi provider, nuove VPN, ulteriori linee WAN o modifiche ai servizi cloud.

Documentare:

• scopo della route
• criteri source e destination
• DSCP, user o application matching se usati
• services
• gateway o SD-WAN profile
• impostazione di Route only through specified gateways
• aspettativa NAT
• comportamento failover
• client e destinazione di test
• owner e data di review

Per applicazioni business critical deve essere chiaro anche chi reagisce a guasti provider, problemi di failover o cambi di public IP.

Lista di controllo

• Obiettivo del traffico e intenzione della route descritti chiaramente.
• Source, destination e services non sono inutilmente ampi.
• Destinazioni Internet non modellate inutilmente con Any, ma con gruppi Internet o destinazioni concrete.
• DSCP, user e application matching usati solo se il traffico reale è stato testato con essi.
• Gateway o SD-WAN profile scelto consapevolmente.
• Route only through specified gateways attivato o disattivato consapevolmente.
• Regola firewall e regola NAT coerenti con la route.
• Route precedence controllata.
• Log SD-WAN attivati per validazione o troubleshooting.
• Reply packets e system-generated traffic inclusi solo se necessario.
• Log Viewer e Packet Capture usati per la validazione.
• Failover e failback testati se fanno parte del design.
• Route documentata e assegnata a un owner.

Domande frequenti