IPv6 Router Advertisement auf Sophos Firewall konfigurieren

Ein IPv6-Client kann eine Adresse besitzen und trotzdem kein funktionierendes Netz haben. Auf Sophos Firewall liefert Router Advertisement, kurz RA, das Präfix, den Default Router und die Information, ob SLAAC oder DHCPv6 für weitere Werte zuständig ist. DHCPv6 allein verteilt keinen Default Gateway.

Der häufigste Fehler ist deshalb nicht ein falscher Lease-Bereich, sondern eine unpassende Kombination aus RA-Präfix, Flags und DHCPv6-Rolle. Für ein einfaches SLAAC-Netz genügt normalerweise ein angekündigtes /64 mit Autonomous. Soll ein DHCPv6-Server Adressen verteilen, wird zusätzlich Managed flag benötigt. Other flag weist Clients auf weitere DHCPv6-Parameter wie DNS oder Domain Name hin.

⚠️ Ein falsches Router Advertisement kann auf dem gesamten Layer-2-Segment Adressen oder den Default Router verändern. Vor dem Speichern vorhandene RA-Quellen, IPv6-Präfixe und den Managementzugang dokumentieren. Die Umstellung zuerst in einem Pilot-VLAN mit einem echten Client testen.

Router Advertisement in acht Schritten

1. Das vorgesehene IPv6-/64, das Clientsegment und die gewünschte Rolle von SLAAC und DHCPv6 festlegen.
2. Prüfen, ob bereits ein Router RA-Nachrichten sendet oder Prefix Delegation automatisch eine RA-Konfiguration erzeugt hat.
3. Network > IPv6 router advertisement öffnen und Add wählen.
4. Das IPv6-fähige physische Interface, LAG, VLAN oder Bridge-Interface des Clientsegments auswählen.
5. Minimales und maximales Advertisement-Intervall passend zur Umgebung festlegen.
6. Managed flag, Other flag und Default gateway nur entsprechend dem geplanten Clientmodell aktivieren.
7. Das /64 mit On-link, Autonomous, Preferred lifetime und Valid lifetime hinzufügen.
8. Speichern und mit einem neuen Clientlauf RS, RA, Adresse, Default Gateway, DNS und echten IPv6-Nutztraffic kontrollieren.

Ein sichtbarer RA-Eintrag ist noch kein Erfolg. Erst der Client zeigt, ob Betriebssystem, Präfix, DHCPv6 und Default Route dieselbe Planung umsetzen.

SLAAC, DHCPv6 und die beiden Flags verstehen

Unabhängig davon erzeugt ein IPv6-fähiges Interface automatisch eine Link-Local-Adresse für die Kommunikation im lokalen Segment; dafür ist kein RA erforderlich. Diese lokale Adresse ist von der globalen SLAAC-Adresse zu unterscheiden und beweist nicht, dass die globale Adresskonfiguration funktioniert. Auch eine globale Adresse allein ist noch kein Nachweis für Internetzugang.

Bei SLAAC bildet der Client seine globale IPv6-Adresse aus dem angekündigten Präfix und seinem Interface Identifier. Dazu muss das Präfix Autonomous erlauben. Die Firewall kündigt über RA zusätzlich den Default Router an, wenn Default gateway aktiviert ist.

Managed flag bedeutet, dass Clients ihre IPv6-Adresse von einem DHCPv6-Server beziehen sollen. Sophos weist ausdrücklich darauf hin, dieses Flag nur zu verwenden, wenn ein DHCPv6-Server verfügbar ist. Der vollständige Serverablauf steht unter DHCPv6-Server auf Sophos Firewall einrichten und testen.

Other flag verweist Clients für zusätzliche Netzwerkparameter an DHCPv6. Dazu können DNS-Server, Domain Name, NIS, NISP, SIP, SNTP und BCMS gehören. Das Flag stellt diese Werte nicht selbst bereit; DHCPv6 muss sie tatsächlich liefern und der Client muss sie unterstützen.

Je nach Betriebssystem kann ein Client mehrere Adressen bilden oder Flags unterschiedlich auswerten. Deshalb wird die gewünschte Kombination nicht nur aus der WebAdmin-Maske abgeleitet, sondern mit den real eingesetzten Clientplattformen geprüft.

