Sophos Firewall als DHCP-Server einrichten

Die Sophos Firewall kann IPv4-Adressen, Gateway, DNS-Server und weitere Netzwerkeinstellungen direkt an Clients verteilen. Dazu legt man unter Network > DHCP einen Server für das Client-Interface an, definiert den Adressbereich und prüft danach, ob der Client eine passende Lease erhält.

Kurzablauf: Network > DHCP > Server > Add öffnen, Interface und Adressbereich wählen, Use interface IP as gateway aktivieren, DNS bewusst festlegen und speichern. Anschliessend unter System services > Services den Dienst DHCP server prüfen und die vergebene Adresse unter IPv4 lease kontrollieren.

Diese Anleitung behandelt einen DHCPv4-Server für Clients im direkt angeschlossenen Netz. Wenn ein zentraler DHCP-Server ein anderes Subnetz versorgen soll, passt Sophos Firewall DHCP Relay einrichten und testen. PXE, VoIP und herstellerspezifische Werte sind unter DHCP-Optionen auf Sophos Firewall konfigurieren beschrieben.

Für IPv6 gelten andere Rollen für Adressvergabe und Default Gateway. Der vollständige Ablauf steht unter DHCPv6-Server auf Sophos Firewall einrichten und testen.

Beispiel und Adressplanung

Das Beispiel verwendet ein Client-VLAN mit diesen Werten:

Interface: VLAN20 - 10.20.0.1/24
Dynamischer Bereich: 10.20.0.100 bis 10.20.0.199
Gateway: 10.20.0.1
Statische Zuordnung für einen Drucker: 10.20.0.20
Interne DNS-Server: 10.10.0.10 und 10.10.0.11
Domain Name: corp.example

Der dynamische Bereich liegt innerhalb des Interface-Netzes, enthält aber weder die Netzwerkadresse, die Broadcast-Adresse noch das Gateway. Die Adressen unterhalb von 10.20.0.100 bleiben im Beispiel für Infrastruktur und statische Zuordnungen reserviert. Damit verteilt dieser DHCP-Bereich die reservierten Adressen nicht zusätzlich dynamisch. Vor einem anderen Gerät, auf dem dieselbe IP-Adresse manuell eingetragen wurde, schützt diese Trennung jedoch nicht.

Vor dem Aktivieren sollte man prüfen, welche Adressen bereits von Switches, Access Points, Druckern oder Servern verwendet werden. Läuft im selben VLAN noch ein anderer DHCP-Server, muss zuerst geklärt werden, welcher Server künftig zuständig ist. Zwei unkoordinierte Server können unterschiedliche Gateways oder DNS-Server verteilen und führen zu wechselnden Fehlerbildern.

Das Interface selbst muss bereits die richtige statische IP-Adresse besitzen. Wie Interface, Zone und VLAN zusammenspielen, erklärt Sophos Firewall VLAN-Interface konfigurieren.

DHCP-Server konfigurieren

⚠️ In einem HA-Cluster unterstützt Sophos den DHCP-Dienst im Modus Active-passive, nicht im Modus Active-active. Diese Voraussetzung vor dem Anlegen des DHCP-Servers prüfen; ein Wechsel des HA-Modus ist kein Fehlerbehebungsschritt für einen einzelnen DHCP-Bereich.

Network > DHCP öffnen.
Unter Server auf Add klicken.
Einen eindeutigen Namen wie dhcp-vlan20-clients eintragen.
Unter Interface das Client-Interface VLAN20 - 10.20.0.1 wählen.
Unter Dynamic IP lease den Bereich 10.20.0.100 bis 10.20.0.199 hinzufügen.
Als Subnet mask 255.255.255.0 für das Beispielnetz /24 eintragen.
Use interface IP as gateway aktivieren. Dadurch erhalten die Clients 10.20.0.1 als Gateway.
DNS-Server, Domain name und Lease-Zeiten passend zum Netz festlegen.
Falls benötigt, statische MAC-IP-Zuordnungen ergänzen.
Mit Save speichern.

