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.0.2.0/24. Ogni lato riceve una rete virtuale distinta per il tunnel:

HQ real:            192.0.2.0/24  → visible to branch as 198.51.100.0/24
Branch real:        192.0.2.0/24  → visible to HQ as 203.0.113.0/24

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

Le tre reti provengono dai blocchi IPv4 riservati agli esempi dalla RFC 5737 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

In Hosts and services > IP host > Add, IPsec policy-based richiede tre oggetti di rete 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.0.2.0, HO_LAN_NAT_198.51.100.0 e BO_LAN_NAT_203.0.113.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:

• Activate on save: attivato
• Create firewall rule: attivato
• Local subnet: HO_LAN_NAT_198.51.100.0
• Remote subnet: BO_LAN_NAT_203.0.113.0
• Network address translation (NAT): attivato
• Original subnet: HO_LAN_REAL_192.0.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

Questa assegnazione dei ruoli è particolarmente utile quando la filiale ha un indirizzo IP dinamico e la sede centrale non dispone di un indirizzo affidabile del peer verso cui avviare la connessione: in tal caso, la filiale avvia la connessione verso l’endpoint della sede centrale, raggiungibile in modo stabile. Un indirizzo dinamico non è però un ostacolo assoluto se l’indirizzo del peer può essere risolto in modo affidabile e il progetto consente l’avvio dalla sede centrale. Con l’aggiunta di nuove filiali, l’avvio delle connessioni scala meglio se ogni filiale ritenta la propria connessione, anziché lasciare alla sede centrale il compito di ritentare tutte le connessioni delle filiali.

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

• Activate on save: attivato
• Create firewall rule: attivato
• Local subnet: BO_LAN_NAT_203.0.113.0
• Remote subnet: HO_LAN_NAT_198.51.100.0
• Network address translation (NAT): attivato
• Original subnet: BO_LAN_REAL_192.0.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. Posizionare queste regole VPN sopra qualsiasi regola più ampia in conflitto e, 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.

Stabilire la connessione quando necessario

Controllare lo stato del tunnel solo dopo aver configurato entrambe le sedi e verificato le regole firewall. Activate on save attiva la voce di configurazione, ma non dimostra che il tunnel sia stabilito. Se il tunnel non è ancora stabilito ed è necessario avviarlo manualmente, aprire Site-to-site VPN > IPsec sul lato iniziatore – la filiale in questo esempio – e fare clic sul pulsante di stato nella colonna Connection della connessione interessata.

Non disconnettere né ristabilire una SA di produzione già stabilita per questo passaggio; non è necessario fare clic su quel pulsante nella sede centrale che risponde. Un indicatore di connessione verde conferma che il tunnel è stabilito, non che il percorso dei dati funzioni: eseguire quindi in entrambe le direzioni i controlli di servizio, Child SA e cattura descritti più avanti.

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. È una procedura Sophos distinta e non va combinata con le regole DNAT/SNAT per Any-to-Any.

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 203.0.113.0/24
• Translated source: Original
• Original destination: rete tradotta centrale 198.51.100.0/24
• Translated destination: rete reale centrale 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• 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 198.51.100.0/24 e utilizzare la rete tradotta della filiale 203.0.113.0/24 come Original destination.

NAT nella filiale

Applicare lo stesso principio in modo speculare nella filiale:

• Original source: rete tradotta centrale 198.51.100.0/24
• Translated source: Original
• Original destination: rete tradotta della filiale 203.0.113.0/24
• Translated destination: rete reale della filiale 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• Create reflexive rule: attivato
• Load balancing method: One-to-one

La regola reflexive deve tradurre in uscita la rete reale della filiale in 203.0.113.0/24. Il valore Any per entrambe le interfacce è intenzionale in questo modello documentato; non sostituirlo con WAN solo perché il peer IPsec viene raggiunto tramite WAN. Gli oggetti degli indirizzi tradotti e le regole firewall garantiscono l’ambito ristretto. Una regola SNAT o MASQ più generale posta sopra non deve intercettare prima il traffico.

SFOS confronta una regola NAT con origine, destinazione e servizio originali, prima del NAT, e con le interfacce in entrata e in uscita. NAT viene applicato solo al primo pacchetto di una connessione, quindi ogni test successivo a una modifica NAT deve usare una nuova connessione, con una nuova quintupla. 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.

Abbinare esattamente le regole firewall Any-to-Any

Una regola NAT non autorizza il traffico. In Rules and policies > Firewall rules > Add firewall rule > New firewall rule, creare regole limitate: in sede centrale, l’uscita usa zona LAN, rete reale centrale, zona VPN e rete tradotta della filiale; l’ingresso usa zona VPN, rete tradotta della filiale, zona LAN e rete reale centrale. In filiale invertire le sedi, limitare Services e attivare Log firewall traffic per il collaudo. La differenza segue l’ordine NAT: firewall prima di SNAT in uscita, DNAT prima del firewall in ingresso.