Adressmodell bewusst wählen

Die drei Schalter erfüllen unterschiedliche Aufgaben: Managed flag und Other flag stehen im RA-Kopf, Autonomous gehört dagegen zum einzelnen angekündigten Präfix. Default gateway ist nochmals unabhängig davon. Damit lassen sich diese gebräuchlichen Modelle abbilden:

• Nur SLAAC: Autonomous und Default gateway ein, Managed flag aus. Other flag bleibt aus, wenn der Client keine weiteren Werte per DHCPv6 beziehen soll.
• SLAAC plus stateless DHCPv6: Autonomous, Default gateway und Other flag ein, Managed flag aus. Die Adresse entsteht per SLAAC; DHCPv6 liefert beispielsweise DNS.
• Stateful DHCPv6: Managed flag und Default gateway ein, ein DHCPv6-Server ist erreichbar. Autonomous bleibt aus, wenn der Client nicht zusätzlich eine SLAAC-Adresse bilden soll; Other flag wird für weitere DHCPv6-Parameter gesetzt.
• Koexistenz: Sind Autonomous und Managed flag aktiv, können Clients SLAAC und DHCPv6 parallel verwenden. Diese Variante nur wählen, wenn mehrere Adressen beabsichtigt und die eingesetzten Betriebssysteme geprüft sind.

Die dokumentierte SFOS-22-RA-Maske enthält kein Feld für RDNSS oder DNSSL. Wer DNS über diesen Sophos-Ablauf verteilen will, plant daher Other flag und einen DHCPv6-Server gemeinsam. Statische Clientkonfiguration bleibt davon unberührt.

Automatische RA bei Prefix Delegation

Wird auf einem internen Interface IPv6 prefix delegation ausgewählt, erstellt SFOS automatisch ein Router Advertisement. Das automatisch zugewiesene Präfix dieses RA-Servers lässt sich nicht ändern. Soll zusätzlich ein anderes Präfix angekündigt werden, wird ein weiterer RA-Server mit diesem Präfix angelegt.

Die automatische Erstellung ist praktisch, darf aber nicht übersehen werden. Sophos nennt in den Release Notes zu SFOS 21.5 GA für DHCP Prefix Delegation ausserdem RA und DHCPv6 als standardmässig aktiviert. Vor einem manuellen RA-Eintrag deshalb am internen Interface und unter Network > IPv6 router advertisement prüfen, welche Konfiguration im konkreten SFOS-22-System vorhanden und aktiv ist. Den gesamten Provider-, WAN- und Delegated-Interface-Ablauf erklärt IPv6 Prefix Delegation auf Sophos Firewall konfigurieren.

Wichtig für das Adressmodell: Die Option DHCPv6 server eines internen Interfaces im Modus Delegated liefert laut SFOS-22-Hilfe nur zusätzliche Parameter wie DNS, aber keine IPv6-Adressen. Für stateful DHCPv6 wird stattdessen ein separater adressverteilender Server unter Network > DHCP benötigt.

Beispielnetz planen

Das folgende Beispiel verwendet den für Dokumentation reservierten Bereich 2001:db8::/32. Er ist nicht für produktive Internetkommunikation bestimmt und wird durch das tatsächlich zugewiesene Präfix ersetzt:

• Clientsegment: VLAN20
• Firewall-Adresse: 2001:db8:20::1/64
• angekündigtes Präfix: 2001:db8:20::/64
• Betriebsart: SLAAC mit Default Gateway
• DHCPv6: nur für zusätzliche DNS-Parameter, falls benötigt
• Testclient: ein verwaltetes Gerät im VLAN20

Präfix, Interface-Adresse und Clientsegment müssen zusammengehören. Eine aus einem anderen VLAN kopierte RA-Konfiguration kann Clients eine formal gültige, aber im eigenen Routing nicht nutzbare Adresse geben.

Router Advertisement konfigurieren

Interface und Intervalle wählen