Bei direkt angeschlossenen Clients bestimmt das gewählte Interface, in welchem Netz die Firewall auf DHCP-Anfragen antwortet. Der dynamische Bereich muss deshalb zum Subnetz dieses Interfaces passen. DHCP-Server sind auf physischen Interfaces sowie auf VLAN-, Wireless- und Bridge-Interfaces möglich, nicht aber auf einem Interface Alias. Auf einem Interface, das bereits als DHCP Relay verwendet wird, kann nicht gleichzeitig ein DHCPv4-Server eingerichtet werden.

Für direkt angeschlossene Clients bleibt Accept client request via relay deaktiviert. Die Option wird nur benötigt, wenn diese Serverkonfiguration Anfragen aus einem entfernten Client-Subnetz über einen Relay-Agenten annehmen soll. Für jedes solche Client-Netz braucht es eine passende Serverkonfiguration mit eigenem Gateway; den vollständigen Aufbau beschreibt die verlinkte DHCP-Relay-Anleitung.

Diese Serverkonfigurationen können dasselbe DHCP-Interface verwenden, auf dem der Server die weitergeleiteten Anfragen empfängt. Das lauschende Interface ist dabei vom entfernten Client-Subnetz zu unterscheiden: Adressbereich, Subnetzmaske und Gateway jeder Konfiguration gehören zum jeweiligen Client-Netz. Der Server vergibt Adressen aus dem Subnetz der Quelladresse des Relay-Agenten; das gemeinsame lauschende Interface ersetzt deshalb keine separate Konfiguration pro Client-Netz.

Gateway und DNS richtig wählen

Für ein normales Client-Netz ist die IP-Adresse der Sophos Firewall auf diesem Interface das Gateway. Im Beispiel erhalten die Clients deshalb 10.20.0.1.

Bei Use device’s DNS settings verteilt die Firewall ihre konfigurierten DNS-Server an die Clients. Das ist passend, wenn diese Server sowohl öffentliche als auch benötigte interne Namen auflösen können. In einer AD-Umgebung trägt man in der Regel die internen DNS-Server ein, damit Domain Controller, interne Dienste und Suchdomains zuverlässig funktionieren. Öffentliche Resolver allein reichen dafür meist nicht aus.

Domain name verteilt ein DNS-Suffix an den Netzwerkadapter. Mit corp.example kann der Client beispielsweise den Hostnamen fileserver zu fileserver.corp.example ergänzen. Das ersetzt weder einen DNS-Eintrag noch einen erreichbaren DNS-Server; beides wird separat geprüft.

Erhalten die Clients die Firewall-IP als DNS-Server, kann die Sophos Firewall Anfragen für bestimmte interne Zonen an die zuständigen Server weiterleiten. Dieser Fall ist unter DNS Request Routes auf Sophos Firewall konfigurieren beschrieben. Verteilt DHCP dagegen direkt die Adressen anderer DNS-Server, erreichen die Client-Anfragen die Request Routes der Firewall nicht.

Die Felder WINS server 1 und WINS server 2 sind nur für ältere NetBIOS-Umgebungen vorgesehen. Sie bleiben leer, solange Clients oder Anwendungen keinen WINS-Dienst benötigen. Wird WINS noch eingesetzt, müssen die tatsächlichen Serveradressen eingetragen und die Namensauflösung mit einem betroffenen Client geprüft werden.

Lease-Zeiten passend setzen

Default lease time ist die regulär an den Client ausgegebene Lease-Zeit. Max lease time ist die Obergrenze; nach deren Ablauf muss der Client eine neue Anfrage an den DHCP-Server senden. Beide Werte werden in Minuten angegeben.

In stabilen Büro- oder Gerätenetzen sind längere Leases sinnvoll, weil sich der Bestand selten ändert. In Gäste-, Schulungs- oder stark wechselnden WLAN-Netzen verhindert eine kürzere Lease, dass nicht mehr verbundene Geräte den Bereich lange belegen.

Sehr kurze Leases erzeugen dagegen unnötig viele Erneuerungen. Entscheidend ist deshalb nicht ein allgemeiner Idealwert, sondern wie gross der Bereich ist und wie häufig die Clients wechseln.

