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.
Aktuelle Sophos-Firewall-Versionen unterstützen DHCP-Optionen direkt im WebAdmin. Für die meisten Umgebungen ist deshalb keine SSH- oder CLI-Konfiguration mehr nötig. Die CLI-Beispiele bleiben trotzdem wichtig, weil ältere Runbooks, Spezialfälle und Troubleshooting oft noch genau diese Syntax verwenden.
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-ofoder 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. Dieser wird im WebAdmin unter Network > DHCP erstellt oder 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
Sobald der DHCPv4-Server erstellt ist, können die Optionen direkt im gleichen Dialog ergänzt werden.
Network > DHCPöffnen.- Den bestehenden DHCPv4-Server bearbeiten oder einen neuen Server anlegen.
- Zum Abschnitt
DHCP optionswechseln. - Option hinzufügen.
Option,Code,TypeundValueerfassen.- Änderungen speichern.
- Mit einem Testclient prüfen, ob die Option wirklich übernommen wird.
Die Felder bedeuten:
Option: Name der Option. Bei vordefinierten Optionen kann man sie auswählen, bei eigenen Optionen wird ein sinnvoller Name verwendet.Code: Numerischer DHCP-Optioncode, zum Beispiel66,67,161oder ein herstellerspezifischer Wert.Type: Datentyp des Werts, zum Beispielipaddress,string,boolean,one-byte,two-byte,four-byteoderarray-of.Value: Der konkrete Wert, den der Client erhalten soll, zum Beispiel eine IP-Adresse, ein Hostname, ein Pfad oder ein Port.
Die korrekten Werte liefert in der Regel der Hersteller des Zielsystems. Vor allem bei String-Werten, Pfadangaben oder Vendor-spezifischen Optionen lohnt sich ein Gegencheck in der Herstellerdokumentation. Ein formal gespeicherter Wert bedeutet noch nicht automatisch, dass der Client ihn auch so interpretiert, wie man es erwartet.
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:
66verweist auf den TFTP- oder Deployment-Server.67enthä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.
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:
161für den Server192fü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.
Ä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. Wann DHCP Relay statt DHCP Server relevant ist
Sophos Firewall kann nicht nur selbst DHCP-Server sein, sondern auch DHCP Relay verwenden. Dabei werden DHCP-Anfragen von Clients an einen DHCP-Server in einem anderen Netz weitergeleitet.
Das ist vor allem dann relevant, wenn IP-Adressen zentral von einem Windows-DHCP-Server oder einem anderen dedizierten DHCP-System vergeben werden. In solchen Designs werden DHCP-Optionen normalerweise auf diesem zentralen DHCP-Server gepflegt, nicht auf der Sophos Firewall.
Bei VPN-, XFRM-, RED- oder Aussenstellen-Designs sollte man deshalb zuerst prüfen:
- Soll die Sophos Firewall selbst Leases verteilen?
- Soll sie nur DHCP-Anfragen weiterleiten?
- Befindet sich der Client in einem direkt angeschlossenen Netz?
- Gibt es mehrere DHCP-Server, die versehentlich für denselben Client antworten könnten?
Wenn der falsche DHCP-Server antwortet, hilft auch die korrekteste DHCP-Option auf der Sophos Firewall nicht.
5. Wann die CLI noch sinnvoll ist
Für aktuelle Standardkonfigurationen reicht das WebAdmin normalerweise aus. Die CLI ist eher noch sinnvoll, 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 gehen muss, sollte zuerst die Anleitung SSH mit der Sophos Firewall verbinden prüfen. Nach dem Login wird für die folgenden Befehle die 4. Device Console verwendet.

CLI-Grundprinzip: Option definieren und binden
Bei der CLI-Konfiguration gibt es zwei Schritte:
- Die DHCP-Option wird definiert.
- 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-Optioncodeoptionname: frei gewählter Name der Optionoptiontype: Datentyp, zum Beispielipaddressoderstring
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-Konfigurationoptionname(234): Name der zuvor definierten Option inklusive Optioncode in Klammernvalue: 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 folgenden Beispiele sind weiterhin nützliche Vorlagen, wenn eine Option per Device Console gesetzt oder ein altes Runbook nachvollzogen werden muss. Falsch sind diese Befehle nicht, sie sind in aktuellen Standardumgebungen nur nicht mehr der erste Weg.
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
Bindings eines DHCP-Servers anzeigen:
system dhcp dhcp-options binding show dhcpname DHCP_Server_Avanet_LAN
Eine Option kann bei Bedarf wieder gelöscht werden:
system dhcp dhcp-options delete optionname dhcp_magic_ip(234)
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:
- Testclient im richtigen VLAN oder Interface anschliessen.
- Alte Lease erneuern oder Client neu starten.
- Prüfen, welche DHCP-Adresse, Gateway, DNS-Server und zusätzlichen Optionen angekommen sind.
- Zielsystem testen, zum Beispiel PXE-Boot, WDS-Start, Thin-Client-Registrierung oder Telefon-Provisioning.
- Im WebAdmin prüfen, ob die Lease im erwarteten DHCP-Scope erscheint.
- 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 listund 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
Muss man DHCP-Optionen auf der Sophos Firewall per CLI konfigurieren?
Warum kommt eine DHCP-Option beim Client nicht an?
Wo werden DHCP-Optionen konfiguriert, wenn Sophos Firewall nur DHCP Relay nutzt?
Welche DHCP-Optionen braucht PXE oder WDS?
66 für den TFTP- oder Deployment-Server und Option 67 für den Bootfile-Namen verwendet. Der richtige Wert hängt aber von WDS, TFTP, BIOS/UEFI und Client-Architektur ab.