Unter Network > IPv6 router advertisement > Add wird zuerst das Clientinterface gewählt. SFOS erlaubt ein IPv6-fähiges physisches Interface, LAG, VLAN oder Bridge-Interface. Ein WAN- oder Transitinterface wird nicht allein deshalb gewählt, weil dort das Providerpräfix ankommt; massgeblich ist das Layer-2-Segment der Clients.

Min advertisement interval und Max advertisement interval bestimmen den Abstand zwischen unaufgeforderten RA-Nachrichten. Liegt das maximale Intervall bei neun Sekunden oder höher, verlangt SFOS für das Minimum 75 Prozent des Maximums. Es gibt keinen universellen Idealwert: Änderungen beeinflussen Erkennungszeit und Nachrichtendichte und werden deshalb nur mit dokumentiertem Ausgangswert und Clienttest vorgenommen.

Flags und Default Gateway setzen

Für das SLAAC-Beispiel bleibt Managed flag aus. Other flag wird nur aktiviert, wenn ein erreichbarer DHCPv6-Server tatsächlich zusätzliche Werte bereitstellt. Default gateway macht die Firewall zum angekündigten Default Router; die dazugehörige Zeit wird in Sekunden angegeben.

Ein aktiviertes Flag ist kein Funktionsnachweis. Wenn Managed flag gesetzt ist, aber kein DHCPv6-Server antwortet, bleibt die Adresskonfiguration unvollständig. Ist Default gateway aus, kann ein Client zwar eine globale Adresse bilden, erhält aus diesem RA aber keine Default Route.

Präfix und Lifetimes eintragen

Ein RA kann laut Sophos null oder mehrere Prefix-Optionen enthalten. Default Router, M/O-Flags und angekündigtes Präfix sind deshalb getrennte Entscheidungen: Ein RA ohne Präfix kann noch Routerinformationen liefern, erzeugt für dieses Segment aber keine SLAAC-Adresse.

Unter der Prefix-Advertisement-Konfiguration wird für das Beispiel 2001:db8:20::/64 eingetragen. Das Feld erwartet genau ein /64; ein grösseres delegiertes Providerpräfix wird zuerst in passende /64-Clientnetze aufgeteilt. On-link sagt dem Client, dass Ziele aus diesem Präfix ohne weiteren Router im lokalen Segment erreichbar sind. Autonomous erlaubt die automatische Adressbildung per SLAAC.

Preferred lifetime beschreibt in Minuten, wie lange eine Adresse für neue Verbindungen bevorzugt wird. Danach ist sie deprecated, kann aber für bestehende Kommunikation weiterverwendet werden. Valid lifetime beschreibt, wie lange die Adresse insgesamt gültig bleibt. Nach Ablauf darf sie nicht mehr senden oder empfangen. SFOS verlangt deshalb eine Valid lifetime, die mindestens so gross wie die Preferred lifetime ist.

Bei SLAAC kann ein weiteres RA mit einem passenden, für SLAAC geeigneten Präfix die Preferred lifetime anhand des neu empfangenen Werts auffrischen. Eine per DHCPv6 vergebene Adresse kann durch DHCPv6-Erneuerung aufgefrischt werden. Fortlaufend empfangene RA allein garantieren aber keinen dauerhaft bevorzugten Zustand: Eine angekündigte Preferred lifetime von null führt zur Deprecation; eine zu kurze kann vor der nächsten Auffrischung ablaufen.

Bei dynamischen Providerpräfixen dürfen diese Zeiten nicht so gewählt werden, als bliebe das Präfix dauerhaft gleich. Ein Prefix-Wechsel muss mit einem neuen Clientlauf und echten bestehenden sowie neuen Verbindungen geprüft werden.

MTU und Neighbor-Parameter bewusst behandeln

Die erweiterten Felder steuern Informationen für IPv6 Neighbor Discovery:

• Link MTU kündigt die maximale Paketgrösse in Bytes an. Bei 0 wird keine MTU-Information über dieses Interface beworben.
• Reachable time bestimmt, wie lange ein Client einen bestätigten Neighbor als erreichbar betrachtet.
• Retransmit time bestimmt die Wartezeit vor einer erneuten Neighbor Solicitation.
• Hop limit begrenzt die Zahl der Router-Hops; jeder Router reduziert den Wert.