Controllare insieme routing, DNS e applicazioni

Con route-based Any-to-Any, su ciascun lato una route statica, SD-WAN o dinamica configurata manualmente deve condurre alla rete remota tradotta tramite l’interfaccia XFRM corretta o il relativo gateway monitorato. Se esistono più route, si controllano insieme Route Precedence, Administrative Distance e selezione SD-WAN. Con route-based con traffic selectors specifici, invece, viene creata automaticamente una route statica quando il tunnel viene stabilito; si controllano quindi questa route e i selectors corrispondenti. Con IPsec policy-based, SFOS crea una route VPN nel backend quando il tunnel viene stabilito e associa il traffico in base alla policy VPN e alle Local e Remote subnets; una route XFRM dedicata non fa parte di questo metodo. In tutte e tre le varianti, la rete reale identica deve rimanere locale e non deve essere attirata nel tunnel da una route verso la rete remota.

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. Controllare Current activities > IPsec connections e Reports > VPN. In Diagnostics > Packet capture > Configure, un filtro BPF come host 203.0.113.10 limita la cattura al test. 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. Con Any-to-Any, le Rule IDs previste delle regole DNAT e SNAT reflexive attestano la traduzione pianificata degli indirizzi di origine e destinazione. Con IPsec policy-based e route-based con traffic selectors specifici, si confrontano invece i valori salvati di Original subnet, Local subnet e Remote subnet su entrambi i lati, i selectors negoziati e gli indirizzi originali e tradotti effettivi nel flusso di test. Per questo NAT interno alla connessione non è richiesta una NAT Rule ID separata.
4. Packet Capture mostra ingresso, inoltro e percorso di ritorno tramite In interface, Out interface, Rule ID, Status e Reason. Gli indirizzi di origine e destinazione prima e dopo la traduzione vengono confrontati con il piano di indirizzamento; il filtro deve includere gli indirizzi originali o tradotti verificati nel singolo test. Con route-based si controlla l’interfaccia XFRM corrispondente; con policy-based si controlla il percorso IPsec tramite l’interfaccia IPsec condivisa, non un’interfaccia XFRM dedicata. Con Any-to-Any, NAT ID serve inoltre ad associare il traffico alla regola NAT separata e non costituisce una prova obbligatoria per il NAT interno alla connessione.
5. Il server di destinazione vede l’indirizzo sorgente pianificato e risponde sullo stesso percorso.

Come controllo negativo, si contatta quindi l’indirizzo reale identico 192.0.2.10: deve rimanere locale e non deve attraversare la VPN in nessuna delle tre varianti. Aggiungere altri host, servizi e nomi DNS solo dopo l’esito previsto dei test positivo e negativo in entrambe le direzioni. 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. Con Any-to-Any, si confrontano Original source e Translated source, oltre all’indirizzo di destinazione remoto invariato nella regola SNAT reflexive; con IPsec policy-based e route-based con traffic selectors specifici, si confrontano le associazioni di Original subnet, Local subnet e Remote subnet, oltre ai selectors negoziati della connessione. Si controllano inoltre il gateway del server e le regole firewall nella direzione inversa. Una traduzione unilaterale non può produrre un flusso bidirezionale stabile.

Corrisponde la regola NAT errata

Con Any-to-Any, si controllano NAT Rule ID e ordine delle regole DNAT/SNAT separate. Una regola MASQ ampia, Default-SNAT o DNAT precedente può corrispondere prima della regola VPN specifica. Non si disattivano tutte le regole NAT per tentativi; si correla prima il singolo flusso di test per timestamp e si corregge poi solo la regola in conflitto. Con IPsec policy-based e route-based con traffic selectors specifici, una traduzione errata viene invece circoscritta in base ai campi NAT della connessione IPsec, ai selectors negoziati e agli indirizzi effettivi prima e dopo NAT; l’assenza di una NAT Rule ID separata non costituisce un errore in questi casi.

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. Annotare anche nomi, ID, ordine e stato di attivazione di tutte le regole e route interessate, insieme ai valori DNS e applicativi precedenti. Durante la migrazione disattivare le vecchie regole solo dopo averne documentato l’esatto stato precedente.

Se il collaudo non riesce, ripristinare prima i valori DNS e applicativi annotati. Per Any-to-Any disattivare solo le nuove regole firewall, la coppia DNAT/SNAT reflexive e la route della rete tradotta; per policy-based ripristinare i campi Local, Remote e Original subnet salvati. Ripristinare quindi ordine e stato di attivazione precedenti di regole e route e testare nuove connessioni in entrambe le direzioni. Le sessioni esistenti conservano l’associazione NAT stabilita dal primo pacchetto e non provano il rollback: lasciare proseguire le sessioni non correlate e, se serve una prova immediata, terminare solo le sessioni di test interessate prima di ripetere il test. Non cancellare tutte le connessioni. Rimuovere indirizzi XFRM e oggetti solo quando Object usage non mostra dipendenze. 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