Sophos Firewall DHCP Options (SFOS)

DHCP-Optionen werden auf der Sophos Firewall benötigt, wenn Clients beim Start mehr als IP-Adresse, Gateway und DNS erhalten sollen. Typische Fälle sind PXE, WDS, Thin Clients, VoIP-Telefone oder ältere RED-Umgebungen, bei denen ein bestimmter Optioncode und Datentyp exakt passen muss.

SFOS 22 unterstützt vordefinierte und eigene DHCP-Optionen direkt im WebAdmin. Das ist der verifizierte Standardweg. Ältere Runbooks enthalten oft noch ausführlichere Device-Console-Syntax; sie ist weiter unten bewusst als Migrationsreferenz gekennzeichnet und nicht als ungeprüfte Copy-and-paste-Anleitung für SFOS 22.

Was DHCP-Optionen sind

DHCP verteilt nicht nur eine IP-Adresse. Zusammen mit der Lease kann der DHCP-Server zusätzliche Informationen an den Client übergeben. Genau dafür gibt es DHCP-Optionen. Typische Beispiele sind DNS-Server, Gateway, TFTP-Server, Bootfile-Name, Vendor-spezifische Parameter oder Werte für Thin Clients und Telefone.

Auf der Sophos Firewall gehören DHCP-Optionen immer zum DHCP-Server beziehungsweise zum Scope, der die Lease ausstellt. Das ist wichtig: Wenn ein Client seine Adresse von einem anderen DHCP-Server erhält, muss die Option dort konfiguriert werden. Wenn die Sophos Firewall nur als DHCP Relay arbeitet, leitet sie DHCP-Anfragen weiter, ist aber nicht die Stelle, an der die Option für diesen Scope gepflegt wird.

Für IPv6 ist DHCP nicht immer gleich zu behandeln wie bei IPv4. Wenn ein Provider ein IPv6-Präfix delegiert, gehören Router Advertisement, DHCPv6-Parameter und Firewall Regeln zusammen. Der Ablauf ist in IPv6 Prefix Delegation auf Sophos Firewall konfigurieren beschrieben.

In der Praxis sollte man vor der Konfiguration drei Dinge klären:

• Welcher DHCP-Server verteilt die Lease wirklich?
• In welchem Scope oder auf welchem Interface befindet sich der Client?
• Welche Optioncodes, Datentypen und Werte verlangt der Hersteller des Zielsystems?

Voraussetzungen

• Sophos Firewall mit aktiviertem DHCPv4-Server
• Zugriff auf Network > DHCP
• Ein DHCP-Scope auf dem passenden Interface
• Die benötigten DHCP-Optioncodes und Werte des Herstellers oder Zielsystems
• Für CLI-Fallbacks: erlaubter SSH-Zugriff auf die Sophos Firewall

Vor der Änderung sollte man den betroffenen Scope kurz prüfen. DHCP-Optionen wirken nur dann zuverlässig, wenn sie am richtigen DHCP-Server, im richtigen Netz und mit dem richtigen Datentyp gesetzt werden.

• DHCP-Server: Die Sophos Firewall muss die Lease selbst ausstellen. Bei DHCP Relay gehören die Optionen normalerweise auf den zentralen DHCP-Server.
• Scope und Interface: Ein Client im falschen VLAN oder an einem anderen Interface sieht die Option nicht, auch wenn sie korrekt gespeichert ist.
• Optioncode und Datentyp: Viele Fehler entstehen, weil ein Client string, ipaddress, array-of oder einen Vendor-Wert anders erwartet als eingetragen.
• Testclient: Ein bekanntes Gerät im betroffenen Netz macht sichtbar, ob die Option wirklich im DHCP Offer oder ACK ankommt.
• Änderungsfenster: PXE, Telefone und Thin Clients können beim Lease-Wechsel sofort betroffen sein. Änderungen sollten deshalb kontrolliert getestet werden.

