Configurare NAT64 su Sophos Firewall con Direct Web Proxy

Un client solo IPv6 può accedere tramite il Direct Web Proxy di Sophos Firewall a un sito web che dispone soltanto di un indirizzo IPv4. SFOS risolve il nome di destinazione nel proxy e stabilisce la connessione successiva tramite IPv4. Servono due regole firewall: una regola IPv6 dal client al proxy e una regola IPv4 dal proxy alla destinazione.

Non si tratta di un NAT64 layer 3 generale per protocolli qualsiasi. Funziona soltanto per le connessioni HTTP e HTTPS che browser o applicazioni inviano esplicitamente al web proxy. In questa procedura non viene creata una normale regola NAT64 in Rules and policies > NAT rules.

La classificazione completa è disponibile in Supporto IPv6 e limiti in Sophos Firewall con SFOS 22. SFOS supporta questo percorso NAT64 basato sul proxy, ma indica DNS64 come non supportato; ciò non crea una transizione generale per altri protocolli.

⚠️ Le due regole hanno compiti diversi. Per gli endpoint solo IPv6, la Web Policy e l’associazione degli utenti appartengono alla regola IPv6. Application Control, IPS e le altre funzioni di protezione della connessione IPv4 in uscita appartengono alla regola IPv4. Un’unica regola ampia non rende visibile questa separazione in modo affidabile.

NAT64 tramite proxy in otto passaggi

Scegliere un client pilota solo IPv6 gestito e una destinazione web A-only controllata.
Verificare indirizzo IPv6, DNS, FQDN del proxy e listener TCP del Direct Web Proxy.
Preparare la configurazione di base di Direct Web Proxy, Device Access e del file PAC o della policy del browser.
Nella vista IPv6 creare una regola con logging dalla rete pilota alla porta proxy con zona di destinazione WAN.
Impostare la Web Policy e, se necessario, Match known users in questa regola IPv6.
Nella vista IPv4 creare una seconda regola con logging dal proxy alla destinazione IPv4 con HTTP/HTTPS.
Eseguire il test con una destinazione priva di record AAAA e controllare entrambi i Firewall Rule IDs e la decisione del filtro web.
Aggiungere altri client soltanto dopo test positivi e negativi; verificare separatamente rollback, HA e SD-WAN.

Perché servono due regole firewall

Il percorso dei dati cambia versione IP nel proxy:

Il client si collega tramite IPv6 al listener proxy del firewall.
La regola IPv6 valuta client, utente, nome della destinazione, porta proxy e Web Policy.
Il proxy risolve il nome host richiesto.
Se la destinazione ha soltanto un record A, il proxy crea una nuova connessione IPv4.
La regola IPv4 valuta questo secondo segmento e applica, ad esempio, Application Control o IPS.

La seconda connessione non è più il pacchetto IPv6 originale del client. La regola IPv4 non deve quindi essere progettata come se l’indirizzo IPv6 del client dovesse comparire come sorgente. Allo stesso tempo, una regola IPv6 riuscita da sola non dimostra ancora che il proxy raggiunga realmente la destinazione IPv4.

Sophos definisce questa struttura uno scenario NAT64. Diversamente da un gateway NAT64 classico, non viene però instradato un prefisso IPv6 verso destinazioni IPv4 qualsiasi. Questa procedura non traduce applicazioni prive di supporto per proxy esplicito, UDP, ICMP o altro traffico non proxy.

Configurare Direct Web Proxy con un file PAC spiega la configurazione generale di listener, PAC, Device Access e rollback. Questo articolo presuppone un percorso proxy di base funzionante e aggiunge soltanto la transizione da IPv6 a IPv4.

Esempio e valori da sostituire

La procedura utilizza un piccolo progetto pilota:

Client solo IPv6: CLIENT6-PROXY-01
Rete pilota: 2001:db8:20:30::/64
Indirizzo IPv6 del firewall nella rete client: 2001:db8:20:30::1
FQDN del proxy: fw01.corp.example
Porta proxy: TCP 3128
Destinazione A-only controllata: v4-test.corp.example
Indirizzo di destinazione di documentazione: 192.0.2.80
Regola IPv6: LAN6_DirectProxy_to_IPv4
Regola IPv4: Proxy_IPv4_Egress_Pilot
Web Policy: Web_Standard_IPv6_Pilot

