NAT64 auf Sophos Firewall mit Direct Web Proxy einrichten

Ein IPv6-only-Client kann über den Direct Web Proxy der Sophos Firewall auf eine Website zugreifen, die nur eine IPv4-Adresse besitzt. SFOS löst den Zielnamen im Proxy auf und baut die nachgelagerte Verbindung über IPv4 auf. Dafür werden zwei Firewallregeln benötigt: eine IPv6-Regel vom Client zum Proxy und eine IPv4-Regel vom Proxy zum Ziel.

Das ist kein allgemeines Layer-3-NAT64 für beliebige Protokolle. Es funktioniert nur für HTTP- und HTTPS-Verbindungen, welche Browser oder Anwendungen ausdrücklich an den Webproxy senden. Eine normale NAT64-Regel unter Rules and policies > NAT rules wird in diesem Ablauf nicht angelegt.

Die vollständige Einordnung steht unter Sophos Firewall IPv6 Support und Grenzen in SFOS 22. SFOS unterstützt diesen proxybasierten NAT64-Pfad, führt DNS64 aber als nicht unterstützt; daraus entsteht kein allgemeiner Übergang für andere Protokolle.

⚠️ Die beiden Regeln haben unterschiedliche Aufgaben. Web Policy und Benutzerbezug gehören bei IPv6-only-Endpoints in die IPv6-Regel. Application Control, IPS und weitere Schutzfunktionen für die ausgehende IPv4-Verbindung gehören in die IPv4-Regel. Eine einzelne breite Regel macht diese Trennung nicht zuverlässig sichtbar.

NAT64 über den Proxy in acht Schritten

1. Einen verwalteten IPv6-only-Pilotclient und ein kontrolliertes A-only-Webziel festlegen.
2. IPv6-Adresse, DNS, Proxy-FQDN und TCP-Listener des Direct Web Proxy prüfen.
3. Den Basisaufbau für Direct Web Proxy, Device Access und PAC beziehungsweise Browserrichtlinie vorbereiten.
4. In der IPv6-Ansicht eine geloggte Regel vom Pilotnetz zum Proxyport mit Zielzone WAN erstellen.
5. Web Policy und gegebenenfalls Match known users in dieser IPv6-Regel setzen.
6. In der IPv4-Ansicht eine zweite geloggte Regel vom Proxy zum IPv4-Ziel mit HTTP/HTTPS erstellen.
7. Mit einem Ziel ohne AAAA-Record testen und beide Firewall Rule IDs sowie die Web-Filter-Entscheidung prüfen.
8. Erst nach positivem und negativem Test weitere Clients aufnehmen; Rollback, HA und SD-WAN separat abnehmen.

Warum zwei Firewallregeln nötig sind

Der Datenpfad wechselt am Proxy die IP-Version:

1. Der Client verbindet sich über IPv6 mit dem Proxylistener der Firewall.
2. Die IPv6-Regel bewertet Client, Benutzer, Zielname, Proxyport und Web Policy.
3. Der Proxy löst den angeforderten Hostnamen auf.
4. Besitzt das Ziel nur einen A-Record, erzeugt der Proxy eine neue IPv4-Verbindung.
5. Die IPv4-Regel bewertet diesen zweiten Abschnitt und wendet dort beispielsweise Application Control oder IPS an.

Die zweite Verbindung ist nicht mehr das ursprüngliche IPv6-Paket des Clients. Deshalb darf die IPv4-Regel nicht so entworfen werden, als müsse dort die IPv6-Clientadresse als Source erscheinen. Gleichzeitig beweist eine grüne IPv6-Regel allein noch nicht, dass der Proxy das IPv4-Ziel wirklich erreicht.

Sophos bezeichnet diesen Aufbau als NAT64-Szenario. Anders als bei einem klassischen NAT64-Gateway wird aber kein IPv6-Präfix für beliebige IPv4-Ziele geroutet. Anwendungen ohne explizite Proxyunterstützung, UDP, ICMP und anderer Non-Proxy-Traffic werden durch diesen Ablauf nicht übersetzt.

Die allgemeine Listener-, PAC-, Device-Access- und Rollback-Konfiguration erklärt Direct Web Proxy mit PAC-Datei einrichten. Dieser Artikel setzt den funktionierenden Proxy-Grundpfad voraus und ergänzt nur den IPv6-zu-IPv4-Übergang.

Beispiel und austauschbare Werte

Der Ablauf verwendet einen kleinen Pilot:

• IPv6-only-Client: CLIENT6-PROXY-01
• Pilotnetz: 2001:db8:20:30::/64
• IPv6-Adresse der Firewall im Clientnetz: 2001:db8:20:30::1
• Proxy-FQDN: fw01.corp.example
• Proxyport: TCP 3128
• kontrolliertes A-only-Ziel: v4-test.corp.example
• dokumentierte Zieladresse: 192.0.2.80
• IPv6-Regel: LAN6_DirectProxy_to_IPv4
• IPv4-Regel: Proxy_IPv4_Egress_Pilot
• Web Policy: Web_Standard_IPv6_Pilot

2001:db8::/32, 192.0.2.0/24 und .example sind Dokumentationsbereiche. Diese funktionieren nicht als produktive Adressen und werden durch das eigene IPv6-Präfix, die echte Firewall-Adresse sowie einen kontrollierten DNS-Namen ersetzt. Der Pilotclient muss tatsächlich nur IPv6 verwenden; ein parallel aktiver IPv4-Pfad würde den Test entwerten.

Das Testziel benötigt einen A-Record, aber keinen AAAA-Record. Am besten wird dafür ein eigener kleiner Webserver oder ein kontrollierter Test-Virtual-Host verwendet. Eine zufällige öffentliche Website ist ungeeignet, weil ihr Betreiber jederzeit IPv6 aktivieren oder DNS-Antworten ändern kann.

Wie WAN-Prefix, Router Advertisement und DHCPv6 zusammengehören, zeigt IPv6 Prefix Delegation konfigurieren. NAT64 repariert keine fehlende IPv6-Adressierung im Clientnetz.

Voraussetzungen kontrollieren

Vor den Regeln müssen vier getrennte Grundlagen funktionieren:

• Der Client besitzt eine gültige IPv6-Adresse, Default Route und funktionierendes DNS.
• fw01.corp.example liefert im Clientnetz die vorgesehene AAAA-Antwort der Firewall.
• Der Direct Web Proxy lauscht unter Web > General settings > Web proxy configuration auf dem dokumentierten Port, im Beispiel 3128.
• Die Firewall besitzt einen funktionierenden IPv4-WAN-Pfad zum Ziel.

Unter Administration > Device access muss Web proxy für die konkrete Clientquelle und die vorgesehene Firewall-Adresse erreichbar sein. Eine breite Freigabe für die ganze LAN- oder Wi-Fi-Zone ist für einen Pilot nicht nötig. Wichtig bleibt die Proxygrenze: Ein zugelassener Client kann über diesen Pfad lokale HTTP-/HTTPS-Dienste der Firewall erreichen. Die Managementziele werden deshalb wie im Basisartikel ausdrücklich negativ getestet.

Der Client erhält den Proxy-FQDN und Port per verwalteter Browserrichtlinie, Betriebssystemvorgabe oder PAC-Datei. Der FQDN muss vom IPv6-only-Client über IPv6 erreichbar sein. Eine Proxyadresse, die nur einen A-Record besitzt, kann ein IPv6-only-Client nicht als ersten Hop verwenden.

Vorhandene Firewallregeln, Web Policies, Authentifizierung, TLS Inspection und SD-WAN Routes werden dokumentiert. Die zwei Pilotregeln kommen so weit nach oben, dass sie vor einer allgemeineren passenden Regel ausgewertet werden, ohne bestehende Schutzregeln unkontrolliert zu übersteuern.

IPv6-Regel zum Proxy erstellen

Unter Rules and policies > Firewall rules zuerst IPv6 auswählen und über Add firewall rule > New firewall rule eine Regel erstellen:

• Rule name: LAN6_DirectProxy_to_IPv4
• Action: Accept
• Log firewall traffic: aktiv
• Source zones: LAN
• Source networks and devices: IPv6-Pilotnetz oder einzelner Pilotclient
• Destination zones: WAN
• Destination networks: kontrolliertes FQDN-Ziel oder für den späteren Rollout die bewusst geplante Zielmenge
• Services: eigener TCP-Service für 3128
• Match known users: nur mit bereits funktionierender Authentifizierung und den vorgesehenen Benutzern oder Gruppen
• Web filtering > Web policy: Web_Standard_IPv6_Pilot

Die Zielzone WAN wirkt zunächst ungewöhnlich, weil sich der Client technisch mit einer Firewall-Adresse verbindet. Sophos verlangt für die Übergabe an die Proxykomponente jedoch WAN oder Any. Das gilt laut Hersteller sogar dann, wenn der letztliche Webserver in LAN oder DMZ steht. Die Zielzone wird deshalb nicht auf Verdacht an die physische Serverzone angepasst.

Sophos erlaubt bei Services auch Any. Der konkrete Listener-Port ist für einen Pilot nachvollziehbarer und verhindert eine unnötig breite Freigabe. Wird der Web proxy listening port geändert, müssen Service, PAC-/Browservorgabe, Device Access und Tests denselben Wert verwenden.