Conflict detection prüft eine Adresse vor der Vergabe und hilft, bereits verwendete IP-Adressen zu erkennen. Die Funktion ist besonders nützlich, wenn noch manuell konfigurierte Geräte oder eine ältere, nicht vollständig dokumentierte Adressierung vorhanden sind.

Statische IP-MAC-Zuordnung anlegen

Eine statische Zuordnung sorgt dafür, dass ein bestimmtes Gerät immer dieselbe Adresse per DHCP erhält. Das ist für Drucker, Access Points oder andere Geräte sinnvoll, die erreichbar bleiben sollen, aber weiterhin zentral konfigurierte Werte wie Gateway und DNS beziehen sollen.

Unter Static IP MAC mapping trägt man Hostname, MAC-Adresse und die gewünschte IP-Adresse ein. Im Beispiel erhält der Drucker mit seiner tatsächlichen MAC-Adresse immer 10.20.0.20. Diese Adresse liegt bewusst ausserhalb des dynamischen Bereichs.

Eine DHCP-Zuordnung ist nicht dasselbe wie eine manuell am Gerät konfigurierte IP-Adresse: Das Gerät bleibt DHCP-Client, die Firewall reserviert jedoch die passende Lease. Verwendet ein Notebook oder Smartphone eine private beziehungsweise zufällige WLAN-MAC-Adresse, muss die Zuordnung zu der MAC-Adresse passen, die das Gerät in diesem WLAN tatsächlich verwendet.

Eine einzelne MAC-Adresse kann höchstens fünf statische IP-Adressen erhalten, sofern diese in unterschiedlichen Subnetzen liegen. Für eine normale Zuordnung in nur einem Netz braucht es keine globale Einstellung.

In SFOS 23 wird bei derselben MAC-Adresse in mehreren DHCP-Serverkonfigurationen unter Network > DHCP > Advanced server settings die Einstellung Lease scope for static binding auf Global gesetzt. Clients können damit eine Adresse von jedem auf der Firewall konfigurierten DHCP-Server beziehen, unabhängig davon, wo die statische IP-MAC-Bindung hinterlegt ist. Network begrenzt dies auf den Server mit der Bindung. Vorher den bisherigen Wert festhalten; danach jeden betroffenen Scope mit einer neuen Client-Lease prüfen. Für den Rückbau genau den zuvor festgehaltenen Wert wiederherstellen.

SFOS 22: globale Bindung über die Device Console

Bevor man die globale Zuordnung ändert, prüft man nach dem SSH-Login in der Device Console die lokale, befehlsspezifische Hilfe für conf-generation-method und static-entry-scope auf der installierten SFOS-Version. Die aktuelle Methode und den aktuellen Scope mit einer dort unterstützten lesenden Abfrage oder einer verfügbaren UI-Anzeige feststellen und festhalten; die zugehörige Rücksetzsyntax ebenfalls vorab prüfen. Eine show-Form ist hier nicht pauschal für jede Version bestätigt. Lassen sich Ausgangszustand oder Rückweg nicht zuverlässig feststellen, keine Änderung durchführen und den Zustand zuerst mit dem Support klären.

Nur Werte, die vom benötigten Zielzustand abweichen, werden anschliessend geändert:

system dhcp conf-generation-method new
system dhcp static-entry-scope global

Die Einstellung betrifft alle DHCP-Serverkonfigurationen. Sie ist für normale, einmalige Zuordnungen nicht erforderlich und sollte deshalb nur für diesen Mehrfach-Scope-Fall geändert werden.

Bei mehrfach gebundenen MAC-Adressen ist der oben gezeigte Zielzustand wichtig, damit die Clients die richtigen DHCP-Angaben wie DNS-Server und Gateway erhalten. Einen bereits passenden Zustand nicht überschreiben und keine Defaults als Ausgangszustand annehmen. Für den Rückbau genau die zuvor festgehaltenen Werte mit der für die installierte Version bestätigten Syntax wiederherstellen. Waren die Ausgangswerte tatsächlich network und old, kommen dafür system dhcp static-entry-scope network und system dhcp conf-generation-method old infrage, sofern die lokale Hilfe diese Formen bestätigt. Danach jeden betroffenen Scope mit einer neuen Client-Lease prüfen.

