Sophos Firewall IPv6 Support und Grenzen in SFOS 22

Sophos Firewall unterstützt IPv6 in SFOS 22 für zentrale Netzwerk-, Routing-, VPN-, Regel-, Schutz- und Diagnosefunktionen. Ein vollständiger IPv6-only-Betrieb ist trotzdem nicht für jede Umgebung realistisch. WAF-Regeln, IPv6-Auflösung in FQDN-Hostobjekten, die integrierte Let’s-Encrypt-Funktion, Up2date, RED, Remote-Access-IPsec, RIPng und Multicast besitzen dokumentierte Grenzen.

Vor einem Rollout wird deshalb nicht nur geprüft, ob ein Interface eine IPv6-Adresse erhält. Entscheidend ist, ob jede Funktion im tatsächlichen Ende-zu-Ende-Pfad IPv6 unterstützt. Wo eine benötigte Funktion fehlt, bleibt Dual Stack oder ein gezielt geplanter IPv4-Pfad meist sicherer als eine erzwungene IPv6-only-Architektur.

Dieser Artikel ordnet die offizielle SFOS-22-IPv6-Supportmatrix für den Betrieb ein. Die konkrete Konfiguration von Prefix Delegation, Routing, VPN und Regeln bleibt in den verlinkten Fachartikeln.

IPv6-Design in sieben Schritten prüfen

1. Exakten SFOS-Build, Provideranschluss, Präfix und alle benötigten Dienste dokumentieren.
2. Den vollständigen Pfad vom Client oder Sender bis zum Ziel in einzelne Funktionen zerlegen: Interface, Adressierung, DNS, Routing, Regel, Schutzmodul, VPN, Portal und Updatepfad.
3. Jede dieser Funktionen gegen die SFOS-22-Supportgrenzen dieses Artikels prüfen.
4. Für nicht unterstützte Abhängigkeiten einen bewussten IPv4- oder alternativen Produktpfad festlegen. Keine fehlende Funktion mit einer breiten Regel oder Any umgehen.
5. IPv6-Interfaces, Router Advertisement, Routen, Objekte und Firewall-Regeln getrennt von IPv4 konfigurieren.
6. Adresse, Default Route, Neighbor Discovery, DNS, Route Lookup, Rule ID, Packet Capture und den eigentlichen Dienst nacheinander testen.
7. Erst nach Positiv- und Negativtest produktiv umstellen; IPv4-Fallback und vorherige Regelreihenfolge bis dahin erhalten.

⚠️ Ein Haken in der Sophos-Supportmatrix bestätigt Produktunterstützung, aber keine fertige Konfiguration und keine Funktionsgleichheit mit IPv4. Ein erfolgreicher IPv6-Ping beweist weder DNS, Policy, Schutzprofil, VPN noch Anwendung. Umgekehrt wird eine dokumentiert nicht unterstützte Funktion nicht durch Service-Restarts, versteckte CLI-Optionen oder eine breitere Firewall-Regel unterstützt.

Was die Supportmatrix wirklich aussagt

Die aktuelle Sophos-Seite wurde am 8. Januar 2026 aktualisiert und gilt für die SFOS-22-Hilfe. Sie trennt Funktionen, die IPv6 verarbeiten können, von Funktionen, die weiterhin keinen IPv6-Support besitzen. Diese Grenze ist enger als die allgemeine Aussage, dass die Firewall IPv6 unterstützt.

Vier Ebenen müssen getrennt bleiben:

• Adressierung: Das Interface besitzt ein IPv6-Präfix und der Client eine passende Adresse.
• Routing: Hin- und Rückweg zeigen auf die erwarteten Interfaces und Gateways.
• Policy: Eine eigene IPv6-Regel erlaubt genau den geplanten Traffic und protokolliert den Test.
• Dienst: VPN, WAF, Proxy, E-Mail, Portal oder Updatefunktion unterstützt den IPv6-Pfad tatsächlich.

Eine funktionierende Ebene beweist die nächste nicht. Genau diese Trennung verhindert, dass ein grüner Interface-Status als Beleg für eine noch nicht unterstützte WAF- oder Updatefunktion gewertet wird.

Netzwerk und Adressierung

Unterstützt

• statische IPv6-Adressen auf physischen, Bridge-, Alias-, VLAN- und LAG-Interfaces;
• DHCP Prefix Delegation;
• DHCPv6 Server, Client und Relay sowie dynamische und statische Leases;
• Neighbor Discovery Protocol (NDP) und Router Advertisement;
• DNS Lookup und Reverse Name Lookup;
• IPv6-Tunnel mit 6in4, 6to4, 6rd und 4in6.

Nicht unterstützt oder eingeschränkt

