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 a IPsec policy-based. Per design nuovi o in crescita, route-based Any-to-Any con XFRM e routing esplicito è spesso più flessibile. 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.

Impostazione	Sede centrale	Filiale
Local subnet	`Any`	`10.20.0.0/24`
Remote subnet	`10.20.0.0/24`	`Any`
Gateway type	`Respond only`	`Initiate the connection`

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.

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 percorso di ritorno documentato e una finestra di manutenzione.

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. Senza percorso di ritorno e NAT corretti, il tunnel può essere verde ma le connessioni Internet non ricevono risposta.

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
Log firewall traffic: attivato

Segue una regola mirata Branch_LAN_to_WAN_drop per la stessa rete della filiale da LAN a WAN. Impedisce che una regola Internet locale troppo ampia aggiri il percorso pianificato nel tunnel. Non includere accidentalmente altre reti o servizi locali esplicitamente necessari.

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.

Il valore predefinito è enable. Poiché un sistema esistente può avere un valore diverso, si mostra prima lo stato attuale con questo comando di sola lettura della Device Console:

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:

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

⚠️ 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.

Durante il rollback ripristinare lo stato precedente documentato. Se l’opzione era attiva, utilizzare:

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

Dopo ogni modifica, verificare nuovamente tutte le connessioni IPsec e i servizi necessari del firewall.

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:

Nella filiale corrisponde Branch_LAN_to_VPN; la regola locale di drop LAN-to-WAN non corrisponde a questo flusso riuscito.
Nella sede centrale corrispondono Branch_VPN_to_WAN e la regola MASQ collegata.
L’indirizzo IP sorgente visibile pubblicamente appartiene alla sede centrale.
DNS, HTTPS e una destinazione volutamente bloccata si comportano secondo la policy centrale.
Packet Capture mostra pacchetti di andata e ritorno nel tunnel e sulla WAN centrale.
Il traffico generato dal sistema utilizza il percorso locale o centrale scelto in precedenza.

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: il design standard non offre breakout Internet locale. Un fallback richiede un percorso di sicurezza e routing separato e pianificato consapevolmente.

Per il rollback, disattivare prima Branch_LAN_to_WAN_drop e ripristinare in modo controllato il percorso Internet locale precedentemente consentito. Rimuovere poi le regole VPN-to-WAN e MASQ solo se nessun altro flusso le utilizza. Ripristinare Route Precedence e l’opzione del traffico di sistema esattamente ai valori precedenti documentati, quindi ripetere i test in entrambe le sedi.

FAQ

Anche il traffico generato dal firewall della filiale deve passare dalla sede centrale?

No. È una decisione di design separata. L’opzione CLI può disattivare le route VPN policy-based per questo traffico, ma così facendo riavvia tutti i tunnel IPsec.

Questo design offre automaticamente un failover Internet locale nella filiale?

No. La regola di drop LAN-to-WAN blocca intenzionalmente il percorso locale. Un fallback richiede criteri, regole, policy di sicurezza e test controllati separati.