Für IPv6-only-Endpoints werden Benutzer- und Gruppeneinstellungen in dieser IPv6-Regel festgelegt. Die Web Policy wirkt ebenfalls hier. Regelreihenfolge, Logging und Benutzerbezug erklärt die Anleitung zu Firewall-Regeln; Kategorien und Aktionen werden unter Web Protection Policies geplant.

IPv4-Regel vom Proxy zum Ziel erstellen

Danach in Rules and policies > Firewall rules auf IPv4 wechseln und die zweite Regel erstellen:

• Rule name: Proxy_IPv4_Egress_Pilot
• Action: Accept
• Log firewall traffic: aktiv
• Source zones: Any
• Source networks and devices: Any
• Destination zones: WAN
• Destination networks: zuerst das kontrollierte A-only-Ziel, später nur die tatsächlich benötigte Zielmenge
• Services: HTTP und HTTPS beziehungsweise die wirklich benötigten Zielports
• Match known users: für diesen IPv6-only-Ablauf nicht als Ersatz für den Benutzerbezug der IPv6-Regel verwenden
• Other security features: gewünschte Application Control-, IPS- und gegebenenfalls Traffic-Shaping-Policy

Das offizielle Sophos-Beispiel verwendet für Source Zone und Source Network Any, weil der Proxy die IPv4-Verbindung erzeugt. Diese Werte werden nicht fälschlich durch das IPv6-Clientnetz ersetzt. Die Pilotregel wird stattdessen bei Destination und Services eng gehalten und anhand ihrer Rule ID kontrolliert.

Die Web Policy wird nicht in diese IPv4-Regel verschoben. Sie gehört zum ersten, benutzerbezogenen Proxyabschnitt. Application Control und IPS schützen dagegen den Abschnitt zwischen Proxy und IPv4-Ziel. Eine Traffic-Shaping-Policy in der IPv4-Regel betrifft diesen Egress; Sophos dokumentiert zugleich, dass Traffic Shaping nicht auf die direkte Verbindung zwischen Client und Proxy angewendet wird.

Es wird keine zusätzliche NAT64-Regel angelegt. Der normale IPv4-WAN-Pfad der Firewall muss trotzdem funktionieren. Wenn schon eine bestehende IPv4-Regel denselben Proxy-Egress kontrolliert abdeckt, darf sie nach Rule-ID- und Policy-Prüfung weiterverwendet werden; eine zweite parallele Any-Regel wäre dann schlechter als eine bewusst dokumentierte bestehende Regel.

Den echten IPv6-zu-IPv4-Pfad testen

DNS- und Listener-Vorprüfung

Auf einem Windows-Pilotclient helfen folgende lesende Prüfungen:

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

Der Proxy-FQDN muss die erwartete IPv6-Adresse liefern. Das Testziel muss einen A-Record besitzen; für den AAAA-Test wird keine Zieladresse erwartet. Test-NetConnection bestätigt nur den TCP-Listener, nicht Web Policy, DNS-Auflösung im Proxy oder IPv4-Egress.

Beide Regeln und Schutzebenen abnehmen

1. Eine neue private Browsersitzung auf dem IPv6-only-Piloten öffnen.
2. Effektiven Proxy beziehungsweise die geladene PAC-Datei kontrollieren.
3. Das erlaubte A-only-Ziel aufrufen.
4. Ein durch Web_Standard_IPv6_Pilot bewusst blockiertes Ziel aufrufen.
5. Im Log viewer die IPv6-Regel, Source, Benutzer, Web Policy, Action und Firewall Rule ID prüfen.
6. Für die nachgelagerte Verbindung die IPv4-Regel, IPv4-Ziel, Service, Application Control/IPS und zweite Firewall Rule ID prüfen.
7. Den gleichen Zielaufruf ohne Proxy negativ testen; der IPv6-only-Client darf das A-only-Ziel dann nicht direkt über IPv4 erreichen.
8. Eine Anwendung ohne Proxyunterstützung testen und bestätigen, dass sie nicht irrtümlich als NAT64-fähig gilt.

Erfolg ist erst belegt, wenn der Zielname wirklich A-only ist, der Client den Proxy über IPv6 erreicht, beide erwarteten Regeln matchen und der erlaubte sowie blockierte Webtest die geplanten Aktionen zeigen. Das Vorgehen zum Abgleich von Rule ID, Log Viewer, Policy Tester und Packet Capture steht unter Firewall-Regeln systematisch testen.

Fehler systematisch eingrenzen

Der Proxyport ist über IPv6 nicht erreichbar