2001:db8::/32, 192.0.2.0/24 e .example sono intervalli di documentazione. Non funzionano come indirizzi di produzione e devono essere sostituiti con il prefisso IPv6 dell’organizzazione, l’indirizzo effettivo del firewall e un nome DNS controllato. Il client pilota deve utilizzare davvero soltanto IPv6; un percorso IPv4 attivo in parallelo invaliderebbe il test.

La destinazione di test deve avere un record A, ma nessun record AAAA. A questo scopo è preferibile un piccolo web server interno o un virtual host di test controllato. Un sito web pubblico casuale non è adatto, perché il gestore potrebbe attivare IPv6 o modificare le risposte DNS in qualsiasi momento.

Configurare IPv6 Prefix Delegation spiega come interagiscono prefisso WAN, Router Advertisement e DHCPv6. NAT64 non corregge l’assenza di indirizzamento IPv6 nella rete client.

Verificare i prerequisiti

Prima di creare le regole devono funzionare quattro elementi distinti:

Il client dispone di un indirizzo IPv6 valido, una route predefinita e DNS funzionante.
fw01.corp.example restituisce nella rete client la risposta AAAA prevista per il firewall.
Direct Web Proxy è in ascolto sulla porta documentata in Web > General settings > Web proxy configuration, 3128 in questo esempio.
Il firewall dispone di un percorso WAN IPv4 funzionante verso la destinazione.

In Administration > Device access, Web proxy deve essere raggiungibile per la sorgente client concreta e l’indirizzo del firewall previsto. Per un progetto pilota non serve un’autorizzazione ampia per l’intera zona LAN o Wi-Fi. Il limite del proxy resta importante: un client autorizzato può raggiungere tramite questo percorso i servizi HTTP/HTTPS locali del firewall. Le destinazioni di gestione vengono quindi verificate esplicitamente con test negativi, come descritto nell’articolo di base.

Il client riceve FQDN e porta del proxy tramite una policy del browser gestita, un’impostazione del sistema operativo o un file PAC. Il FQDN deve essere raggiungibile tramite IPv6 dal client solo IPv6. Un client solo IPv6 non può utilizzare come primo hop un indirizzo proxy che dispone soltanto di un record A.

Documentare regole firewall, Web Policies, autenticazione, TLS Inspection e SD-WAN Routes esistenti. Posizionare le due regole pilota abbastanza in alto da essere valutate prima di una regola generale corrispondente, senza ignorare in modo incontrollato le regole di protezione esistenti.

Creare la regola IPv6 verso il proxy

In Rules and policies > Firewall rules, selezionare prima IPv6 e creare una regola mediante Add firewall rule > New firewall rule:

Rule name: LAN6_DirectProxy_to_IPv4
Action: Accept
Log firewall traffic: attivo
Source zones: LAN
Source networks and devices: rete pilota IPv6 o singolo client pilota
Destination zones: WAN
Destination networks: destinazione FQDN controllata oppure, per il successivo rollout, l’insieme di destinazioni pianificato consapevolmente
Services: servizio TCP personalizzato per 3128
Match known users: soltanto con un’autenticazione già funzionante e gli utenti o gruppi previsti
Web filtering > Web policy: Web_Standard_IPv6_Pilot

La zona di destinazione WAN sembra inizialmente insolita, perché tecnicamente il client si collega a un indirizzo del firewall. Sophos richiede tuttavia WAN o Any per inoltrare il traffico al componente proxy. Secondo il produttore, ciò vale anche quando il web server finale si trova in LAN o DMZ. La zona di destinazione non deve quindi essere modificata per supposizione nella zona fisica del server.

Sophos consente anche Any in Services. La porta concreta del listener è più comprensibile per un progetto pilota ed evita un’autorizzazione inutilmente ampia. Se cambia Web proxy listening port, servizio, impostazione PAC/browser, Device Access e test devono utilizzare lo stesso valore.

Per gli endpoint solo IPv6, configurare utenti e gruppi in questa regola IPv6. Anche la Web Policy si applica qui. La guida sulle regole firewall spiega ordine, logging e associazione degli utenti; categorie e azioni vengono pianificate nelle Web Protection Policies.

Creare la regola IPv4 dal proxy alla destinazione

Passare quindi a IPv4 in Rules and policies > Firewall rules e creare la seconda regola:

Rule name: Proxy_IPv4_Egress_Pilot
Action: Accept
Log firewall traffic: attivo
Source zones: Any
Source networks and devices: Any
Destination zones: WAN
Destination networks: inizialmente la destinazione A-only controllata, successivamente soltanto l’insieme di destinazioni realmente necessario
Services: HTTP e HTTPS, oppure le porte di destinazione realmente necessarie
Match known users: per questa procedura solo IPv6 non utilizzarlo come sostituto dell’associazione utenti nella regola IPv6
Other security features: policy previste di Application Control, IPS e, se necessario, Traffic Shaping

L’esempio ufficiale Sophos utilizza Any per zona e rete di origine, perché il proxy crea la connessione IPv4. Questi valori non devono essere sostituiti erroneamente dalla rete client IPv6. La regola pilota viene invece limitata mediante destinazione e servizi e verificata tramite la sua Rule ID.

La Web Policy non viene spostata in questa regola IPv4. Appartiene al primo segmento del proxy, legato all’utente. Application Control e IPS proteggono invece il segmento tra proxy e destinazione IPv4. Una policy di Traffic Shaping nella regola IPv4 si applica a questo egress; Sophos documenta inoltre che Traffic Shaping non si applica alla connessione diretta tra client e proxy.

Non creare una regola NAT64 aggiuntiva. Il normale percorso WAN IPv4 del firewall deve comunque funzionare. Se una regola IPv4 esistente copre già questo egress del proxy in modo controllato, può continuare a essere utilizzata dopo averne verificato Rule ID e policy; una seconda regola Any parallela sarebbe peggiore di una regola esistente documentata consapevolmente.

Testare il vero percorso da IPv6 a IPv4

Controllo preliminare di DNS e listener

Su un client pilota Windows sono utili i seguenti controlli in sola lettura:

Resolve-DnsName fw01.corp.example -Type AAAA
Resolve-DnsName v4-test.corp.example -Type A
Resolve-DnsName v4-test.corp.example -Type AAAA
Test-NetConnection fw01.corp.example -Port 3128

Il FQDN del proxy deve restituire l’indirizzo IPv6 previsto. La destinazione di test deve avere un record A; dal test AAAA non è atteso alcun indirizzo di destinazione. Test-NetConnection conferma soltanto il listener TCP, non la Web Policy, la risoluzione DNS nel proxy o l’egress IPv4.

Verificare entrambe le regole e i livelli di protezione

Aprire una nuova sessione privata del browser sul client pilota solo IPv6.
Controllare il proxy effettivo o il file PAC caricato.
Aprire la destinazione A-only consentita.
Aprire una destinazione bloccata intenzionalmente da Web_Standard_IPv6_Pilot.
In Log viewer, verificare regola IPv6, sorgente, utente, Web Policy, azione e Firewall Rule ID.
Per la connessione successiva, verificare regola IPv4, destinazione IPv4, servizio, Application Control/IPS e secondo Firewall Rule ID.
Ripetere la richiesta alla destinazione senza proxy come test negativo; il client solo IPv6 non deve raggiungere direttamente tramite IPv4 la destinazione A-only.
Testare un’applicazione senza supporto proxy e confermare che non venga erroneamente considerata compatibile con NAT64.

Il successo è dimostrato soltanto quando il nome di destinazione è realmente A-only, il client raggiunge il proxy tramite IPv6, entrambe le regole previste corrispondono e i test web consentito e bloccato mostrano le azioni pianificate. Testare sistematicamente le regole firewall spiega come correlare Rule ID, Log Viewer, Policy Tester e Packet Capture.

Circoscrivere gli errori sistematicamente

La porta proxy non è raggiungibile tramite IPv6

Controllare risposta AAAA del FQDN del proxy, indirizzo client, route predefinita, Neighbor Discovery, interfaccia del firewall e Web proxy in Device Access. Un test IPv4 riuscito da un altro client non dimostra nulla sul percorso del listener IPv6.

La regola IPv6 corrisponde, ma la destinazione non si carica

Confermare innanzitutto che il proxy risolva il nome di destinazione in un record A e che il firewall stesso disponga di un percorso WAN IPv4 funzionante. Controllare poi regola IPv4, destinazione, servizio, ordine e Rule ID. La regola IPv6 è soltanto la prima metà.

Funzionano soltanto i siti web dual-stack

Il percorso NAT64 non è ancora dimostrato. Controllare se la destinazione di test dispone di un record AAAA. Utilizzare una destinazione A-only dedicata per l’accettazione ed escludere un percorso IPv4 attivo sul client.

