Instradare Internet della filiale attraverso la sede via IPsec

Quando il traffico Internet di una filiale deve essere ispezionato centralmente e uscire dalla connessione WAN della sede centrale, Sophos Firewall può utilizzare un tunnel IPsec Site-to-Site policy-based. I client della filiale inviano il traffico attraverso il tunnel anziché direttamente alla WAN locale. Nella sede centrale vengono applicate le regole centrali di firewall, NAT e sicurezza.

LAN filiale → Firewall filiale → IPsec policy-based → Sede centrale → MASQ → Internet

Questo design richiede più di un tunnel VPN verde. Route Precedence, Traffic Selectors, ordine delle regole e percorso di ritorno devono essere coerenti. Se il tunnel o la sede centrale non sono disponibili, in questo design la filiale normalmente non dispone di un breakout Internet locale automatico.

⚠️ Questa procedura si applica solo a IPsec policy-based. Il peer non deve essere route-based. Per design nuovi o in crescita, è consigliabile route-based Any-to-Any: entrambi i peer usano selettori Any, ciascuno riceve un’interfaccia XFRM e sono necessarie route Static, SD-WAN o dinamiche esplicite. Non mescolare quei passaggi con la procedura policy-based seguente. La scelta è spiegata in Configurare una VPN IPsec Site-to-Site.

Esempio e prerequisiti

L’esempio utilizza la rete della filiale 10.20.0.0/24. La sede centrale dispone di una connessione WAN funzionante e di un tunnel policy-based già pianificato. 10.20.0.0/24 è un valore di documentazione e deve essere sostituito con la rete reale della filiale.

Per questo design, la Route Precedence globale deve essere VPN, Static, SD-WAN. Prima di modificarla, salvare il valore attuale e identificare tutti gli altri percorsi Static, VPN e SD-WAN interessati. La procedura controllata è descritta in Modificare Route Precedence in sicurezza.

Il valore predefinito di SFOS 22 è Static, SD-WAN, VPN. Questo design differisce perché Remote subnet: Any crea nella filiale una route VPN policy-based automatica per tutte le destinazioni. Non eliminare la default route Static 0.0.0.0/0 verso la WAN locale: rimane disponibile per il traffico generato dal firewall quando l’uso della VPN è disattivato e per un rollback controllato. Leggere il valore corrente in Device Console con system route_precedence show; l’articolo dedicato contiene comando di modifica, analisi dell’impatto e ripristino.

Prima della modifica devono inoltre essere disponibili:

• un tunnel IPsec policy-based funzionante tra i due firewall;
• accesso amministrativo verificato a entrambe le sedi;
• capacità Internet e firewall sufficiente nella sede centrale;
• DNS, Web Policies, IPS, Application Control e le eccezioni desiderate;
• un backup aggiornato della configurazione e un registro della modifica con selettori originali, Route Precedence, opzione del traffico di sistema e ID firewall e NAT;
• un percorso di ritorno documentato e una finestra di manutenzione.

Con HA, prima della modifica registrare per ogni sede il nodo attivo, lo stato corretto del cluster e l’accesso di amministrazione al peer. HA non sostituisce né una seconda WAN centrale né una seconda sede. Il failover è un test separato e non si deduce da un tunnel verde.

Impostare i selettori IPsec

Nella sede centrale impostare Local subnet su Any e Remote subnet sulla LAN della filiale. Nella filiale utilizzare i valori opposti: la rete locale della filiale e Any come rete remota.

Verificare quindi il tunnel con una destinazione interna nella sede centrale. Attivare il percorso Internet solo quando il traffico tra le sedi funziona in entrambe le direzioni. In questo modo un errore IPsec rimane distinguibile da un problema NAT o di regole.

Creare le regole firewall e NAT

Le regole vengono create in Rules and policies > Firewall rules. Le regole VPN generate automaticamente non costituiscono un design completo per questo percorso Internet.

Sede centrale: da VPN a WAN

Una regola Branch_VPN_to_WAN consente il traffico della filiale verso Internet:

• Action: Accept
• Source zones: VPN
• Source networks: 10.20.0.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: solo i servizi effettivamente necessari
• Log firewall traffic: attivato
• Create linked NAT rule > Translated source (SNAT): MASQ

Web Policy, IPS, Application Control e TLS Inspection vengono selezionati consapevolmente. La regola MASQ collegata traduce i client della filiale nell’indirizzo pubblico della sede centrale. Per il traffico in uscita SFOS valuta prima la regola firewall e poi SNAT; controllare quindi anche l’ordine NAT, perché una regola NAT precedente corrispondente prevale. Inoltre, NAT non crea route e le modifiche NAT valgono solo per le nuove connessioni.