Dienst prüfen und Lease testen

Nach dem Speichern prüft man unter System services > Services, ob DHCP server läuft. Falls der Dienst gestoppt ist, wird er dort gestartet.

Danach verbindet man einen kontrollierten Testclient mit dem richtigen VLAN. Unter Windows kann eine neue Lease so angefordert und geprüft werden:

⚠️ ipconfig /release trennt die aktuelle IPv4-Verbindung. Den Befehl nicht über genau diese Remote-Verbindung ausführen, wenn kein alternativer Zugriff vorhanden ist.

ipconfig /release
ipconfig /renew
ipconfig /all

Der Client sollte eine Adresse aus 10.20.0.100 bis 10.20.0.199, das Gateway 10.20.0.1 und die vorgesehenen DNS-Server erhalten. Unter Network > DHCP > IPv4 lease zeigt die Firewall die vergebene Adresse mit Start- und Endzeit, MAC-Adresse und Hostname.

Für die Funktionsprüfung sollten mindestens diese Punkte stimmen:

Der Client erhält eine Adresse aus dem richtigen Bereich.
Gateway und DNS-Server entsprechen der Planung.
Das Gateway ist erreichbar.
Interne und externe Namen werden aufgelöst.
Der Client erreicht nur die Netze und Dienste, die seine Firewall-Regel erlaubt.

Keine oder eine falsche Adresse erhalten

Wenn der Client keine Lease erhält, prüft man zuerst Interface, VLAN und Dienststatus. Danach sind diese Fehler besonders häufig:

Falsches Interface: Der DHCP-Server ist nicht dem Interface des Client-Netzes zugeordnet.
VLAN erreicht die Firewall nicht: Der Switch-Uplink erlaubt das VLAN nicht tagged oder der Client-Port ist falsch zugewiesen.
Adressbereich passt nicht: Start- oder Endadresse liegt ausserhalb des Interface-Subnetzes.
Bereich ist ausgeschöpft: Anzahl und Laufzeit der belegten Leases mit der Grösse des konfigurierten Bereichs vergleichen. Die Lease-Liste zeigt vergebene, aber keine eigene Liste freier Adressen.
Anderer DHCP-Server antwortet: Der Client erhält eine Adresse, aber ein falsches Gateway oder falsche DNS-Server.
Policy rule denied für Quelle 0.0.0.0: Ist auf dem Interface weder ein DHCP-Server noch ein Relay konfiguriert, kann eine Client-Anfrage mit diesem Eintrag verworfen werden. Die Meldung beweist deshalb nicht, dass eine normale Firewall-Regel die Ursache ist. Zuerst DHCP-Server, Relay und Interface-Zuordnung prüfen.
DHCP Relay wäre nötig: Der Client befindet sich nicht im direkt angeschlossenen Netz des Servers.
Statische Zuordnung greift nicht: Die eingetragene MAC-Adresse entspricht nicht der MAC-Adresse, die der Client tatsächlich verwendet.

Mit einem Paketmitschnitt auf port 67 or port 68 sieht man, ob ein Discover, Offer, Request und ACK ausgetauscht werden und welcher Server antwortet. Die Bedienung ist unter Packet Capture im Sophos Firewall WebAdmin verwenden beschrieben.

Erreicht ein Discover die Firewall, aber es folgt kein Offer, prüft man zusätzlich den Status von dhcpd und das Log dhcpd.log. Die passenden Befehle und Logpfade stehen unter Sophos Firewall Services und Logs per CLI prüfen.

Erhält der Client eine korrekte IP-Adresse, kann aber keine Namen auflösen, prüft man zuerst die per DHCP verteilten DNS-Adressen. Sind sie falsch oder fehlen sie, liegt der Fehler weiterhin in der DHCP-Konfiguration. Stimmen sie, folgen die interne Namensauflösung und der Netzwerkzugriff zum DNS-Server.

