Zum Inhalt springen
Avanet

DHCPv6-Server auf Sophos Firewall einrichten und testen

Ein DHCPv6-Server auf der Sophos Firewall verteilt IPv6-Adressen und Netzwerkparameter an Clients. Die Konfiguration beginnt unter Network > DHCP > Add > IPv6. Anders als bei DHCPv4 reicht der Server allein jedoch nicht für ein vollständiges Clientnetz: Das IPv6 Default Gateway lernen Clients über Router Advertisement auf Sophos Firewall, nicht über DHCPv6.

Kurzablauf: IPv6-Präfix und Router Advertisement zuerst prüfen, danach Interface und dynamischen Lease-Bereich im selben /64 wählen, Preferred time kleiner als Valid time setzen, DNS bewusst festlegen und mit einem echten Client testen. Eine statische Zuordnung verwendet den DUID des Clients und nicht einfach dessen MAC-Adresse.

⚠️ Sophos Firewall kann DHCPv6-Server und DHCPv6-Relay nicht gleichzeitig betreiben. Vor der Aktivierung muss klar sein, welcher Dienst die Umgebung versorgt. Ein vorhandenes IPv6-Präfix oder eine sichtbare Lease beweist ausserdem weder ein Default Gateway noch funktionierendes DNS oder erlaubten Nutztraffic.

Router Advertisement und DHCPv6 trennen

Bei IPv4 liefert DHCP normalerweise Adresse, Subnetzmaske und Default Gateway zusammen. IPv6 trennt diese Aufgaben. Router Advertisement, kurz RA, kündigt das Präfix und den Router an. DHCPv6 kann eine Adresse aus einem verwalteten Bereich sowie DNS-Server und weitere Optionen liefern.

Für den Betrieb müssen deshalb drei Ebenen zusammenpassen:

  • Das Interface besitzt das vorgesehene IPv6-Präfix.
  • Router Advertisement signalisiert das geplante Clientverhalten und liefert den Default-Router.
  • DHCPv6 verteilt den passenden Lease-Bereich und die benötigten Zusatzwerte.

Soll der Provider ein dynamisches Präfix an die Firewall delegieren, beginnt die Planung bei IPv6 Prefix Delegation auf Sophos Firewall. Die allgemeinen Produktgrenzen für Interfaces, Routing, VPN, Regeln und DNS stehen unter Sophos Firewall IPv6 Support in SFOS 22.

Beispielnetz planen

Das folgende Labornetz verwendet den für Dokumentation reservierten IPv6-Bereich 2001:db8::/32. Diese Werte funktionieren nicht als produktive Internetadressen und werden durch das tatsächliche statische oder delegierte Präfix ersetzt:

  • Client-Interface: VLAN20 - 2001:db8:20::1/64
  • Dynamischer Bereich: 2001:db8:20::100 bis 2001:db8:20::1ff
  • Statische Zuordnung: 2001:db8:20::20
  • Interner DNS-Server: 2001:db8:10::53
  • Beispielname: dhcpv6-vlan20-clients

Das Interface und der dynamische Bereich liegen im selben /64. Bestehende statische Adressen für Firewall, Server und Infrastruktur dürfen nicht in den dynamischen Bereich fallen. Vor der Aktivierung werden vorhandene Router Advertisements, DHCPv6-Server und Relay-Agenten im Segment erfasst, damit Clients keine widersprüchlichen Informationen erhalten.

DHCPv6-Server konfigurieren

  1. Unter Network > DHCP auf Add und danach auf IPv6 klicken.
  2. Als Name dhcpv6-vlan20-clients eintragen.
  3. Unter Interface VLAN20 - 2001:db8:20::1 wählen.
  4. Accept client request via relay für direkt angeschlossene Clients deaktiviert lassen.
  5. Unter Dynamic IP lease den Bereich 2001:db8:20::100 bis 2001:db8:20::1ff hinzufügen.
  6. Preferred time und Valid time passend zum Präfix- und Client-Lifecycle setzen.
  7. Als DNS server den geplanten internen DNS-Server eintragen oder bewusst Use device’s DNS settings wählen.
  8. Nur benötigte DHCP options und statische DUID-Zuordnungen ergänzen.
  9. Mit Save speichern.

Der gewählte Lease-Bereich muss zum Client-Subnetz passen. Bei Clients hinter einem Relay gehört der Bereich zum Subnetz des Relay-Interfaces. Accept client request via relay wird nur aktiviert, wenn der Server tatsächlich Anfragen eines geprüften DHCPv6-Relay-Agenten annimmt.

Bei einem DHCPv6-Server auf einem physischen Interface mit delegiertem IPv6-Präfix zeigt die DHCPv6-Konfigurationsdatei laut Sophos keine Änderung, wenn Accept client request via relay gewählt wird. Diesen Spezialfall nicht anhand der Datei allein bewerten; Topologie, Relay-Pfad, Lease und Paketfluss müssen zusammenpassen.

Preferred time und Valid time verstehen