AAAA-Antwort des Proxy-FQDNs, Clientadresse, Default Route, Neighbor Discovery, Firewall-Interface und Web proxy unter Device Access prüfen. Ein erfolgreicher IPv4-Test von einem anderen Client sagt nichts über den IPv6-Listenerpfad aus.

Die IPv6-Regel matcht, aber das Ziel lädt nicht

Zuerst bestätigen, dass der Proxy den Zielnamen als A-Record auflöst und die Firewall selbst einen funktionierenden IPv4-WAN-Pfad besitzt. Danach die IPv4-Regel, Destination, Service, Reihenfolge und Rule ID prüfen. Die IPv6-Regel ist nur die erste Hälfte.

Nur Dual-Stack-Websites funktionieren

Dann ist der NAT64-Pfad noch nicht bewiesen. Das Testziel auf einen vorhandenen AAAA-Record kontrollieren. Für die Abnahme ein eigenes A-only-Ziel verwenden und parallel aktives IPv4 am Client ausschliessen.

Web Policy oder Benutzer stimmt nicht

Die Zuordnung in der IPv6-Regel prüfen. Für IPv6-only-Endpoints bewertet SFOS Match known users in beiden Regeln, Sophos weist die Einstellungen aber ausdrücklich der IPv6-Regel zu. Ein Benutzer-Match in der IPv4-Regel darf nicht als Ersatz für den fehlenden Benutzerbezug des ersten Abschnitts verwendet werden.

Application Control oder IPS greift nicht

Diese Funktionen in der IPv4-Regel und nicht nur in der IPv6-Regel prüfen. Danach anhand der IPv4-Rule-ID bestätigen, dass wirklich diese Regel den Proxy-Egress verarbeitet. Eine grüne Web-Filter-Entscheidung belegt Application Control oder IPS nicht.

Interne oder lokale Ziele verhalten sich unerwartet

Auch bei einem letztlichen Ziel in LAN oder DMZ verlangt die IPv6-Regel zur Proxyübergabe WAN oder Any. Die tatsächliche Zielzone wird in der IPv4-Regel abgebildet. Zusätzlich die lokale Managementdienst-Exposition des Proxyzugangs und interne DNS-Antworten kontrollieren.

SD-WAN, HA und Rollback

Eine SD-WAN Route mit Services HTTP und HTTPS matcht die Clientverbindung zum Proxyport 3128 nicht. Für den ersten Abschnitt muss der tatsächliche Listener-Port oder bewusst Any verwendet werden. Der Proxy-Egress braucht ausserdem einen funktionierenden WAN-Gateway- oder statischen Rückweg. Die Sonderregeln erklärt SD-WAN Routes einrichten und testen.

In HA wird keine unterbrechungsfreie Fortsetzung einer bestehenden Proxyverbindung versprochen. Nach einem kontrollierten Failover eine neue Browsersitzung öffnen und Proxy-AAAA, IPv6-Rule-ID, Web Policy, IPv4-Rule-ID sowie Zielzugriff erneut prüfen. Für die Logsuche zählt der Node, der den jeweiligen Traffic verarbeitet hat.

Für den Rollback:

1. Pilotregeln deaktivieren oder auf den dokumentierten Vorzustand zurücksetzen.
2. Dedizierte Device-Access-Exception für den Piloten entfernen, sofern sie nur für diesen Test angelegt wurde.
3. PAC-, GPO- oder Browser-Proxyvorgabe am Piloten zurücknehmen.
4. Vorherige IPv4-/IPv6-Regelreihenfolge und SD-WAN-Konfiguration wiederherstellen.
5. Direkten IPv6-Zugriff, bestehenden Proxytraffic und lokale Managementdienste erneut prüfen.

Die beiden Regeln werden nicht gelöscht, bevor der vorherige Pfad dokumentiert ist und eine geöffnete Adminsitzung beziehungsweise ein alternativer Managementzugang zur Verfügung steht.

Checkliste für die Freigabe

• Client ist nachweislich IPv6-only.
• Proxy-FQDN liefert die erwartete AAAA-Adresse.
• Testziel besitzt A, aber keinen AAAA-Record.
• Direct Web Proxy und Device Access sind auf den Piloten begrenzt.
• IPv6-Regel verwendet Zielzone WAN, echten Listener-Port, Logging und Web Policy.
• Benutzerbezug ist bei Bedarf in der IPv6-Regel positiv und negativ getestet.
• IPv4-Regel verarbeitet den Proxy-Egress mit den geplanten Zielports und Schutzfunktionen.
• Beide Firewall Rule IDs und beide IP-Versionen sind im Test belegt.
• Managementdienst-Exposition, Non-Proxy-Traffic, SD-WAN und HA sind bewusst abgegrenzt.
• Rollback, Owner und Review-Datum sind dokumentiert.

Häufige Fragen