Verificare il routing SD-WAN per Reply Packets e System Traffic

Le SD-WAN Routes di Sophos Firewall non riguardano soltanto il classico traffico dai client verso Internet. A seconda dell’ambiente, possono interessare anche i Reply Packets e il traffico generato dal sistema. Proprio in questi casi possono verificarsi problemi di routing difficili da individuare: la regola sembra corretta e il gateway è attivo, ma le risposte seguono il percorso sbagliato oppure il firewall non raggiunge un servizio tramite la connessione prevista.

Questa guida illustra le due opzioni CLI reply-packet e system-generate-traffic, quando è opportuno verificarle e come testare le modifiche in sicurezza. Per la configurazione standard di una SD-WAN Route, consultare prima Configurare e testare una SD-WAN Route su Sophos Firewall. Per l’ordine generale tra route statiche, SD-WAN Policy Routes e route VPN, vedere anche Modificare in sicurezza la Route Precedence su Sophos Firewall.

⚠️ Queste impostazioni possono influire immediatamente sul routing di produzione. Prima di modificarle, documentare lo stato attuale, scegliere una finestra di manutenzione e predisporre una procedura di ripristino chiara. Sono particolarmente critiche le SD-WAN Routes estese con Any, una Route Precedence che antepone SD-WAN alle Static Routes e il routing SD-WAN attivo per System Traffic o Reply Packets.

Concetti di base e limiti

Funzione delle due opzioni

Con le SD-WAN Routes è necessario distinguere tra il normale traffico inoltrato, i pacchetti di risposta e il traffico generato dal firewall stesso. Le due opzioni non stabiliscono se una singola SD-WAN Route è configurata correttamente. Estendono invece i tipi di traffico che possono essere presi in considerazione dal routing basato su policy SD-WAN.

Le due opzioni svolgono funzioni diverse:

• reply-packet: riguarda i pacchetti di risposta relativi a traffico esistente. Consente di influenzare tramite SD-WAN il percorso di ritorno in determinati scenari non-WAN.
• system-generate-traffic: riguarda il traffico generato dal firewall stesso. Consente di instradare le connessioni originate dal firewall tramite SD-WAN Routes definite.

Non è opportuno attivare entrambe le opzioni alla cieca solo perché “SD-WAN non funziona”. Occorre prima stabilire se il problema interessa davvero Reply Packets o traffico generato dal sistema. Per le connessioni normali, la causa è spesso una Firewall Rule, il NAT, la Route Precedence, lo stato del gateway oppure una SD-WAN Route troppo estesa.

Reply Packets

I Reply Packets sono pacchetti di risposta relativi a traffico esistente. Sulle interfacce WAN, Sophos Firewall impone in linea di principio un routing simmetrico per queste risposte: i pacchetti devono uscire dalla stessa interfaccia WAN attraverso la quale è arrivata la connessione originale.

L’opzione reply-packet è particolarmente rilevante quando, in determinati scenari, i pacchetti di risposta devono essere presi in considerazione dal routing basato su policy SD-WAN. Un esempio tipico è il routing asimmetrico su interfacce non-WAN, ad esempio tra LAN e DMZ.

Occorre considerare un limite importante: se il traffico originale passa attraverso la Default Route o il WAN Link Load Balancing, le SD-WAN Routes non si applicano a questi Reply Packets. Il firewall continua a utilizzare il percorso di ritorno appropriato tramite l’interfaccia della connessione originale.

Domande utili per la verifica:

• Si tratta davvero di traffico di risposta e non di una nuova connessione?
• Il traffico passa attraverso WAN, LAN, DMZ, XFRM o un’altra zona?
• Esiste una SD-WAN Route che deve influenzare intenzionalmente il percorso di ritorno?
• La route è troppo estesa, ad esempio con Destination Any?
• La Route Precedence fa sì che la route venga valutata prima di una route statica o VPN?

Traffico generato dal sistema

Il traffico generato dal sistema è quello prodotto direttamente da Sophos Firewall. A seconda dell’ambiente, può includere richieste DNS, download delle firme, richieste di autenticazione, DHCP, NTP, Syslog o connessioni a Sophos Central. Per impostazione predefinita, questo traffico utilizza i gateway WAN attivi configurati in Network > WAN link manager.