• IPv6 über Cellular WAN;
• IPv6 PPPoE;
• Dynamic DNS über IPv6;
• DNS64;
• Tunnel Broker;
• RED Hardware und Firewall-RED-Tunnel zwischen zwei Sophos Firewalls;
• DHCP Prefix Delegation auf einem LAG-Interface.

Die Prefix-Delegation-Anleitung erklärt den ausführbaren Pfad vom Providerpräfix über das interne Interface bis zu Router Advertisement und Firewall-Regeln: IPv6 Prefix Delegation auf Sophos Firewall konfigurieren. Bei statischen Präfixen bleiben Interface-, VLAN- und Zonenplanung aus Sophos Firewall Zonen und Interfaces richtig planen relevant.

DNS64 und NAT64 dürfen nicht verwechselt werden. SFOS 22 listet DNS64 als nicht unterstützt. Den von Sophos dokumentierten NAT64-Weg stellt dagegen der Direct Web Proxy bereit und nur für expliziten HTTP-/HTTPS-Proxytraffic. Das ist kein allgemeines Protokoll-Gateway.

Routing und Multicast

Unterstützt

• statische IPv6-Unicast-Routen;
• SD-WAN-Routen für IPv6;
• BGP-IPv6 und OSPFv3;
• WAN Load Balancing;
• Upstream Proxy.

Nicht unterstützt

• RIPng;
• dynamisches IPv6-Multicast mit Multicast Listener Discovery (MLD);
• statische IPv6-Multicast-Routen.

Eine IPv4-Route wird nicht automatisch zu einer IPv6-Route. Für feste Netze steht der Ablauf unter Statische IPv4- und IPv6-Routen einrichten. OSPFv3 wird getrennt von OSPFv2 konfiguriert; die Router ID bleibt dabei in IPv4-Schreibweise. Der sichere Ablauf und die fehlende OSPFv3-Authentisierung sind unter Sophos Firewall OSPF konfigurieren und prüfen beschrieben.

Die vorhandenen Avanet-Artikel zu statischem Multicast und PIM-SM behandeln IPv4. Aus deren Befehlen und Menüs darf kein IPv6-MLD- oder Multicast-Ablauf abgeleitet werden.

VPN

Unterstützt

• Site-to-Site SSL VPN;
• Remote Access SSL VPN;
• Site-to-Site IPsec.

Nicht unterstützt

• Remote Access IPsec über IPv6;
• L2TP VPN über IPv6;
• PPTP VPN über IPv6.

Beim Site-to-Site-IPsec kann die Verbindung IPv4, IPv6 oder bei einer route-based Any-to-Any-Verbindung Dual verwenden. Dual verlangt getrennte IPv4- und IPv6-Firewall-Regeln und einen bewusst geplanten Routingpfad. Die vollständige Typentscheidung steht unter Sophos Firewall Site-to-Site IPsec VPN einrichten.

Die Aussage Remote Access SSL VPN unterstützt IPv6 bedeutet nicht, dass jede Ressource, jedes FQDN-Objekt und jeder Full-Tunnel-Pfad automatisch dual-stack funktioniert. Pool, erlaubte Ressourcen, DNS, IPv6-Regeln und der reale Clienttest bleiben getrennte Prüfpunkte.

Regeln, NAT und Schutzmodule

Unterstützt

• zonenbasierte IPv6-Firewall-Regeln;
• NAT66 und NAT64, wobei NAT64 nur im Proxy Mode verfügbar ist;
• Server Load Balancing;
• SSL/TLS Inspection Rules;
• IPS, DoS Bypass Rules und Spoof Protection;
• Web Filtering, Application Filter und Malware Scanning;
• Zero-day Protection.

Nicht unterstützt

• WAF-Regeln über IPv6;
• Wireless als IPv6-Schutzpfad;
• die in der Sophos-Matrix separat bezeichnete Funktion Advanced protection.

Eine IPv4-Firewall-Regel erlaubt keinen IPv6-Traffic. In Rules and policies > Firewall rules wird die IP-Version bewusst gewählt und die Regel mit Source, Destination, Service, Logging und Rule ID abgenommen. Die Grundlagen stehen unter Sophos Firewall-Regeln verstehen und sicher konfigurieren.

Für IPv6-only-Clients mit einem IPv4-only-Webziel gilt der getrennte Proxyablauf NAT64 mit Direct Web Proxy. Non-Proxy-Traffic, UDP, ICMP und Anwendungen ohne explizite Proxyunterstützung werden dadurch nicht übersetzt.

E-Mail, Portale und Administration

Unterstützt

• SMTP MTA und SMTP Proxy;
• IMAP Proxy und POP Proxy;
• WebAdmin, User Portal und SSH;
• NTP und SNMP;
• Authentication Server.

Nicht unterstützt

• Quarantine Digest über IPv6.