Preferred time gibt in Minuten an, wie lange eine Adresse bevorzugt für neue Verbindungen verwendet wird. Danach wird sie als deprecated behandelt. Bestehende Verbindungen können sie noch verwenden, neue Verbindungen sollen jedoch eine weiterhin bevorzugte Adresse wählen.

Valid time bestimmt, wie lange die Adresse insgesamt gültig bleibt. Danach darf der Client sie nicht weiter verwenden. SFOS verlangt deshalb, dass Preferred time kleiner als Valid time ist.

Es gibt keinen universellen Idealwert. Bei dynamisch delegierten Providerpräfixen dürfen die DHCPv6-Zeiten nicht so geplant werden, als bliebe das Präfix garantiert dauerhaft gleich. In stabilen internen Netzen können längere Zeiten sinnvoll sein; bei Migrationen oder häufig wechselnden Präfixen braucht es kürzere, aber weiterhin betrieblich realistische Werte und einen kontrollierten Erneuerungstest.

DNS bewusst verteilen

Mit Use device’s DNS settings gibt die Firewall ihre konfigurierten DNS-Server an die Clients weiter. Das passt nur, wenn diese Server interne und externe Namen für das Clientnetz korrekt auflösen können. Alternativ werden die tatsächlichen IPv6-Adressen der vorgesehenen DNS-Server eingetragen.

Eine erfolgreiche Lease ohne funktionierende Namensauflösung ist kein DHCPv6-Gesamterfolg. Nach der Adressprüfung folgen deshalb ein interner und ein externer DNS-Test. Für interne Zonen und Split DNS bleibt DNS Request Routes auf Sophos Firewall konfigurieren relevant.

Eigene DHCPv6-Optionen an der Device Console verwalten

Die Device Console verwaltet eine eigene DHCPv6-Option in zwei Schritten. Zuerst wird die Option global definiert, danach wird sie an einen namentlich ausgewählten DHCPv6-Server gebunden. Vor einer Änderung zeigen diese Befehle den vorhandenen Bestand und die Bindungen des Zielservers:

system dhcpv6 dhcpv6-options list
system dhcpv6 dhcpv6-options binding show dhcpname <DHCPv6-Servername>

Die SFOS-22-Hilfe erlaubt für optioncode syntaktisch Werte von 1 bis 65535. Das bedeutet nicht, dass jeder Code auf SFOS unterstützt wird oder vom Client ausgewertet werden kann. Die zugehörige Sophos-Tabelle nennt die Codes 21, 22, 24 und 27 bis 34. Vor dem Anlegen werden deshalb Optionscode, Datentyp, RFC und Clientunterstützung gemeinsam geprüft.

⚠️ Die Onlinehilfe zeigt die Befehlsgrammatik nur verkürzt und erklärt die für das Anlegen benötigten Werte und Datentypen nicht vollständig. An der betroffenen Firewall wird daher mit der Tab-Vervollständigung nach system dhcpv6 dhcpv6-options add und system dhcpv6 dhcpv6-options binding add gearbeitet. Ein Befehl aus einem anderen SFOS-Build wird nicht blind übernommen.

Nach dem Binden folgt erneut binding show, danach erneuert ein Testclient seine Lease. Der Paketmitschnitt muss die erwartete Option mit dem korrekten Wert in der Serverantwort zeigen. Für einen Rollback wird zuerst die Bindung gelöst und erst danach eine nicht mehr verwendete globale Definition gelöscht. Da die von Sophos veröffentlichte Löschsyntax für eine Bindung nur dhcpname nennt, wird sie als Aktion auf Serverebene behandelt und nie ohne vorherige Bestandsaufnahme ausgeführt.

Statische DUID-Zuordnung anlegen

DHCPv6 identifiziert einen Client über dessen DHCP Unique Identifier, kurz DUID. Unter Static IP DUID mapping wird deshalb die IPv6-Adresse dem tatsächlichen DUID des Clients zugeordnet. Eine aus dem Chassis abgelesene MAC-Adresse ist kein verlässlicher Ersatz.

Zuerst lässt man den Testclient eine dynamische Lease beziehen und ermittelt den verwendeten DUID aus Client, Lease-Anzeige oder Paketmitschnitt. Danach wird die statische Adresse 2001:db8:20::20 ausserhalb des dynamischen Bereichs eingetragen. Nach einer erneuten Lease-Anfrage muss genau dieser Client die vorgesehene Adresse erhalten.

Bei einem Betriebssystemwechsel, einem neu erzeugten DUID oder einem aus einem Template geklonten System kann die Zuordnung nicht mehr zum Client passen. Dann wird nicht die Firewall-Regel aufgeweitet, sondern zuerst der tatsächlich gesendete DUID geprüft.

Lease und Datenpfad testen

Nach dem Speichern verbindet man einen kontrollierten Client im vorgesehenen VLAN neu oder erneuert dessen IPv6-Konfiguration. Unter Network > DHCP > IPv6 lease muss die erwartete Adresse mit dem passenden Client erscheinen.