Per questo traffico, Incoming interface e Source networks non sono noti e non costituiscono quindi selettori adatti. In una SD-WAN Route destinata al traffico del firewall, si devono pertanto limitare in modo mirato soltanto Destination networks e Services, lasciando ampi gli altri criteri. Una route con Destination Any potrebbe altrimenti instradare inaspettatamente il traffico di sistema e di gestione sul percorso sbagliato.

Non è necessaria una normale Firewall Rule. In Current activities > Live connections, il traffico generato dal sistema presenta quindi la Firewall Rule ID 0. Se è necessario utilizzare un Source IP specifico, non è sufficiente neppure una normale regola SNAT: le regole NAT traducono il traffico inoltrato, mentre per il traffico del firewall può essere necessario configurare sys-traffic-nat nella Device Console, a seconda dello scenario.

Si applicano inoltre due limiti pratici:

• Se tutti i gateway configurati in Network > WAN link manager sono contrassegnati soltanto come Backup, il firewall non inoltra attraverso di essi il traffico generato dal sistema. Almeno un gateway deve essere Active.
• Il traffico RED generato dal sistema su UDP 3410 è traffico Layer 2. Le SD-WAN Routes non si applicano a questo traffico.

Preparazione

Quando verificare queste impostazioni

Le due opzioni sono rilevanti soprattutto nei progetti di routing più complessi. Negli ambienti semplici con una sola WAN, raramente rappresentano il primo intervento da effettuare.

Situazioni in cui la verifica è opportuna:

• Il traffico generato dal firewall non utilizza il percorso WAN o VPN previsto.
• Syslog, Central, DNS, NTP o il monitoring devono passare attraverso una connessione specifica.
• Una route-based IPsec VPN con interfacce XFRM viene utilizzata insieme alle SD-WAN Routes.
• VoIP o altro traffico sensibile funziona attraverso SD-WAN/VPN soltanto in una direzione.
• Packet Capture mostra le risposte su un’interfaccia diversa da quella prevista.
• Dopo un aggiornamento, SD-WAN, IPsec o NAT si comportano in modo diverso rispetto a prima.
• Una SD-WAN Route estesa influenza improvvisamente le reti interne o l’accesso di gestione.

Negli scenari IPsec, consultare anche Risoluzione dei problemi delle VPN IPsec su Sophos Firewall. Per le singole connessioni, Testare una Firewall Rule di Sophos Firewall con Log Viewer e Packet Capture è spesso il punto di partenza migliore.

Visualizzare lo stato attuale

I comandi vengono eseguiti nella Device Console, non nella Advanced Shell. Se l’accesso alla console non è ancora stato configurato, consultare Collegarsi a Sophos Firewall tramite SSH.

Verificare lo stato per i Reply Packets:

show routing sd-wan-policy-route reply-packet

Verificare lo stato per il traffico generato dal sistema:

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

Inoltre, nel WebAdmin, il tooltip delle informazioni di routing in Routing > SD-WAN routes indica se il routing SD-WAN è attivo per il traffico generato dal sistema e per i Reply Packets.

Documentare anche la Route Precedence attuale:

system route_precedence show

Prima di ogni modifica, documentare l’output corrente. Questa operazione è importante perché un rollback può essere eseguito correttamente soltanto se lo stato precedente è noto.

Modificare la configurazione

Attivare o disattivare le opzioni

Attivare il routing SD-WAN per i Reply Packets:

set routing sd-wan-policy-route reply-packet enable

Attivare il routing SD-WAN per il traffico generato dal sistema:

set routing sd-wan-policy-route system-generate-traffic enable

Eseguire quindi nuovamente i comandi di stato e documentare l’output.

Per disattivare in modo mirato le opzioni, utilizzare i comandi inversi:

set routing sd-wan-policy-route reply-packet disable
set routing sd-wan-policy-route system-generate-traffic disable

⚠️ Non apportare più modifiche al routing contemporaneamente. Se si modificano nello stesso momento Route Precedence, SD-WAN Route, regola NAT e queste opzioni CLI, diventa molto difficile attribuire correttamente un eventuale errore.

Procedura sicura per le modifiche

Una procedura pragmatica riduce il rischio:

1. Definire con precisione il traffico interessato: Source, Destination, Service, Zone e gateway previsto.
2. Documentare le SD-WAN Routes, i gateway e la Route Precedence esistenti.
3. Verificare se Destination Any è davvero necessario.
4. Documentare lo stato attuale di reply-packet e system-generate-traffic.
5. Modificare una sola opzione.
6. Eseguire un test con un esempio di traffico chiaramente definito.
7. Controllare Log Viewer, Packet Capture e i contatori del gateway.
8. Documentare il risultato e solo successivamente apportare ulteriori modifiche.

Se la modifica potrebbe interessare l’accesso di gestione, deve essere disponibile una seconda modalità di accesso: console locale, altro percorso interno oppure accesso da una rete di gestione non interessata.

Verifica dopo la modifica

Dopo l’attivazione, lo stato verde del gateway non è sufficiente. È necessario verificare che il traffico desiderato utilizzi davvero il percorso previsto.

Live Connections, Log Viewer e contatori SD-WAN

Per il traffico inoltrato, controllare nel Log viewer gli eventi relativi al firewall e a SD-WAN. Nelle Firewall Rules interessate deve essere attiva l’opzione Log firewall traffic. Il traffico generato dal sistema, invece, non è controllato da una Firewall Rule. In Current activities > Live connections lo si riconosce dalla Firewall Rule ID 0 e dalle interfacce Inbound e Outbound.

Elementi da verificare:

• Si tratta di traffico inoltrato con una Firewall Rule ID oppure di traffico di sistema con ID 0?
• Quale NAT Rule ID viene utilizzata per il traffico inoltrato?
• Quale gateway o interfaccia compare nel log?
• Sono presenti drop, violazioni delle policy o decisioni inattese delle Security Features?
• La SD-WAN Route mostra soltanto OUT per le richieste o anche IN per le risposte? I contatori compaiono soltanto quando i criteri Source e Destination corrispondono alla rispettiva direzione.

Packet Capture

Con Diagnostics > Packet capture è possibile verificare il flusso effettivo dei pacchetti. Per analizzare il routing, impostare un filtro preciso: Source IP, Destination IP, porta e protocollo.

Confrontare i seguenti aspetti:

• Il pacchetto arriva sull’interfaccia prevista?
• Esce dal firewall attraverso l’interfaccia prevista?
• La risposta ritorna?
• Viene applicato il NAT?
• Per i Reply Packets, il percorso di ritorno è plausibile?

Per l’utilizzo e l’interpretazione, consultare Utilizzare Packet Capture nel WebAdmin di Sophos Firewall.

Verificare i servizi di sistema

Per il traffico generato dal sistema, testare in modo mirato il servizio interessato:

• DNS: eseguire un lookup DNS sul firewall e verificare il percorso verso la destinazione.
• NTP: controllare lo stato dell’ora e la raggiungibilità del server NTP.
• Syslog: controllare un messaggio di test o un log recente sul collector.
• Sophos Central: verificare la connessione a Central e il reporting.
• Monitoring: verificare SNMP, sFlow o i controlli esterni sul collector.

Se il traffico generato dal sistema non è visibile, controllare se la route richiede criteri superflui come Source networks, Incoming interface, utente o applicazione. Per il traffico del firewall, la decisione dovrebbe basarsi soprattutto su Destination networks e Services. Se la destinazione richiede un indirizzo sorgente specifico, verificare anche il Source IP e un’eventuale configurazione sys-traffic-nat.

Errori e dipendenze

Errori tipici

• SD-WAN Route con Destination Any per percorsi interni: il traffico interno o l’accesso di gestione può essere instradato attraverso la WAN. È preferibile utilizzare gruppi di destinazioni Internet o reti di destinazione specifiche.
• Route Precedence con SD-WAN prima di Static: le reti direttamente connesse o statiche possono essere intercettate inaspettatamente da SD-WAN. Verificare la Route Precedence e, se necessario, anteporre Static a SD-WAN.
• system-generate-traffic attivo senza limitazione della destinazione: i servizi del firewall possono utilizzare il percorso sbagliato. Definire quindi in modo preciso reti di destinazione e Services.
• Reply Packets confusi con normali nuove connessioni: in questo modo si interviene sulla causa sbagliata. Verificare Packet Capture e la direzione del flusso.
• Ricerca di una Firewall Rule per il traffico generato dal sistema: questo traffico ha la Firewall Rule ID 0 e non è controllato da normali Firewall Rules. Verificare route, servizio, Live Connection ed eventualmente sys-traffic-nat.
• Direct Web Proxy trattato come normale traffico HTTP/HTTPS: per il proxy diretto, la SD-WAN Route deve includere la porta configurata in Web > General settings > Web proxy listening port. In alternativa, Services può essere impostato su Any. Source Network e Incoming Interface non corrispondono ai Reply Packets del traffico proxy; per il percorso di ritorno è necessario almeno un gateway WAN o una route statica appropriata.
• Più modifiche al routing contemporaneamente: la causa dell’errore rimane incerta. Procedere per fasi e documentare ogni test.
• Nessun accesso di gestione alternativo: WebAdmin o SSH possono diventare irraggiungibili dalla rete interessata. Predisporre una finestra di manutenzione e un percorso di accesso alternativo.