Web Policy o utente non sono corretti

Controllare l’assegnazione nella regola IPv6. SFOS valuta Match known users in entrambe le regole per gli endpoint solo IPv6, ma Sophos assegna esplicitamente queste impostazioni alla regola IPv6. L’associazione utente nella regola IPv4 non deve sostituire il contesto utente mancante nel primo segmento.

Application Control o IPS non si applica

Controllare queste funzioni nella regola IPv4, non soltanto nella regola IPv6. Confermare poi tramite la Rule ID IPv4 che questa regola elabori realmente l’egress del proxy. Una decisione corretta del filtro web non dimostra Application Control o IPS.

Le destinazioni interne o locali si comportano in modo inatteso

Anche quando la destinazione finale si trova in LAN o DMZ, la regola IPv6 richiede WAN o Any per inoltrare il traffico al proxy. La zona di destinazione reale viene rappresentata nella regola IPv4. Controllare inoltre l’esposizione dei servizi di gestione locali dovuta all’accesso proxy e le risposte DNS interne.

SD-WAN, HA e rollback

Una SD-WAN Route con i servizi HTTP e HTTPS non corrisponde alla connessione del client alla porta proxy 3128. Per il primo segmento si deve utilizzare la porta effettiva del listener oppure, consapevolmente, Any. L’egress del proxy necessita inoltre di un gateway WAN funzionante o di un percorso di ritorno statico. Configurare e testare le SD-WAN Routes spiega questi casi particolari.

In HA non bisogna promettere la continuazione senza interruzioni di una connessione proxy esistente. Dopo un failover controllato, aprire una nuova sessione del browser e ricontrollare record AAAA del proxy, Rule ID IPv6, Web Policy, Rule ID IPv4 e accesso alla destinazione. Per la ricerca nei log conta il nodo che ha elaborato il traffico interessato.

Per il rollback:

Disattivare le regole pilota o ripristinare lo stato precedente documentato.
Rimuovere l’eccezione Device Access dedicata al pilota, se creata soltanto per questo test.
Rimuovere dal pilota l’impostazione PAC, GPO o proxy del browser.
Ripristinare l’ordine precedente delle regole IPv4/IPv6 e la configurazione SD-WAN.
Ricontrollare accesso IPv6 diretto, traffico proxy esistente e servizi di gestione locali.

Non eliminare le due regole prima di aver documentato il percorso precedente e di disporre di una sessione amministratore aperta o di un accesso di gestione alternativo.

Checklist per l’approvazione

Il client è dimostrabilmente solo IPv6.
Il FQDN del proxy restituisce l’indirizzo AAAA previsto.
La destinazione di test dispone di un record A, ma di nessun record AAAA.
Direct Web Proxy e Device Access sono limitati al pilota.
La regola IPv6 utilizza zona di destinazione WAN, porta effettiva del listener, logging e Web Policy.
L’associazione utenti, se necessaria, ha superato test positivi e negativi nella regola IPv6.
La regola IPv4 elabora l’egress del proxy con le porte di destinazione e le funzioni di protezione pianificate.
Entrambi i Firewall Rule IDs ed entrambe le versioni IP sono dimostrati nel test.
Esposizione dei servizi di gestione, traffico non proxy, SD-WAN e HA sono delimitati consapevolmente.
Rollback, responsabile e data di revisione sono documentati.

Domande frequenti

NAT64 su Sophos Firewall richiede una normale regola NAT?

Non per questa procedura documentata del web proxy. SFOS fornisce l’accesso da IPv6 a IPv4 all’interno del percorso del proxy esplicito. Servono una regola firewall IPv6 e una IPv4, ma nessuna regola NAT64 generale in Rules and policies > NAT rules.

Questa configurazione NAT64 funziona per ogni applicazione?

No. Si applica a HTTP/HTTPS di client e applicazioni che utilizzano esplicitamente Direct Web Proxy. Traffico non proxy, UDP, ICMP o applicazioni senza supporto proxy richiedono un’altra transizione IPv6/IPv4 oppure connettività nativa.

Perché una sola regola firewall non è sufficiente?

Il proxy termina la connessione IPv6 del client e crea poi una nuova connessione IPv4 verso la destinazione A-only. Web Policy e associazione utenti vengono valutate nel segmento IPv6; Application Control e IPS per l’egress nel segmento IPv4. Entrambi i percorsi devono essere consentiti, registrati e testati separatamente.