Usare NAT per reti IPsec sovrapposte su Sophos Firewall

Se sede centrale e filiale utilizzano la stessa subnet reale, nessun firewall può decidere dalla sola destinazione se un pacchetto debba rimanere locale o attraversare il tunnel IPsec. Il tunnel può essere verde senza che esista un percorso univoco. La soluzione è un piano di traduzione coordinato su entrambi i lati: ogni sede appare al peer mediante una rete tradotta univoca.

Il tipo di tunnel determina il metodo. IPsec policy-based e IPsec route-based con traffic selectors specifici utilizzano le impostazioni NAT direttamente nella connessione IPsec. Route-based Any-to-Any usa invece regole DNAT e SNAT e una route verso la rete remota tradotta. Configurare una VPN IPsec Site-to-Site spiega la scelta generale del tipo di tunnel.

Scegliere il metodo corretto

Sophos supporta la traduzione 1:1, 1:n o n:n per IPsec policy-based. Con n:n, rete originale e tradotta devono avere la stessa dimensione. Un /24, ad esempio, va associato a un altro /24, non a un /25.

Per scegliere bastano tre domande:

• Nella connessione IPsec sono inserite Local e Remote subnets specifiche? Utilizzare Network address translation (NAT) nella connessione.
• Entrambe le subnet sono impostate su Any in un tunnel route-based? Utilizzare DNAT con una regola SNAT reflexive e una route tramite XFRM.
• Le reti non sono sovrapposte? NAT è normalmente inutile e rende più complessi log, regole e troubleshooting.

⚠️ Non mescolare i due metodi. Prima della modifica salvare entrambe le configurazioni del tunnel, le regole NAT e firewall, le route, le risposte DNS e un accesso amministrativo indipendente. Una regola MASQ ampia o un indirizzo tradotto improvvisato non sono workaround sicuri.

Creare un piano di indirizzamento per entrambe le sedi

Nell’esempio, sede centrale e filiale utilizzano entrambe la rete reale 192.168.2.0/24. Ogni lato riceve una rete virtuale distinta per il tunnel:

HQ real:            192.168.2.0/24  → visible to branch as 192.168.1.0/24
Branch real:        192.168.2.0/24  → visible to HQ as 192.168.3.0/24

Un client della sede centrale contatta quindi un server della filiale tramite il suo indirizzo in 192.168.3.0/24. Un client della filiale utilizza l’indirizzo corrispondente in 192.168.1.0/24 per un server centrale. L’indirizzo reale 192.168.2.x rimane locale in ciascuna sede.

Le tre reti sono valori di documentazione e devono essere sostituite insieme con reti libere del piano reale. Le reti tradotte devono essere univoche, non sovrapporsi ad alcuna rete LAN, VLAN, VPN, cloud o domestica ed essere documentate in modo speculare su entrambi i firewall. Se le applicazioni usano nomi, il DNS di ciascuna sede deve restituire l’indirizzo tradotto del sistema remoto.

Configurare IPsec policy-based con NAT

IPsec policy-based richiede tre oggetti IP host su ogni firewall: la rete locale reale, la propria rete tradotta e quella tradotta del peer. Nell’esempio della sede centrale sono HO_LAN_REAL_192.168.2.0, HO_LAN_NAT_192.168.1.0 e BO_LAN_NAT_192.168.3.0.

Configurare la sede centrale

In Site-to-site VPN > IPsec > Add, creare la connessione come Policy-based con Gateway type Respond only. Profilo, autenticazione, interfaccia WAN e indirizzo del peer devono corrispondere al lato remoto. Utilizzare queste assegnazioni:

• Local subnet: HO_LAN_NAT_192.168.1.0
• Remote subnet: BO_LAN_NAT_192.168.3.0
• Network address translation (NAT): attivato
• Original subnet: HO_LAN_REAL_192.168.2.0

Il firewall traduce la propria rete locale reale nella rete tradotta prima dell’invio. Il traffico in entrata verso la rete tradotta viene ricondotto alla rete reale.

Configurare la filiale in modo speculare

In filiale, creare la connessione Policy-based con Gateway type Initiate the connection. L’assegnazione viene completamente invertita:

• Local subnet: BO_LAN_NAT_192.168.3.0
• Remote subnet: HO_LAN_NAT_192.168.1.0
• Network address translation (NAT): attivato
• Original subnet: BO_LAN_REAL_192.168.2.0

Local e Remote subnet contengono quindi le reti tradotte, mentre Original subnet contiene la rete locale reale. Se dimensione o direzione non coincidono, può formarsi Phase 2, ma il traffico viene tradotto in modo errato o non trova un ritorno.

Controllare le regole firewall automatiche

Con Create firewall rule, SFOS crea regole VPN in entrata e uscita. Controllarle in Rules and policies > Firewall rules, nel gruppo Automatic VPN rules. Devono consentire le reti tradotte nella direzione corretta e solo i servizi realmente necessari. È possibile adattare una regola VPN generale esistente; non è obbligatoria una regola ampia separata per ogni tunnel.

Le regole vengono valutate dall’alto verso il basso. Durante un test reale controllare Rule ID, zone di origine e destinazione, reti di origine e destinazione, servizi e logging. Creare regole firewall su Sophos Firewall spiega la logica generale.

Configurare route-based Any-to-Any con DNAT e SNAT

Questo metodo richiede un tunnel route-based Any-to-Any funzionante. L’interfaccia XFRM ha un indirizzo di transito univoco, esistono le regole LAN-to-VPN e VPN-to-LAN appropriate e una route statica, SD-WAN o dinamica conduce alla rete tradotta del peer. Solo allora si aggiunge NAT.