Il rischio è particolarmente elevato quando si verificano contemporaneamente più condizioni: la Route Precedence antepone SD-WAN a Static, una SD-WAN Route estesa utilizza Any e il routing SD-WAN per il traffico generato dal sistema o per i Reply Packets è attivo. In questo caso, l’accesso a WebAdmin o SSH da determinate subnet interne può andare perso.

Interazione con NAT, IPsec e VoIP

SD-WAN raramente è l’unico elemento coinvolto. In molti malfunzionamenti entrano in gioco anche NAT, IPsec o traffico specifico dell’applicazione.

Per SNAT è importante verificare se lo stesso Source IP viene mantenuto attraverso gateway diversi. Se si utilizzano MASQ o indirizzi sorgente tradotti differenti, il failover o il reindirizzamento possono causare problemi di comunicazione. Per i concetti di base, consultare Comprendere il NAT su Sophos Firewall.

Nelle route-based IPsec VPN, le interfacce XFRM possono essere utilizzate nelle SD-WAN Routes o negli SD-WAN Profiles. In questo caso, verificare insieme lo stato IPsec, la SD-WAN Route, la Route Precedence e le Firewall Rules. I concetti di base delle route-based VPN sono descritti in Route IPsec su Sophos Firewall.

In caso di problemi VoIP, controllare anche SIP, RTP, NAT e SD-WAN. Le release notes di SFOS 22.0 MR1 documentano la correzione di un problema per cui, dopo un aggiornamento a SFOS 22.0 GA, l’audio VoIP attraverso una route-based VPN con routing SD-WAN funzionava soltanto in una direzione. La procedura pratica è disponibile in Risolvere i problemi VoIP con SIP e RTP su Sophos Firewall.

Rollback e conclusione

Rollback

Prima della modifica, documentare lo stato precedente. Se successivamente risultano interessati l’accesso di gestione, i servizi di sistema o il traffico di produzione, non continuare con tentativi improvvisati. Ripristinare innanzitutto lo stato precedente.

In pratica:

1. Ripristinare i valori precedenti documentati per reply-packet e system-generate-traffic utilizzando i comandi enable o disable appropriati.
2. Ripristinare l’ordine precedente della Route Precedence, se è stato modificato.
3. Disattivare temporaneamente le SD-WAN Routes troppo estese o limitarle a destinazioni specifiche.
4. Testare l’accesso di gestione da una rete non interessata.
5. Solo in seguito approfondire la causa effettiva.

Se WebAdmin e SSH non sono più raggiungibili da una subnet interna, ma rimangono accessibili da un’altra subnet, utilizzare quest’ultima per verificare innanzitutto la SD-WAN Route estesa, la Route Precedence e le due opzioni CLI.

Checklist

• Stato attuale delle due opzioni CLI documentato.
• Route Precedence documentata con system route_precedence show.
• Traffico interessato definito con precisione.
• Per il traffico di sistema, utilizzati soltanto Destination e Service come criteri decisivi di corrispondenza.
• SD-WAN Route non configurata inutilmente in modo esteso con Any.
• Route Precedence verificata.
• Almeno un gateway WAN Active disponibile per il System Traffic.
• Connessione di gestione alternativa predisposta.
• Una sola modifica eseguita per ogni test.
• Log Viewer e Packet Capture utilizzati per la verifica.
• NAT, IPsec e Firewall Rules verificati insieme.
• Risultato e rollback documentati nel registro operativo.

FAQ