IPv6-Support für WebAdmin oder SSH ist keine Empfehlung, diese Dienste aus dem Internet freizugeben. Device Access und Local Service ACL bleiben eng auf das Managementnetz oder bekannte Quellnetze begrenzt. Der IPv6-Pilot muss zusätzlich negativ bestätigen, dass nicht vorgesehene Managementquellen keinen Zugriff erhalten.

Diagnose, Objekte, Updates und Zertifikate

Unterstützt

• Current Activities für Benutzer und Verbindungen;
• Ping, Traceroute, Name Lookup, Route Lookup und Packet Capture;
• Syslog und Reporting;
• IPv6 IP Hosts;
• Traffic Shaping und QoS.

Nicht unterstützt oder eingeschränkt

• Policy Tester für IPv6;
• Country Hosts für IPv6;
• IPv6-Auflösung in FQDN-Hostobjekten;
• Up2date Infrastructure über IPv6;
• die integrierte Let’s-Encrypt-Funktion über IPv6.

Die FQDN-Grenze betrifft das SFOS-Hostobjekt: Die Firewall löst für dieses Objekt keine IPv6-Adressen auf. Das bedeutet nicht, dass DNS-Clients oder Name lookup generell keine AAAA-Antworten erhalten. Ein dynamisches IPv6-Ziel darf aber nicht mit einem FQDN-Hostobjekt geplant werden, als würde SFOS dessen AAAA-Adressen automatisch pflegen.

Auch die Let’s-Encrypt-Grenze ist produktspezifisch. Sie sagt nicht, dass ACME oder Zertifikate allgemein IPv4-only sind. Sie bedeutet, dass die integrierte SFOS-Funktion nicht als IPv6-Pfad eingeplant wird. Für Ausstellung, Erneuerung und Up2date bleibt deshalb ein funktionierender IPv4-Pfad bestehen, solange Sophos diese Grenzen dokumentiert.

Beispiel für einen kontrollierten Dual-Stack-Pilot

Das Beispiel trennt produktive und ersetzbare Werte:

• Providerpräfix: 2001:db8:100::/48
• internes Testnetz: 2001:db8:20:30::/64
• Firewall im Testnetz: 2001:db8:20:30::1
• Pilotclient: 2001:db8:20:30::50
• kontrolliertes Testziel: 2001:db8:40:50::20
• IPv4-Rückweg für Management, Up2date und Let’s Encrypt bleibt vorerst bestehen.

2001:db8::/32 ist ein Dokumentationspräfix und im Internet nicht produktiv routbar. Alle Adressen werden durch das eigene Providerpräfix und kontrollierte Testsysteme ersetzt. Das /64 ist für ein normales Clientsegment das geplante Beispielnetz; die tatsächliche Präfixaufteilung richtet sich nach der Providerdelegation und dem internen Netzplan.

Vor dem Pilot stehen diese Entscheidungen fest:

1. Welche Funktionen verwendet der konkrete Flow?
2. Sind alle davon in der SFOS-Matrix als unterstützt aufgeführt?
3. Gibt es ein IPv4-Fallback für Updates, Zertifikate und Management?
4. Welche IPv6-Regel soll matchen und welche Rule ID wird erwartet?
5. Welche negative Verbindung muss weiterhin blockiert bleiben?
6. Wie werden DNS, Rückweg und der eigentliche Anwendungsdienst geprüft?

IPv6-Pfad abnehmen

Eine belastbare Abnahme geht von unten nach oben:

1. Interface: Erwartete IPv6-Adresse und Präfix auf WAN und internem Interface prüfen.
2. Client: IPv6-Adresse, Prefix Length und Default Route kontrollieren.
3. Neighbor Discovery: Unter Network > Neighbors (ARP–NDP) den erwarteten IPv6-Nachbarn und das richtige Interface prüfen. Die sichere Einordnung steht unter ARP- und NDP-Neighbor-Cache prüfen.
4. DNS: A- und AAAA-Antworten getrennt prüfen. Ein funktionierender A-Record beweist keinen IPv6-Pfad.
5. Routing: Diagnostics > Tools > Route lookup mit der tatsächlichen IPv6-Zieladresse verwenden und Hin- sowie Rückweg dokumentieren.
6. Policy: Im Log Viewer die erwartete IPv6-Regel, Action und Firewall Rule ID bestätigen. Da der Policy Tester IPv6 nicht unterstützt, sind Log Viewer, Route Lookup, Packet Capture und der echte Testfluss wichtiger.
7. Paketfluss: Packet Capture muss Eingang und erwarteten Ausgang zeigen. Ein Paket am Eingang ohne Weiterleitung grenzt Route, Regel oder Schutzmodul ein.
8. Dienst: HTTPS, VPN, SMTP, DNS oder die konkrete Anwendung positiv testen; ein Ping allein genügt nicht.
9. Negativtest: Eine nicht erlaubte IPv6-Quelle oder ein nicht freigegebener Service bleibt blockiert.