Diese Werte nicht als allgemeinen Performance-Tuning-Regler verwenden. Eine MTU- oder Neighbor-Änderung braucht ein konkretes Fehlerbild, einen Vorherwert und erneute Tests für grosse Pakete, Neighbor Discovery und reale Anwendungen.

Nur API: Objektname und Status in SFOS 22/23

Für API-Automatisierung muss die SFOS-Version berücksichtigt werden. Diese Unterschiede betreffen das API-Schema, nicht die oben beschriebenen WebAdmin-Schritte; daraus lässt sich kein zusätzliches GUI-Feld ableiten.

Bei Add Router Advertisement und Update Router Advertisement verlangt SFOS 23 zusätzlich zum weiterhin obligatorischen Interface einen eindeutigen Name für das vorgesehene RA-Objekt. Name ist als SCALAR vom Datentyp STRING dokumentiert: höchstens 64 Zeichen, kein Komma, UTF-8-Zeichen erlaubt. Im SFOS-22-Schema fehlen dieser Parameter und das entsprechende Sample-Element.

Bei Delete Router Advertisement ist in SFOS 22 Interface der obligatorische Auswahlparameter; SFOS 23 ersetzt ihn durch Name mit denselben Namensregeln. Vor einer Löschung das beabsichtigte RA-Objekt, seinen Namen in SFOS 23 und das zugehörige Clientinterface eindeutig zuordnen und die funktionierende RA-Quelle samt Konfiguration dokumentieren. Ein bestehender funktionierender Eintrag wird nicht vorsorglich gelöscht. Wurde die bisherige Quelle ersetzt, gilt der unten beschriebene Rückweg: zuerst die bisherige Quelle wiederherstellen, erst danach den neuen Eintrag deaktivieren.

Die SFOS-23-API-Statustabelle führt für Add und Update neu 505 mit dem symbolischen Meldungsschlüssel Message.RouterAdvertisementNameRecordExists auf; SFOS 22 führt für diese Operationen nur 200 und 500 auf. Der Schlüssel weist auf einen bereits vorhandenen Namen hin. Bei diesem Ergebnis das vorgesehene Objekt und die Eindeutigkeit von Name prüfen, nicht blind löschen und neu anlegen. 505 ist hier ein dokumentierter API-Status, keine Aussage über einen HTTP-Status. Aus der Tabelle folgen weder ein verifizierter Meldungstext noch getestetes Geräteverhalten, Update-Zuordnung, Umbenennungs- oder Migrationsregeln.

RA und Clientverhalten prüfen

Nach dem Speichern den Pilotclient neu verbinden oder seine IPv6-Konfiguration kontrolliert erneuern. Ein Paketmitschnitt mit dem BPF-Filter icmp6 muss die Router Solicitation vom Client als ICMPv6 Type 133 und die Router Advertisement der Firewall als Type 134 zeigen. Type 135 ist eine Neighbor Solicitation und darf bei der Auswertung nicht mit RS verwechselt werden.

Danach werden die Ebenen getrennt geprüft:

1. Das RA kommt auf dem erwarteten Interface und vom erwarteten Router.
2. Präfix, On-link, Autonomous und Flags entsprechen der Planung.
3. Der Client besitzt die erwartete globale IPv6-Adresse und einen Default Gateway.
4. Falls Managed flag oder Other flag aktiv ist, liefert DHCPv6 die vorgesehenen Werte.
5. Interne und externe DNS-Namen werden über die geplanten Server aufgelöst.
6. Ein echter IPv6-Datenpfad trifft die erwartete Firewall Rule ID und der Negativtest bleibt blockiert.

Die WebAdmin-Aufnahme und die Bedeutung der Capture-Felder beschreibt Packet Capture im Sophos Firewall WebAdmin. Für die allgemeine IPv6-Regel-, Routing- und VPN-Matrix bleibt Sophos Firewall IPv6 Support und Grenzen in SFOS 22 relevant.

Fehler systematisch eingrenzen

Der Client sendet RS, aber die Firewall antwortet nicht