Le connessioni route-based con traffic selectors specifici non utilizzano questa procedura. Come IPsec policy-based, usano le impostazioni NAT della connessione IPsec. Se il loro traffico corrisponde invece a una regola MASQ, SFOS può scartarlo perché a queste interfacce XFRM non è assegnato un indirizzo IP.

NAT nella sede centrale

Creare una regola DNAT in Rules and policies > NAT rules > Add NAT rule > New NAT rule. Traduce i pacchetti in entrata destinati alla rete virtuale centrale verso la rete locale reale:

• Original source: rete tradotta della filiale 192.168.3.0/24
• Translated source: Original
• Original destination: rete tradotta centrale 192.168.1.0/24
• Translated destination: rete reale centrale 192.168.2.0/24
• Create reflexive rule: attivato
• Load balancing method: One-to-one

Per l’associazione usare oggetti di rete o IP range della stessa dimensione. Dopo il salvataggio aprire la regola generata Reflexive_NAT#_<DNAT_rule_name>. In uscita deve tradurre la rete reale centrale in 192.168.1.0/24 e utilizzare la rete tradotta della filiale 192.168.3.0/24 come Original destination.

NAT nella filiale

Applicare lo stesso principio in modo speculare nella filiale:

• Original source: rete tradotta centrale 192.168.1.0/24
• Translated source: Original
• Original destination: rete tradotta della filiale 192.168.3.0/24
• Translated destination: rete reale della filiale 192.168.2.0/24
• Create reflexive rule: attivato
• Load balancing method: One-to-one

La regola reflexive deve tradurre in uscita la rete reale della filiale in 192.168.3.0/24. Una regola SNAT o MASQ più generale posta sopra non deve intercettare prima il traffico. Dimostrare ordine e corrispondenza con NAT Rule ID e Packet Capture invece di dedurli solo dall’elenco. Comprendere NAT su Sophos Firewall spiega le regole reflexive e il principio first-match.

Controllare insieme routing, DNS e applicazioni

Su ogni lato, la route verso la rete remota tradotta deve usare l’interfaccia XFRM corretta o il relativo gateway monitorato. Una route verso la rete reale identica sarebbe ambigua e potrebbe attirare traffico locale nel tunnel. Se esistono più route, controllare insieme Route Precedence, Administrative Distance e selezione SD-WAN.

Anche l’applicazione deve utilizzare la destinazione tradotta. Configurazioni statiche, ACL, risposte DNS, monitoring e log dei server non devono continuare ad attendersi l’indirizzo remoto reale. Un test NAT basato solo su ping non dimostra quindi il funzionamento del processo aziendale.

Convalidare il flusso in entrambe le direzioni

Iniziare con un host noto e un servizio TCP o UDP reale su ciascun lato. Dalla sede centrale accedere all’indirizzo tradotto della filiale, quindi dalla filiale testare l’indirizzo tradotto della sede centrale. Per lo stesso timestamp verificare:

1. La connessione IPsec e la Child SA sono attive.
2. La Firewall Rule ID prevista consente il flusso.
3. La NAT Rule ID prevista traduce correttamente indirizzi originali e destinazione.
4. Packet Capture mostra ingresso, traduzione, uscita XFRM e ritorno.
5. Il server di destinazione vede l’indirizzo sorgente pianificato e risponde sullo stesso percorso.

Solo dopo che entrambe le direzioni funzionano si aggiungono altri host, servizi e nomi DNS. Packet Capture su Sophos Firewall aiuta a confrontare prima e dopo NAT; Troubleshooting IPsec su Sophos Firewall descrive il controllo completo del tunnel.

Circoscrivere gli errori in base al sintomo

Il tunnel è verde, ma la destinazione risponde localmente

Probabilmente il client usa l’indirizzo reale, presente anche localmente, invece della rete remota tradotta. Controllare risposta DNS, file hosts, configurazione dell’applicazione e route di destinazione. L’errore si verifica quindi prima del tunnel.

L’andata funziona, ma manca il ritorno

Le traduzioni devono essere speculari sui due firewall. Confrontare Original e Translated source nella regola reflexive, Remote subnet nella connessione IPsec, gateway del server e regole nella direzione inversa. Una traduzione unilaterale non può produrre un flusso bidirezionale stabile.

Corrisponde la regola NAT errata

Controllare NAT Rule ID e ordine. Una regola MASQ ampia, Default-SNAT o DNAT precedente può corrispondere prima della regola VPN specifica. Non disattivare tutte le regole NAT per tentativi; correlare prima il singolo flusso di test per timestamp e correggere solo la regola in conflitto.

Alcuni host funzionano e altri no

Con n:n, gli intervalli originale e tradotto devono avere uguale dimensione e posizione. Controllare oggetti IP range, maschere, indirizzi esclusi, firewall dell’host e offset realmente utilizzato. Il successo per .10 non dimostra l’associazione dell’intero intervallo.

Rollback e funzionamento

Prima della modifica preparare un backup della configurazione, screenshot o esportazioni delle configurazioni di tunnel, NAT, firewall e routing e un accesso di gestione indipendente. Durante la migrazione disattivare vecchie regole solo se è documentato un rollback univoco.

Se la convalida non riesce, disattivare le nuove regole NAT e route, ripristinare la configurazione precedente del tunnel e riprovare il traffico locale originale. Rimuovere le reti tradotte da DNS, monitoring e documentazione solo quando non rimane alcuna dipendenza.

Durante il funzionamento, gestire le reti tradotte nel piano IP centrale. Controllare nuove sedi, reti cloud, pool di Remote Access e reti domestiche rispetto alle reti originali e tradotte. In caso contrario, la sovrapposizione viene solo spostata altrove.

Domande frequenti