Die lesenden Device-Console-Befehle für einen kontrollierten Beispielpfad lauten:

ping6 2001:db8:40:50::20
traceroute6 2001:db8:40:50::20
dnslookup6 app.example.com

Die Dokumentationsadresse und .example funktionieren nicht produktiv und werden durch ein kontrolliertes Ziel ersetzt. Diese Befehle prüfen Erreichbarkeit, Pfad und Namensauflösung, aber weder eine bestimmte Firewall-Regel noch die Anwendung. Weitere sichere Grundbefehle erklärt Sophos Firewall Troubleshooting mit Basisbefehlen.

Fehler nach Symptom eingrenzen

Client erhält keine IPv6-Adresse oder Default Route

Providerpräfix, WAN-Zuweisung, Delegated Interface, Router Advertisement, VLAN und Clientsegment prüfen. Bei einem LAG nicht weiter mit Prefix Delegation experimentieren, weil Sophos diese Kombination ausdrücklich ausschliesst. IPv4-Funktion beweist keine korrekte IPv6-Adressierung.

IPv6-Adresse ist vorhanden, aber der Dienst funktioniert nicht

Zuerst DNS-Antwort, NDP, Route Lookup, IPv6-Regel, Rule ID und Rückweg prüfen. Danach den Dienst selbst untersuchen. Eine breite Any-Regel wird nicht als Diagnoseersatz erstellt. Wenn die benötigte Funktion in der Supportmatrix nicht unterstützt ist, wird der Pfad auf IPv4 oder eine andere Architektur umgestellt.

FQDN-Hostobjekt enthält keine IPv6-Adresse

Das ist die dokumentierte Produktgrenze. FQDN-Hostobjekte lösen in SFOS keine IPv6-Adressen auf. Ein statischer IPv6 IP Host kann für eine stabile, betrieblich gepflegte Adresse passen; bei dynamischen Zielen muss das Design neu bewertet werden. Ein breites Zielobjekt ist kein sicherer Ersatz.

WAF, RED oder Remote-Access-IPsec soll über IPv6 arbeiten

Diese Fälle sind in der aktuellen Matrix nicht unterstützt. Der Rollout stoppt, bevor Regeln, Zertifikate oder Tunnel produktiv umgebaut werden. IPv4 bleibt für diese Funktion bestehen oder es wird ein separat unterstützter Zugriffspfad gewählt.

Updates oder Let’s Encrypt scheitern in einem IPv6-only-Netz

Up2date Infrastructure und die integrierte Let’s-Encrypt-Funktion sind laut Matrix nicht über IPv6 unterstützt. Zuerst den vorgesehenen IPv4-Egress, DNS, Routing und Regeln wiederherstellen. Service-Restarts und Zertifikatsneuanforderungen lösen eine fehlende Produktunterstützung nicht.

Rollback

1. Neue IPv6-Regeln deaktivieren oder auf die dokumentierte vorherige Regelreihenfolge zurücksetzen.
2. Pilot-Router-Advertisement, Delegated Interface oder statische IPv6-Zuweisung nur innerhalb des geplanten Wartungsfensters zurücknehmen.
3. Vorherige IPv4-Routen, DNS-Antworten und Managementzugänge unverändert erhalten oder wiederherstellen.
4. Temporäre IPv6-Hostobjekte und Testregeln erst nach erfolgreichem Rückweg entfernen.
5. IPv4-Management, Up2date, Zertifikatserneuerung und den ursprünglichen Dienst erneut prüfen.
6. Fehlerzeitpunkt, Build, Interface, Route Lookup, Rule ID und Packet Capture sichern, bevor bei einem weiterhin unterstützten IPv6-Pfad ein Supportfall eröffnet wird.

Checkliste

• SFOS-Version und Build dokumentiert.
• Jede benötigte Funktion gegen die aktuelle IPv6-Supportmatrix geprüft.
• Nicht unterstützte Abhängigkeiten besitzen einen bewussten IPv4- oder Alternativpfad.
• Präfix, /64-Segmente, Router Advertisement und DNS geplant.
• IPv4- und IPv6-Regeln getrennt erstellt und geloggt.
• Device Access wurde durch IPv6 nicht unbeabsichtigt erweitert.
• NDP, Route Lookup, Rule ID, Packet Capture und echter Dienst geprüft.
• Positiv- und Negativtest bestanden.
• Up2date und Let’s Encrypt besitzen weiterhin einen funktionierenden IPv4-Pfad.
• Rollback und unabhängiger Managementzugang sind dokumentiert.

FAQ