Interface, IPv6-Adresse, RA-Status und bestehende automatische Prefix-Delegation-Konfiguration prüfen. Danach radvd.log mit dem Testzeitpunkt korrelieren. Ein Dienstneustart ist kein erster Diagnoseschritt; Konfiguration, Capture und Log sollen den fehlenden Antwortpfad zuerst belegen.

RA kommt an, aber der Client erhält keine globale Adresse

Das angekündigte /64, Autonomous und das tatsächlich empfangene RA vergleichen. Ist Managed flag aktiv, zusätzlich die DHCPv6-Kommunikation über UDP 546 und 547 prüfen. Eine sichtbare RA allein beweist keine vollständige Adresszuweisung.

Der Client hat eine Adresse, aber keinen Default Gateway

Prüfen, ob Default gateway aktiv ist und welche Router-Lifetime im RA ankommt. DHCPv6 kann diese fehlende Default Route nicht ersetzen. Sind mehrere Router Advertisements sichtbar, anhand der Quelladresse und des eingehenden Interfaces jede Quelle zuordnen. Allowed RA servers unter Network > Interfaces > [Interface bearbeiten] > Advanced settings beschränkt nur, von welchen RA-Servern die Firewall selbst eine stateless Konfiguration annimmt; das Feld filtert keine RA-Nachrichten für andere Clients im Layer-2-Segment.

Adresse und Gateway stimmen, aber DNS fehlt

Bei Other flag oder einem DHCPv6-Modell muss der DHCPv6-Server die vorgesehenen DNS-Werte tatsächlich liefern. Danach Clientanforderung, Serverantwort und lokale Resolverkonfiguration vergleichen. Das reine Setzen des Flags erzeugt keinen DNS-Server.

IPv6 funktioniert nur teilweise

Zuerst Route und Rückweg, danach IPv6-Firewall-Regel und Rule ID prüfen. Bei grossen Paketen zusätzlich die tatsächlich angekündigte Link MTU mit Paketmitschnitt und Anwendungstest vergleichen. IPv4-Erfolg ist kein Nachweis für den getrennten IPv6-Datenpfad.

Prefix Delegation hat ein anderes Präfix erzeugt

Das Präfix einer automatisch durch Prefix Delegation erzeugten RA-Konfiguration lässt sich nicht manuell ersetzen. Providerpräfix, delegiertes Interface und vorhandenen RA-Eintrag zusammen prüfen. Ein zusätzliches Präfix benötigt einen eigenen RA-Server und einen vollständig funktionierenden Routingpfad.

Die Dienste und Logdateien, einschliesslich radvd.log, sind unter Sophos Firewall Services und Logs per CLI prüfen eingeordnet.

Änderung zurücknehmen

Für einen zustandserhaltenden Rückweg vor der Änderung Interface, Status, Intervalle, Flags, Default-Gateway-Zeit, alle Prefix-Optionen, Lifetimes und Advanced Settings erfassen. Einen bestehenden funktionierenden RA-Eintrag nicht vorsorglich löschen.

War die bisherige RA-Quelle während des Tests aktiv, wird beim Rollback nur der neue manuelle Eintrag deaktiviert oder entfernt. Wurde die bisherige Quelle ersetzt, wird sie zuerst mit den dokumentierten Werten wiederhergestellt und erst danach der neue Eintrag deaktiviert, damit kein Zeitraum ohne vorgesehenen Router entsteht. Eine automatisch durch Prefix Delegation erzeugte Konfiguration nicht wie einen unabhängigen manuellen Eintrag behandeln; hier die dokumentierte Interface- und Delegationseinstellung auf den Vorzustand setzen.

Anschliessend den Client neu verbinden und erneut RA-Quelle, Adresse, Default Gateway, DNS und einen echten IPv6-Datenpfad kontrollieren. Bereits empfangene Adressen und Routen können bis zum Ablauf ihrer angekündigten Lifetimes sichtbar bleiben; deshalb alte und neue RA-Quellen nicht unkontrolliert parallel aktiv lassen und nicht nur die vorhandenen Clientwerte prüfen.

Häufige Fragen