Bei einem RED-Interface gibt es einen zusätzlichen Sonderfall: Ändert man die Interface-IP auf eine Adresse ausserhalb des vorhandenen dynamischen Lease-Bereichs, deaktiviert SFOS den zugehörigen RED-DHCP-Server. Danach müssen Dynamic IP lease, statische Zuordnungen und DNS-Werte zum resultierenden Interface-Subnetz passen; alternativ legt man dafür eine neue Serverkonfiguration an. Erst dann wird der DHCP-Bereich wieder in Betrieb genommen und mit einem Client geprüft.

Bestehenden DHCP-Server ablösen

Bei einer Migration sollte man den neuen DHCP-Server nicht einfach zusätzlich aktivieren. Aktive Clients behalten ihre bisherige Lease; der neue Server kennt diese Vergaben nicht und könnte eine noch verwendete Adresse erneut anbieten.

Für einen kontrollierten Wechsel geht man so vor:

Bereich, Optionen, statische Zuordnungen und aktive Leases des bisherigen Servers dokumentieren.
Die Lease-Zeit auf dem alten Server frühzeitig verkürzen und warten, bis die aktiven Clients ihre Lease mit dem kürzeren Wert erneuert haben.
Den bisherigen Server stoppen und den neuen Server zunächst mit einem nicht überlappenden Übergangsbereich aktivieren.
Mehrere unterschiedliche Clients erneuern und Gateway, DNS sowie Erreichbarkeit prüfen.
Nachdem die alten Leases abgelaufen sind, den endgültigen Bereich aktivieren und die normale Lease-Zeit wiederherstellen.

Conflict detection ist bei einer Migration hilfreich, aber kein Ersatz für diese Planung. Die Funktion prüft eine Adresse vor der Vergabe, führt jedoch keine gemeinsame Lease-Datenbank mit dem alten Server.

Für den Rückweg hält man die alte Konfiguration vollständig fest. Verteilt der neue Scope falsche Werte, deaktiviert oder entfernt man nur diese neue Serverkonfiguration und aktiviert den bisherigen Server kontrolliert wieder. Öffnet man System services > Services und klickt bei DHCP server auf Stop, wird dagegen der globale DHCP-Dienst beendet und damit alle lokalen Scopes; diese Aktion passt nur, wenn genau diese Gesamtwirkung beabsichtigt ist. Anschliessend werden die Leases an mehreren Testclients erneuert.

Spezielle Werte wie PXE-Bootserver, VoIP-Controller oder Vendor-Optionen müssen vor der Umschaltung separat verglichen werden. Sie gehören nicht automatisch zur normalen Verteilung von Adresse, Gateway und DNS.

Automatisierung: Status einer benannten DHCP-Konfiguration

Die XML-API-Dokumentation für SFOS 22 und 23 beschreibt DHCPServerStatus mit den Pflichtfeldern DHCPServerNamedhcpname und Status. DHCPServerNamedhcpname ist die wörtlich dokumentierte Schreibweise, keine hier korrigierte Feldbezeichnung. Der Name bezeichnet die ausgewählte DHCP-Serverkonfiguration, etwa dhcp-vlan20-clients, nicht den globalen DHCP-Dienst. Ein Statuswechsel dieses benannten Scopes darf nicht mit dem oben beschriebenen globalen Stop verwechselt werden.

Für Status zeigt das Beispiel ON/OFF, die Parametertabelle nennt dagegen INTEGER. Eine numerische Zuordnung oder ein Default ist nicht angegeben; beide Felder sind Pflichtfelder. Daraus lässt sich weder eine sichere Kodierung noch ein Verhalten bei ausgelassenen Feldern ableiten. Deshalb keine XML-Statusänderung aus diesem Beispiel automatisieren. Bis Feldschema und Statuskodierung für die installierte Version geklärt sind, bleibt man beim bestehenden GUI-Ablauf unter Network > DHCP für die ausgewählte Serverkonfiguration; den globalen Dienst steuert man separat unter System services > Services.

Vor einer Änderung Name, Interface, Adressbereich und bisherigen Status des Ziel-Scopes festhalten. Danach genau diese Konfiguration und die unveränderten anderen Scopes prüfen sowie die oben beschriebenen Lease-, Gateway-, DNS- und Erreichbarkeitsprüfungen mit kontrollierten Clients durchführen. Beim Deaktivieren prüfen, dass dieser Scope keine neuen Leases mehr vergibt; eine noch vorhandene Client-Lease beweist das nicht. Die dokumentierten API-Ergebnisse 200 (Operation Successful) und 500 (Operation Fail) sind keine Funktionsprüfung; auch HTTP 200 allein bestätigt weder das richtige Ziel noch den Clientzustand. Für den Rückweg genau den festgehaltenen Zustand wiederherstellen und die Clientprüfungen wiederholen.