Il percorso di ritorno ha due parti: MASQ riporta le risposte Internet all’indirizzo WAN centrale; la sede usa poi la propria route VPN policy-based automatica per la destinazione ritradotta 10.20.0.0/24. Se la LAN della filiale è dietro un altro router, documentare e testare anche i suoi percorsi di andata e ritorno.

Filiale: consentire da LAN a VPN

La regola Branch_LAN_to_VPN si trova sopra qualsiasi regola locale che consenta da LAN a WAN:

• Action: Accept
• Source zones: LAN
• Source networks: 10.20.0.0/24
• Destination zones: VPN
• Destination networks: Any
• Services: solo i servizi effettivamente necessari
• Log firewall traffic: attivato

⚠️ Chiarire prima il blocco del traffico web: Le indicazioni del produttore su Drop, HTTP/HTTPS, autenticazione e Web Exceptions sono contraddittorie. La sola regola Drop non dimostra quindi il blocco completo dell’accesso Internet locale. Prima dell’uso in produzione, ottenere un chiarimento scritto da Sophos per la versione SFOS, la build e il percorso di elaborazione esatti, oppure verificarli in un test isolato ed espressamente autorizzato. I casi di test e i criteri di arresto sono descritti in azioni e logging delle regole firewall. Non procedere in produzione se l’accesso web è inatteso o non è chiaro.

Segue una regola mirata Branch_LAN_to_WAN_drop per la stessa rete della filiale da LAN a WAN. Realizza la logica di blocco prevista per un percorso Internet locale parallelo al tunnel; il suo effetto effettivo deve essere confermato come descritto sopra. Non includere accidentalmente altre reti o servizi locali esplicitamente necessari.

L’ordine fa parte della sicurezza: eccezioni specifiche, Branch_LAN_to_VPN, quindi Branch_LAN_to_WAN_drop e infine regole più ampie. Dopo le modifiche, verificare con nuove connessioni client e non soltanto con sessioni esistenti.

Creare regole firewall in sicurezza spiega come verificare insieme posizione, Rule ID e regola NAT collegata.

Decidere separatamente il traffico generato dal sistema

Le regole precedenti controllano il traffico client inoltrato. DNS, NTP, aggiornamenti, Central e altre connessioni generate direttamente dal firewall della filiale sono traffico generato dal sistema.

Anche DNS va distinto per origine. Un client con resolver pubblico segue il percorso client nel tunnel. Un resolver interno centrale richiede selettore, regola firewall e percorso di ritorno adeguati. Solo le richieste DNS generate dal firewall seguono l’opzione del traffico di sistema. Per questo si testano separatamente un IP pubblico e un FQDN.

L’impostazione predefinita documentata è enable; non dimostra lo stato effettivo di un’installazione esistente. Le fonti ufficiali SFOS 22/23 esaminate qui non documentano il getter seguente. Pertanto, costituisce solo un riferimento da sottoporre a conferma, non un’istruzione di lettura verificata: utilizzarlo solo se la sintassi e il significato dell’output per la build installata sono confermati dalla relativa guida CLI o dal supporto Sophos. In caso contrario, non eseguirlo e utilizzare un metodo di lettura confermato. Prima di una modifica, rilevare il valore effettivo dell’opzione con questo metodo e annotarlo nel registro della modifica; inoltre, deve essere definita la procedura esatta di ripristino mediante i setter documentati enable o disable. In assenza di un metodo di lettura confermato, del valore precedente effettivo e di una procedura esatta di ripristino, l’opzione non viene modificata.

show routing policy-based-ipsec-vpn system-generate-traffic

Se solo il traffico client deve passare dalla sede centrale, il traffico generato dal firewall può uscire direttamente dalla WAN della filiale:

⚠️ Questa modifica riavvia tutti i tunnel IPsec del firewall. Documentare prima stato, finestra di manutenzione e percorso di ripristino. Non eseguire il comando come semplice test o sulla base di un sospetto.

set routing policy-based-ipsec-vpn system-generate-traffic disable

Subito dopo l’impostazione, leggere nuovamente il valore dell’opzione con lo stesso metodo di lettura confermato; deve essere disable. Questa verifica dello stato non sostituisce i test descritti di seguito su tutti i tunnel, sui servizi firewall necessari e sul percorso dati locale o centrale scelto. Se l’output non è univoco o non corrisponde al valore di destinazione, non apportare ulteriori modifiche sulla base di supposizioni, ma chiarire la discrepanza con il supporto Sophos.

Durante il rollback ripristinare lo stato precedente documentato. Anche il ripristino dell’opzione riavvia tutti i tunnel IPsec; applicare prima le stesse precauzioni relative a stato, finestra di manutenzione e percorso di ripristino. Se l’opzione era attiva, utilizzare:

set routing policy-based-ipsec-vpn system-generate-traffic enable

Se il valore precedente rilevato era disable, il rollback non deve impostare indiscriminatamente enable. Se il valore attuale dell’opzione corrisponde già al valore precedente, non è necessario eseguire nuovamente un setter; in caso contrario, ripristinare esattamente il valore precedente rilevato mediante il setter documentato appropriato. Dopo ogni modifica e ogni rollback, rileggere il valore dell’opzione con lo stesso metodo di lettura confermato e confrontarlo con il rispettivo valore di destinazione o con il valore precedente registrato. Separatamente, verificare nuovamente tutte le connessioni IPsec, i servizi firewall necessari e il percorso dati locale o centrale stabilito. Se il valore riletto è ambiguo o diverso da quello atteso, non dichiarare che il ripristino è riuscito e coinvolgere il supporto Sophos.

Verificare il percorso dati

Un client di 10.20.0.0/24 apre prima un indirizzo IP pubblico e poi un FQDN tramite HTTPS. Il collaudo verifica più livelli:

1. Nella filiale corrisponde Branch_LAN_to_VPN; la regola locale di drop LAN-to-WAN non corrisponde a questo flusso riuscito.
2. Nella sede centrale corrispondono Branch_VPN_to_WAN e la regola MASQ collegata.
3. L’indirizzo IP sorgente visibile pubblicamente appartiene alla sede centrale.
4. DNS, HTTPS e una destinazione volutamente bloccata si comportano secondo la policy centrale.
5. In Diagnostics > Packet capture, In interface, Out interface, Rule ID, NAT ID, Status e Reason mostrano i pacchetti di andata e ritorno nel tunnel e sulla WAN centrale.
6. Il traffico generato dal sistema utilizza il percorso locale o centrale scelto in precedenza.
7. In Current activities > IPsec connections, la connessione rimane stabilita durante il test e il Log viewer non mostra drop inattesi.
8. Con HA, eseguire separatamente un failover del nodo autorizzato e ripetere il test completo. Senza questo test non dichiarare la ridondanza HA.

Uno Speedtest da solo non basta. Verificare anche applicazioni reali, DNS, log di sicurezza e un download prolungato. Per problemi di prestazioni sono disponibili le procedure per test della velocità Internet e MTU e MSS nella VPN.

Errori tipici e rollback

• Il client della filiale utilizza ancora la WAN locale: controllare ordine delle regole, rete sorgente, regola LAN-to-VPN e regola di drop. Non aggiungere un’eccezione ampia come soluzione rapida.
• Il tunnel è verde ma Internet non funziona: nella sede centrale controllare regola VPN-to-WAN, Rule ID, MASQ, gateway WAN, DNS e percorso di ritorno.
• Solo il firewall utilizza il percorso errato: controllare policy-based-ipsec-vpn system-generate-traffic. Non confondere traffico client e traffico generato dal sistema.
• Altri tunnel cadono dopo la modifica CLI: il riavvio di tutti i tunnel IPsec è un comportamento documentato. Ripristinare lo stato precedente e verificare ogni tunnel separatamente.
• Il tunnel o la sede centrale non sono disponibili: questo design non prevede un fallback Internet locale automatico. Un fallback richiede un percorso di sicurezza e routing separato e pianificato consapevolmente.
• Un IP pubblico funziona, ma un FQDN no: controllare indirizzo DNS del client, regola DNS, percorso del resolver centrale e risposte. L’opzione del traffico di sistema conta solo se la richiesta è generata dal firewall.

Per il rollback, preparare innanzitutto sopra Branch_LAN_to_WAN_drop una regola LAN-to-WAN temporanea limitata a un solo client di test. Ripristinare quindi Route Precedence al valore registrato e verificare il percorso WAN locale con una nuova sessione di quel client. Se il test non riesce, ripristinare immediatamente la precedenza e lo stato delle regole del full tunnel tramite un accesso amministrativo indipendente. Solo dopo un test riuscito si attivano la precedente regola LAN-to-WAN ordinaria, si disattiva Branch_LAN_to_WAN_drop e si elimina la regola temporanea.

Ripristinare poi l’opzione del traffico di sistema al valore precedente e, poiché l’operazione riavvia i tunnel, verificare tutte le connessioni IPsec. Disattivare o rimuovere Branch_LAN_to_VPN, VPN-to-WAN e MASQ solo quando Rule ID, NAT ID e utilizzo confermano che nessun altro flusso ne dipende. Infine, ripristinare i selettori IPsec originali o rimuovere il tunnel creato esclusivamente per questo percorso. Conservare il backup della configurazione e l’accesso amministrativo indipendente finché le nuove sessioni DNS, HTTPS e applicative non funzionano in entrambe le sedi.

FAQ