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

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, liest man nach dem SSH-Login in der Device Console die aktuelle Methode und den aktuellen Scope:

system dhcp conf-generation-method show
system dhcp static-entry-scope show

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.

Die dokumentierten Defaults sind old und network. Die alte Generierung kann bei mehrfach gebundenen MAC-Adressen falsche Angaben wie DNS-Server oder Gateway erzeugen. Ist der Zustand bereits angepasst, wird er nicht überschrieben. Für den Rückbau werden genau die zuvor gelesenen Werte verwendet; nur beim bestätigten Default-Zustand lauten sie system dhcp static-entry-scope network und system dhcp conf-generation-method old. Danach muss jeder betroffene Scope mit einer neuen Client-Lease geprüft werden.

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.

⚠️ In einem HA-Cluster unterstützt Sophos den DHCP-Dienst im Modus Active-passive, nicht im Modus Active-active. Diese Einschränkung muss vor der Inbetriebnahme berücksichtigt werden; ein Wechsel des HA-Modus ist kein Fehlerbehebungsschritt für einen einzelnen DHCP-Bereich.

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

ipconfig /release
ipconfig /renew
ipconfig /all

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

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.

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. Zuerst ihren Zustand lesen:

system dhcp one-lease-per-client show
system dhcp send-dhcp-nak show

one-lease-per-client ist standardmässig deaktiviert. Die aktuelle Hilfe erklärt nicht, wie die Funktion den Client in allen Sonderfällen identifiziert. Die Aktivierung gilt global; 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.

send-dhcp-nak ist standardmässig aktiviert. 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.

Die Schalter werden 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 prüft man den Wert erneut mit show, erneuert eine Lease, kontrolliert IPv4 lease und führt bei Bedarf ein Packet Capture auf UDP 67/68 durch. Bei zuvor bestätigten Defaults lautet der Rückbau system dhcp one-lease-per-client disable beziehungsweise system dhcp send-dhcp-nak enable. War der Ausgangszustand angepasst, stellt man stattdessen exakt die vor der Änderung mit show erfassten Werte wieder her und prüft beide Schalter erneut.