Wenn die Option für produktive Geräte relevant ist, sollte vorab klar sein, wie man sie wieder entfernt oder auf den alten Wert zurücksetzt. Das gilt besonders für Boot-Optionen, Provisioning-Server und herstellerspezifische Vendor-Optionen.

1. DHCP-Server erstellen oder prüfen

Damit DHCP-Optionen verteilt werden können, benötigt man zuerst einen DHCPv4-Server auf der Sophos Firewall. Die vollständige Grundkonfiguration mit Bereich, Gateway, DNS, Lease-Zeit und Test ist unter Sophos Firewall als DHCP-Server einrichten beschrieben. Anschliessend wird der Server unter Network > DHCP bearbeitet.

Wichtig ist vor allem:

• Der DHCP-Server ist einem Interface zugeordnet.
• Der Scope passt zum Netz, in dem die Clients stehen.
• DNS-Server, Gateway und Lease-Time sind sauber gesetzt.
• Der DHCP-Name enthält keine unnötigen Leerzeichen oder Sonderzeichen.
• PXE-, VoIP-, Thin-Client- oder RED-Sonderfälle sind vorab dokumentiert.

Gerade der DHCP-Name ist bei CLI-Befehlen relevant. Wenn der Name Leerzeichen oder Sonderzeichen enthält, werden spätere Befehle und Runbooks unnötig fehleranfällig. Verständliche Namen wie DHCP_Server_Avanet_LAN, Home_Scope oder DHCP_VoIP sind in der Praxis einfacher.

2. DHCP-Optionen im WebAdmin konfigurieren

Der vollständige SFOS-22-Pfad für einen neuen Scope lautet Network > DHCP > Server > Add. Bei einem vorhandenen Scope öffnet man dort dessen Bearbeitungsaktion. Erst danach folgt der Abschnitt DHCP options.

1. Network > DHCP öffnen und unter Server den richtigen DHCPv4-Server bearbeiten.
2. Vorhandene Zeilen unter DHCP options mit Option, Code, Typ und Wert dokumentieren. Das ist die Ausgangskonfiguration für den Rückweg.
3. Eine vordefinierte Option aus der Liste wählen oder eine Custom-Option hinzufügen.
4. Für eine Custom-Option die Felder Code, Type und Value ausfüllen.
5. Save wählen.
6. Die Lease eines kontrollierten Testclients erneuern und die ausgelieferte Option prüfen.

SFOS 22 unterscheidet dabei:

• Predefined options: Auswahl aus den von SFOS angebotenen DHCP-Optionen samt Standardwerten. Die offizielle Zuordnung nennt zum Beispiel String, IP address, Boolean, One-byte numeric value, Two-byte numeric value, Four-byte numeric value und verschiedene Arrays als Datentypen.
• Code: Nummer der Custom- oder Vendor-Option. Sie muss aus der aktuellen Dokumentation des Clientherstellers beziehungsweise aus dem IANA-Register stammen.
• Type: Datentyp für den Inhalt von Value. Nicht nur der sichtbare Wert, sondern auch seine Kodierung muss zur Client-Spezifikation passen.
• Value: Der tatsächlich ausgelieferte Wert, etwa eine IP-Adresse, ein FQDN, ein Pfad oder eine herstellerspezifische Zeichenkette.

Die korrekten Werte liefert in der Regel der Hersteller des Zielsystems. Ein Wert, den SFOS ohne Fehlermeldung speichert, ist noch kein Nachweis dafür, dass der Client Code, Typ und Inhalt wie beabsichtigt interpretiert.

Für die Referenzprüfung trennt die SFOS-23-Hilfe DHCPv4 in Appendix A und DHCPv6 in Appendix B. Beide Tabellen unterscheiden Data type, Data format und Data value (example) und nennen die zugehörige RFC. Der Datentyp allein genügt deshalb nicht: Auch das Format des Werts muss zur jeweiligen Option passen. Die Beispielwerte sind keine Vorgaben für das eigene Netz. DHCPv4-Optioncodes und Werte werden nicht unverändert für DHCPv6 übernommen; dafür wird die passende DHCPv6-Zuordnung geprüft. Die erweiterten Referenztabellen sind kein Nachweis, dass eine Option erst mit SFOS 23 eingeführt wurde.