Globale DHCP-Einstellungen nur bei Bedarf ändern

In SFOS 23 findet man unter Network > DHCP > Advanced server settings diese beiden UI-Felder:

Allow only one lease per client begrenzt jeden Client auf eine DHCP-Lease. Ist die Option aktiviert, erhält jeder Client nur eine geleaste IP-Adresse.
Negative acknowledgement aktiviert DHCPNAK-Antworten, wenn ein Client eine Adresse ausserhalb des konfigurierten Server-Subnetzes oder eine bereits vergebene Adresse anfordert. Conflict detection ist dagegen die separate Prüfung einer Adresse vor der Vergabe.

Vor einer UI-Änderung den bisherigen Wert festhalten. Danach eine Client-Lease erneuern, IPv4 lease und bei Bedarf einen Paketmitschnitt auf UDP 67/68 prüfen. Für den Rückbau genau den festgehaltenen Wert wiederherstellen. Die folgenden CLI-Hinweise zu globaler Wirkung, Client-Identität und NAK-Risiken bleiben zu beachten.

Zwei weitere Device-Console-Schalter wirken auf den DHCP-Dienst insgesamt. Vor einer Änderung die lokale, befehlsspezifische Hilfe für one-lease-per-client und send-dhcp-nak auf der installierten Version prüfen. Den aktuellen Zustand beider Schalter über eine dort unterstützte lesende Abfrage oder eine verfügbare UI-Anzeige festhalten und die Änderungs- sowie Rücksetzsyntax bestätigen. Weder eine bestimmte show-Form noch ein Default wird hier für jede Version vorausgesetzt. Ist der Ausgangszustand oder der Rückweg nicht zuverlässig feststellbar, keine Änderung durchführen und zuerst den Support einbeziehen.

one-lease-per-client begrenzt bei Aktivierung die Lease-Vergabe pro Client. Wie die installierte Version den Client in Sonderfällen identifiziert, muss vor Ort geklärt werden. Die Aktivierung gilt für alle DHCP-Serverkonfigurationen auf dieser Firewall; man begrenzt deshalb zunächst nur den Test auf einen kontrollierten Client und prüft danach die Lease-Tabelle, die Erneuerung sowie Geräte mit mehreren Interfaces oder wechselnder MAC-Adresse.

Ein aktiviertes send-dhcp-nak ermöglicht DHCPNAK-Antworten. Ein DHCPNAK weist eine vom Server nicht akzeptierte Adresse zurück und zwingt den Client zurück in die DHCP-Aushandlung. Das Ausschalten kann ungültige Clientzustände verlängern und ist kein allgemeiner Fix für fehlgeschlagene Leases.

Nur wenn die lokale Hilfe diese Syntax für die installierte Version bestätigt und Ausgangszustand sowie Rückweg festgehalten sind, werden die Schalter so geändert:

system dhcp one-lease-per-client [enable|disable]
system dhcp send-dhcp-nak [enable|disable]

Die eckigen Klammern sind Platzhalter; man führt nur den benötigten Wert aus. Nach der Änderung den Wert mit derselben unterstützten lesenden Abfrage oder UI-Anzeige erneut prüfen, eine Lease erneuern, IPv4 lease kontrollieren und bei Bedarf ein Packet Capture auf UDP 67/68 durchführen. Für den Rückbau exakt die vor der Änderung festgehaltenen Werte mit der vorab bestätigten Syntax wiederherstellen und beide Schalter erneut prüfen. system dhcp one-lease-per-client disable beziehungsweise system dhcp send-dhcp-nak enable sind nur dann passende Rücksetzwerte, wenn der erste Schalter vorher deaktiviert beziehungsweise der zweite vorher aktiviert war und die lokale Hilfe diese Syntax bestätigt.