Danach werden die Ebenen getrennt geprüft:

  1. Der Client erhält eine Adresse aus dem geplanten Bereich oder die statische DUID-Adresse.
  2. Der Client besitzt ein IPv6 Default Gateway aus Router Advertisement.
  3. Die vorgesehenen DNS-Server sind sichtbar und lösen interne sowie externe Namen auf.
  4. Der Client erreicht die Firewall-Adresse und ein bewusst gewähltes IPv6-Testziel.
  5. Log Viewer zeigt für den Nutztraffic die erwartete IPv6-Firewall-Regel.
  6. Ein Negativtest bestätigt, dass nicht erlaubte IPv6-Dienste weiterhin blockiert sind.

Eine IPv4-Regel erlaubt nicht automatisch IPv6. Die benötigten zonenbasierten Regeln werden daher separat geplant und mit Rule ID sowie echtem Traffic abgenommen. Der Ablauf ist unter Sophos Firewall-Regeln konfigurieren beschrieben.

Keine Lease oder unvollständige IPv6-Konfiguration

Der Client erhält keine DHCPv6-Adresse

Zuerst werden Interface-Präfix, DHCPv6-Serverstatus und dynamischer Bereich verglichen. Danach prüft man, ob der Client in diesem Betriebsmodus überhaupt eine verwaltete DHCPv6-Adresse anfordert und ob im Segment ein anderer Server oder Relay aktiv ist.

Ein Paketmitschnitt mit diesem BPF-Filter zeigt Client- und Servernachrichten über UDP 546 und 547:

udp port 546 or udp port 547

Sind Clientnachrichten sichtbar, aber keine Antwort, folgen Serverkonfiguration und dhcpd6.log. Ist gar keine Clientnachricht sichtbar, liegen RA-Modus, Clientverhalten, VLAN oder der lokale Netzwerkpfad näher. Die Capture-Felder erklärt Packet Capture im Sophos Firewall WebAdmin.

Der Client hat eine Adresse, aber kein Default Gateway

DHCPv6 verteilt kein Default Gateway. Dieser Fehler führt deshalb direkt zu Router Advertisement, Interface und Clientsegment. Einen zweiten DHCPv6-Server anzulegen oder Lease-Zeiten zu ändern löst die fehlende Routerinformation nicht.

DNS oder Optionen fehlen

Zuerst wird geprüft, was der Client in seiner DHCPv6-Anfrage anfordert und was die Firewall tatsächlich antwortet. Danach folgen Datentyp, Wert und verwendeter DHCPv6-Server. Ein Eintrag unter DHCP-Optionen auf Sophos Firewall darf nicht blind von DHCPv4 auf DHCPv6 übertragen werden; Optionscode, RFC und Clientunterstützung müssen für DHCPv6 passen.

Statische Adresse wird nicht zugeteilt

Der gesendete DUID wird mit Static IP DUID mapping verglichen. Stimmt er nicht, kann die Firewall die Zuordnung nicht anwenden. Stimmt er, werden Adressbereich, doppelte Server und die neue Lease-Anfrage geprüft.

Relay und Server kollidieren

DHCPv6-Server und DHCPv6-Relay können auf Sophos Firewall nicht gleichzeitig aktiv sein. Ist ein zentraler externer Server vorgesehen, wird der lokale DHCPv6-Server deshalb nicht parallel als vermeintlicher Fallback betrieben. Den Relay-Pfad erklärt DHCP Relay auf Sophos Firewall einrichten.

Die Logdatei dhcpd6.log und weitere Netzwerklogs sind unter Sophos Firewall Services und Logs per CLI prüfen eingeordnet. Ein einzelner Logeintrag ersetzt weder Lease-Anzeige noch Capture und Clienttest.

Änderung zurücknehmen

Vor der produktiven Aktivierung werden bisheriger RA-Zustand, DHCPv6-/Relay-Rolle und vorhandene Clientkonfiguration dokumentiert. Beim Rollback wird der neue DHCPv6-Server deaktiviert oder entfernt, die vorherige Relay- beziehungsweise Adressierungslogik wiederhergestellt und eine neue Clientverbindung aufgebaut.

Danach werden Adresse, Default Gateway, DNS und ein echter IPv6-Datenpfad erneut geprüft. Alte und neue Server sollten nicht unkontrolliert parallel bleiben, nur um einen Rollback scheinbar einfacher zu machen.

Häufige Fragen

Ersetzt DHCPv6 das Router Advertisement?

Nein. Das Default Gateway kommt bei IPv6 über Router Advertisement. DHCPv6 kann Adressen und zusätzliche Parameter bereitstellen, ersetzt RA aber nicht.

Warum verwendet eine statische DHCPv6-Zuordnung einen DUID?

DHCPv6 identifiziert den Client über den DHCP Unique Identifier. Deshalb muss die Zuordnung zum tatsächlich gesendeten DUID passen und kann nicht zuverlässig nur aus einer MAC-Adresse abgeleitet werden.