Änderung und Rückweg vorbereiten

Eine Änderung sollte zuerst nur an einem kontrollierten Scope erfolgen. Vor Save hält man jede betroffene Optionszeile und den alten Wert fest. Schlägt der Test fehl, öffnet man denselben DHCPv4-Server erneut, entfernt nur die neu hinzugefügte Zeile beziehungsweise stellt den dokumentierten alten Wert wieder her und speichert. Danach wird die Lease des Testclients erneut erneuert und im DHCP Offer oder ACK geprüft, ob wieder der Ausgangszustand ausgeliefert wird.

Eine globale Optionsdefinition sollte nicht vorschnell per CLI gelöscht werden: Sie kann noch an einen anderen DHCP-Server gebunden sein. Für den sicheren Rückweg genügt normalerweise die Änderung im betroffenen Scope.

3. Typische Anwendungsfälle

DHCP-Optionen werden meistens dann benötigt, wenn ein Client beim Start zusätzliche Informationen braucht. Häufige Fälle sind PXE, WDS, Thin Clients, VoIP-Telefone, Access Points oder einzelne Legacy-Szenarien.

PXE und WDS

Für PXE- oder WDS-Umgebungen werden häufig die Optionen 66 und 67 verwendet:

• 66 verweist auf den TFTP- oder Deployment-Server.
• 67 enthält den Bootfile-Namen.

Wenn der Client den Server erreicht, aber nicht bootet, liegt das Problem oft nicht bei der Firewall, sondern an einem falschen Dateipfad, einem ungeeigneten Datentyp oder einer unpassenden Architekturdatei. Bei UEFI- und BIOS-Clients werden häufig unterschiedliche Bootfiles benötigt.

Wichtig bei aktuellen SFOS-Versionen: Next-server und Boot file sind im DHCPv4-Server eigene Boot-Option-Felder. Seit SFOS 20.0 MR1 werden sie nicht mehr automatisch nur als DHCP-Option 66 und 67 behandelt. Wenn ein Gerät ausdrücklich Option 66 oder 67 erwartet, sollte man diese Werte bewusst unter DHCP options pflegen und nicht nur die Boot-Option-Felder ausfüllen.

Bei Upgrades auf SFOS 20.0 MR1 oder neuer bleiben bestehende Next-server- und Boot file-Werte als Boot Options und zusätzlich als DHCP-Optionen 66 und 67 erhalten. Nach einer Migration sollte man deshalb prüfen, ob Werte doppelt vorhanden sind und ob der Client die erwartete Variante auswertet.

Im Feld Next-server akzeptiert SFOS eine IP-Adresse oder einen FQDN, aber keine URL. Boot file benötigt den vollständigen Pfad samt Dateiname. Beide Werte müssen zum tatsächlich eingesetzten Boot-Server und zur Client-Architektur passen.

Thin Clients

Thin Clients benötigen je nach Hersteller Optionen für Management-Server, Image-Server oder Verbindungsparameter. In alten Runbooks findet man dafür zum Beispiel:

• 161 für den Server
• 192 für einen Port oder Zusatzparameter

Ob diese Codes korrekt sind, hängt vom Hersteller und vom verwendeten Thin-Client-Modell ab. Deshalb sollte man die Codes nicht blind übernehmen, sondern immer gegen die Herstellerdokumentation prüfen.

Avaya IP-Telefone als konkretes Herstellerbeispiel

Die SFOS-22-Hilfe zeigt für Avaya-Telefone die Optionen 176 und 252 als String. Die dort verwendeten IP-Adressen und der Port sind reine Dokumentationswerte und müssen durch die tatsächlichen Kommunikations-, TFTP- und HTTP-Server der Umgebung ersetzt werden:

Option 176, String: MCIPADD=192.168.30.99,MCPORT=1719,TFTPSRVR=192.168.30.201
Option 252, String: ConfigHttpSrvr=192.168.30.102

Nach dem Erneuern der Lease prüft man im DHCP Offer oder ACK, ob der Client genau diese Strings erhält. Danach müssen Telefon- und Serverlogs bestätigen, dass das Gerät die vorgesehenen Dienste tatsächlich verwendet. Das Beispiel ist keine universelle Avaya-Konfiguration.

Ältere RED-Sonderfälle

In älteren Umgebungen gab es Fälle, in denen bei einer Sophos RED 15w der integrierte Access Point nicht korrekt erkannt wurde. Dafür wurde teilweise eine herstellerspezifische DHCP-Option verwendet, zum Beispiel mit Optioncode 234 und einem Wert wie 10.10.10.12.

Das ist kein allgemeiner Standard für moderne SD-RED-Installationen. Als Legacy-Beispiel ist es aber weiterhin nützlich, weil es zeigt, wie eigene Optioncodes definiert und an einen DHCP-Server gebunden werden.

Für aktuelle RED-Designs ist der Artikel Sophos SD-RED einrichten und Fehler beheben hilfreicher. Wenn es um Interface-, VLAN-, Bridge- oder RED-Designs geht, hilft zusätzlich Sophos Firewall Zonen und Interfaces planen und konfigurieren.

4. DHCP Relay richtig einordnen

Bei DHCP Relay leitet die Sophos Firewall Client-Anfragen an einen Server in einem anderen Netz weiter. DHCP-Optionen werden deshalb auf dem Server gepflegt, der die Lease ausstellt, nicht auf der Relay-Firewall.

Interfacewahl, mehrere Server, lokale Netze sowie policy-based und route-based IPsec sind in Sophos Firewall DHCP Relay einrichten und testen mit Beispielwerten, Regeln, Befehlen und Packet Capture beschrieben.

5. CLI kontrolliert verwenden

SFOS 22 dokumentiert weiterhin beide CLI-Schritte: eine Option mit system dhcp dhcp-options add definieren und sie mit system dhcp dhcp-options binding add an einen DHCP-Server binden. Die aktuelle Device-Console-Übersicht fasst den Befehl nur verkürzt zusammen; die offizielle Avaya-Anleitung zeigt die vollständige Syntax. Der WebAdmin bleibt für neue Standardkonfigurationen übersichtlicher, während die CLI vor allem für bestehende Runbooks, Supportfälle und kontrollierte Migrationen nützlich ist.

Die Device Console kommt nur infrage, wenn:

• ein Altartikel oder älteres Runbook bereits auf CLI-Befehlen basiert
• ungewöhnliche Vendor-Optionen getestet werden müssen
• man im Supportfall exakt sehen möchte, welche Bindings intern hinterlegt sind
• eine Umgebung von einer sehr alten SFOS-Version übernommen wurde
• ein Befehl in einer Dokumentation nachgebaut oder kontrolliert werden muss

Wer diesen Weg mit einer für die installierte Version bestätigten Syntax gehen muss, sollte zuerst die Anleitung SSH mit der Sophos Firewall verbinden prüfen. Nach dem Login ist 4. Device Console die richtige Umgebung, nicht die Advanced Shell. Vor jeder Änderung werden die aktuelle UI-Konfiguration und vorhandene Bindings gesichert.

CLI-Grundprinzip: Option definieren und binden

Bei der CLI-Konfiguration gibt es zwei Schritte:

1. Die DHCP-Option wird definiert.
2. Die Option wird an einen DHCP-Server gebunden und bekommt dort einen Wert.

Zuerst wird die Option definiert:

system dhcp dhcp-options add optioncode optionname optiontype

Die Platzhalter bedeuten:

• optioncode: numerischer DHCP-Optioncode
• optionname: frei gewählter Name der Option
• optiontype: Datentyp, zum Beispiel ipaddress oder string

Beispiel für eine IP-Adresse als DHCP-Option:

system dhcp dhcp-options add optioncode 234 optionname dhcp_magic_ip optiontype ipaddress

Danach wird die Option an einen DHCP-Server gebunden:

system dhcp dhcp-options binding add dhcpname optionname(234) value

Die Platzhalter bedeuten:

• dhcpname: Name des DHCP-Servers aus der Sophos-Firewall-Konfiguration
• optionname(234): Name der zuvor definierten Option inklusive Optioncode in Klammern
• value: Wert, der an Clients verteilt werden soll

Beispiel:

system dhcp dhcp-options binding add dhcpname dhcp_red_avanet optionname dhcp_magic_ip(234) value 10.10.10.12

6. CLI-Beispiele

Die Syntax zum Definieren und Binden von Optionen ist in der aktuellen SFOS-22-Avaya-Anleitung offiziell dokumentiert. Die Thin-Client-, WDS- und RED-Werte unten sind dagegen umgebungsspezifische Beispiele: Optioncode, Datentyp und Inhalt müssen vor der Verwendung mit der aktuellen Herstellerdokumentation abgeglichen werden.

Thin Client Server

Mit dieser Option wird einem Thin Client mitgeteilt, auf welchem Server das Image oder die Management-Komponente liegt:

system dhcp dhcp-options add optioncode 161 optionname ThinClientServer optiontype ipaddress
system dhcp dhcp-options binding add dhcpname DHCP_Server_Avanet_LAN optionname ThinClientServer(161) value '10.10.10.12'

Wenn zusätzlich ein Port benötigt wird, kann dieser als String gesetzt werden:

system dhcp dhcp-options add optioncode 192 optionname ThinClientServerPort optiontype string
system dhcp dhcp-options binding add dhcpname DHCP_Server_Avanet_LAN optionname ThinClientServerPort(192) value '443'

WDS und PXE

Ein DHCP-Optionswert für den WDS- oder TFTP-Server kann so gesetzt werden:

system dhcp dhcp-options binding add dhcpname Home_Scope optionname TFTP_Server_Name(66) value 172.16.16.11

Der Bootfile-Name für das Pre-Environment wird als Option 67 mitgegeben:

system dhcp dhcp-options binding add dhcpname Home_Scope optionname Bootfile_Name(67) value \boot\x64\wdsnbp.com

Mit Pre-Environment ist die Boot-Umgebung gemeint, mit der ein Client während der Installation oder Wiederherstellung startet. Je nach Umgebung kann der benötigte Pfad abweichen, insbesondere bei UEFI, BIOS, 32-Bit- und 64-Bit-Clients.

Bestehende Optionen anzeigen

Vor Änderungen sollte man bestehende Optionen anzeigen:

system dhcp dhcp-options list

Die offizielle SFOS-22-Anleitung weist darauf hin, dass die Firewall Optionsobjekte von 1 bis 255 unterstützt, dieser CLI-Befehl aber nur die Optionen 1 bis 76 anzeigt. Für Codes, Typ und Kodierung bleiben Appendix A, das IANA-Register und die Client- beziehungsweise Herstellerdokumentation massgebend.

Bindings eines DHCP-Servers anzeigen:

system dhcp dhcp-options binding show dhcpname DHCP_Server_Avanet_LAN

Die aktuelle Befehlsübersicht kennt zwar die Aktion delete, ein globales Löschen ist aber kein sicherer Standard-Rollback: Vorher müsste geklärt werden, ob die Definition an weitere DHCP-Server gebunden ist. Für Änderungen an einem einzelnen Scope wird deshalb der dokumentierte alte Zustand im WebAdmin wiederhergestellt.

7. Typische Fehlerquellen

Wenn eine DHCP-Option gespeichert ist, aber beim Client nicht wie erwartet wirkt, liegt es oft an einem dieser Punkte:

• Falscher DHCP-Server antwortet auf die Anfrage.
• Falscher Scope oder falsches Interface wurde bearbeitet.
• Datentyp passt nicht zum erwarteten Wert.
• IP-Adresse, FQDN, Port oder Pfad ist vertippt.
• Bootfile-Pfad passt nicht zur Client-Architektur.
• Client erwartet einen String, die Option wurde aber als IP-Adresse angelegt.
• Hersteller verwendet Vendor-spezifische Optionen, die zusätzliche Parameter brauchen.
• Lease wurde nach der Änderung nicht erneuert.
• DHCP Relay wird verwendet, obwohl die Option auf der Sophos Firewall gepflegt wurde.

Nach einer Änderung sollte man die Lease am Testclient erneuern und prüfen, ob der Client die erwarteten Optionen wirklich erhält. Wenn das Verhalten weiterhin nicht passt, ist ein Paketmitschnitt oft schneller als langes Raten: In den DHCP-Paketen sieht man, welcher Server antwortet und welche Optionen tatsächlich ausgeliefert werden.

8. Änderung testen

Nach dem Speichern einer DHCP-Option sollte man nicht nur warten, bis der nächste Client irgendwann eine neue Lease holt. Besser ist ein kontrollierter Test mit einem bekannten Gerät im betroffenen Netz.

Sinnvoller Ablauf:

1. Testclient im richtigen VLAN oder Interface anschliessen.
2. Alte Lease erneuern oder Client neu starten.
3. Prüfen, welche DHCP-Adresse, Gateway, DNS-Server und zusätzlichen Optionen angekommen sind.
4. Zielsystem testen, zum Beispiel PXE-Boot, WDS-Start, Thin-Client-Registrierung oder Telefon-Provisioning.
5. Im WebAdmin prüfen, ob die Lease im erwarteten DHCP-Scope erscheint.
6. Wenn das Ergebnis nicht passt, mit Packet Capture prüfen, welcher DHCP-Server antwortet und welche Optionen im Offer oder ACK enthalten sind.

Für einen engen Mitschnitt reicht meistens ein Filter auf UDP 67 und 68 zwischen Client und DHCP-Server. Die Bedienung des WebAdmin-Werkzeugs ist in Sophos Firewall Packet Capture im WebAdmin verwenden beschrieben.

Bei PXE- und WDS-Tests sollte man zusätzlich dokumentieren, ob der Testclient BIOS oder UEFI verwendet. Viele Bootprobleme entstehen nicht durch DHCP selbst, sondern durch ein Bootfile, das nicht zur Architektur passt.

9. Troubleshooting nach Symptomen

Wenn DHCP-Optionen nicht wirken, hilft eine symptomorientierte Prüfung oft schneller als das erneute Anlegen derselben Option.

• Client erhält keine IP-Adresse: DHCP-Server, VLAN, Interface oder Relay passt nicht. Lease-Liste, Interface, VLAN und DHCP Relay prüfen.
• Client erhält IP, aber keine Option: Falscher Scope oder falscher DHCP-Server antwortet. Packet Capture auf DHCP Offer oder ACK prüfen.
• PXE findet Server, bootet aber nicht: Option 67, Dateipfad oder Architektur passt nicht. BIOS-/UEFI-Bootfile und TFTP-/WDS-Log prüfen.
• Thin Client verbindet nicht: Falscher Optioncode, Typ oder Herstellerwert. Herstellerdokumentation und gelieferten Wert vergleichen.
• Änderung wirkt erst später: Client verwendet alte Lease. Lease erneuern, Client neu starten oder Lease-Time beachten.
• CLI-Befehl funktioniert nicht: DHCP-Name, Optionname oder Klammernotation ist falsch. system dhcp dhcp-options list und Binding-Ausgabe prüfen.

Wenn im Mitschnitt ein anderer DHCP-Server antwortet, sollte zuerst das Netzdesign geklärt werden. Zwei DHCP-Server im gleichen Broadcast-Domain sind eine klassische Ursache für wechselndes Verhalten. Bei komplexeren VLAN-, Bridge- oder Interface-Fragen hilft Sophos Firewall Zonen und Interfaces planen und konfigurieren.

Häufige Fragen