Sophos Firewall DHCP Relay einrichten und testen

Ein DHCP Relay leitet DHCP-Anfragen aus einem Client-Netz an einen Server in einem anderen Netz weiter. Auf der Sophos Firewall öffnet man Network > DHCP, legt unter Relay einen Agent für das Client-Interface an und trägt die IP-Adresse des DHCP-Servers ein.

Kurzablauf: Client-Interface auswählen, DHCP-Server eintragen, passenden Scope und Rückweg auf dem Server prüfen, Lease erneuern und den Austausch mit port 67 or port 68 mitschneiden. Relay through IPsec wird nur bei policy-based IPsec aktiviert, nicht bei route-based VPN.

Das Beispiel verwendet das Client-Netz 10.20.0.0/24, das Relay-Interface 10.20.0.1 und den DHCP-Server 172.16.16.17.

Voraussetzungen und Grenzen

Der DHCP-Server muss einen Scope für 10.20.0.0/24 besitzen. Die Sophos Firewall verteilt die Lease nicht selbst; sie verwendet die Adresse des Relay-Interfaces, damit der Server den richtigen Scope auswählt. Das Relay benötigt eine Route zum Server, der Server wiederum einen Rückweg zu 10.20.0.1. Soll die Firewall Adressen direkt im angeschlossenen Client-Netz verteilen, passt stattdessen Sophos Firewall als DHCP-Server einrichten. DHCP-Optionen werden auf dem Server gepflegt, der die Lease ausstellt.

DHCPv6-Server und DHCPv6-Relay können nicht gleichzeitig aktiv sein. Soll die Firewall IPv6-Adressen selbst verteilen, beschreibt DHCPv6-Server auf Sophos Firewall einrichten den getrennten Ablauf mit Router Advertisement, DUID und Lease-Prüfung.

Für die Konfiguration gelten diese Grenzen:

• Das Relay-Interface liegt im selben Subnetz wie die Clients und darf nicht das Interface des DHCP-Servers sein.
• Relay-Agenten sind auf physischen und virtuellen Interfaces wie VLAN, Wireless oder Bridge möglich, nicht aber auf einem Interface Alias.
• Im Subnetz des DHCP-Servers wird kein Relay-Agent angelegt.
• Für jedes Client-Subnetz wird ein eigener Relay-Agent angelegt.
• Pro Relay-Agent lassen sich bis zu acht DHCP-Server hinterlegen. Die Anfrage geht an alle; der Client verwendet das erste Offer.
• DHCPv4-Server und DHCPv4-Relay können gleichzeitig auf derselben Firewall laufen, aber nicht auf demselben Interface.
• DHCPv6-Server und DHCPv6-Relay können auf derselben Firewall nicht gleichzeitig aktiv sein.
• Zwischen Client und Relay werden UDP 67 und 68 benötigt; Relay und Server kommunizieren über UDP 67. Der Server benötigt einen Rückweg zur Relay-IP 10.20.0.1.

Mehrere Relay-Ziele sollten für denselben Client identische Scopes und Optionen ausliefern. Unterschiedliche Antworten führen sonst zu einem schwer reproduzierbaren Verhalten.

DHCP Relay ohne VPN einrichten

1. Network > DHCP öffnen.
2. Unter Relay auf Add klicken.
3. Einen eindeutigen Namen wie relay-clients-vlan20 eintragen.
4. IP version auswählen.
5. Unter Interface das Client-Interface VLAN20 - 10.20.0.1 wählen.
6. Unter DHCP server IP den Server 172.16.16.17 eintragen, mit der Plustaste zur Liste hinzufügen und kontrollieren, dass er dort erscheint.
7. Relay through IPsec deaktiviert lassen und speichern.

Danach eine Lease mit einem Testclient erneuern. Weil Relay-Anfragen systemgenerierter Traffic sind, braucht dieser Ablauf auf der Relay-Firewall keine eigene Firewall-Regel. Geräte zwischen Relay und Server müssen UDP 67 dennoch in beide Richtungen zulassen; im Client-Segment werden UDP 67/68 verwendet. Erhält der Client keine Adresse, zuerst prüfen, ob der Server einen Scope für 10.20.0.0/24 besitzt und eine Route zum Relay-Interface kennt. Bei VLAN-Problemen hilft Sophos Firewall VLAN-Interface konfigurieren.

Relay-Refresh-Intervall nur gezielt ändern

Das globale Intervall für DHCP-Relay-Refresh-Pakete zeigt die Device Console mit:

system dhcp dhcp-relay-refresh-interval show

Der dokumentierte Default beträgt 10 Sekunden. Sophos nennt auf derselben SFOS-22-Seite zwei unterschiedliche Obergrenzen: Die Syntax zeigt 10000, die Optionsbeschreibung dagegen 1000 Sekunden. Deshalb wird kein Wert oberhalb 1000 allein aufgrund der Syntaxzeile eingesetzt. Einen abweichenden Sonderfall zuerst mit Sophos Support klären.

Die Änderung folgt dieser Schablone:

system dhcp dhcp-relay-refresh-interval set seconds <seconds>

Der Platzhalter wird durch einen geprüften Wert ersetzt. Das Intervall wird nicht als allgemeines Tuning verändert und repariert weder einen fehlenden Server-Scope noch Routing, IPsec oder Firewall-Regeln. Vorher den Ist-Wert sichern, danach show, eine neue Client-Lease und den Paketfluss auf UDP 67/68 prüfen. Der Rückbau stellt den zuvor gelesenen Wert wieder her.

DHCP Relay über route-based IPsec

Die SFOS-22-Hilfe dokumentiert DHCP Relay über XFRM zu einem externen DHCP-Server hinter der zentralen Firewall. Der dokumentierte Aufbau verwendet einen route-based Any-to-Any-Tunnel. Route-based Traffic Selectors sind für diesen Ablauf nicht bestätigt.

⚠️ Die offizielle Hilfe ist an dieser Stelle widersprüchlich: Die DHCP-Übersicht sagt, Relay-Agenten könnten derzeit nicht über route-based VPN erstellt werden. Die Seite Add a DHCP relay und die eigene route-based Anleitung beschreiben dagegen genau den folgenden Aufbau. Deshalb wird die Aussage nicht auf andere route-based Designs übertragen. Falls die Felder im eingesetzten SFOS-22-Build abweichen, nicht auf policy-based Optionen ausweichen, sondern den Build mit Sophos Support klären.

⚠️ Der Quellenkonflikt bleibt ungelöst; der beschriebene Aufbau ist dokumentiert, nicht als Produktfähigkeit bestätigt oder getestet. Vor der Umsetzung muss Sophos Support die Unterstützung für den genauen SFOS-Build und die Any-to-Any-Topologie mit externem DHCP-Server klären. Diese Bestätigung ist eine Voraussetzung, kein hier bereits vorliegender Nachweis. Bis zur Klärung keine route-based Konfigurationsänderungen nach diesem Ablauf vornehmen.

Vorausgesetzt werden:

1. Any-to-Any-IPsec-Verbindungen auf beiden Firewalls.
2. Adressierte XFRM-Interfaces mit Gateway.
3. Statische, SD-WAN- oder dynamische Routen auf beiden Firewalls: vom Relay zum DHCP-Server und für die Antwort zurück zur Relay-IP 10.20.0.1.
4. Erlaubter IPsec-Zugriff unter Administration > Device access für die beteiligten WAN-Interfaces.
5. Eine Regel in der Zentrale von VPN zur Serverzone mit Source 10.20.0.1, Destination 172.16.16.17 und Service DHCP.

Am Aussenstandort wird das Client-Interface als Relay-Agent eingetragen; Relay through IPsec bleibt deaktiviert. Die Relay-Anfrage ist dort systemgenerierter Traffic und benötigt keine eigene DHCP-Firewall-Regel. Eine SD-WAN-Route verwendet als Source Any, als Destination den Host 172.16.16.17, als Service DHCP und das entfernte XFRM-Gateway. In der Zentrale führt die Rückroute vom DHCP-Server zur Relay-IP 10.20.0.1 über das XFRM-Gateway. Wer verhindern will, dass dieser Verkehr bei einem Tunnelausfall über ein anderes Gateway ausweicht, aktiviert in beiden dedizierten SD-WAN-Routen Route only through specified gateways.

Die allgemeinen VPN-Regeln für den Any-to-Any-Tunnel müssen ebenfalls bestehen; die Konfiguration des Tunnels und der XFRM-Routen ist unter Site-to-Site IPsec auf Sophos Firewall einrichten ausführlich beschrieben.

⚠️ Dieser route-based Ablauf gilt für einen externen DHCP-Server hinter der zentralen Firewall. Ein Interface der Sophos Firewall als zentraler DHCP-Server wird dafür nicht unterstützt.

DHCP Relay über policy-based IPsec

Bei policy-based IPsec wird am Aussenstandort Relay through IPsec aktiviert. Lokale und entfernte Subnetze der IPsec-Verbindung müssen Relay-Interface und DHCP-Server abdecken. Liegt ein externer DHCP-Server hinter der zentralen Firewall, werden dort zwei Regeln benötigt:

• VPN zur Serverzone: Relay-Netz zu DHCP-Server, Service DHCP.
• Serverzone zu VPN: DHCP-Server zum Client-Netz, Service DHCP.

Für den dokumentierten policy-based Ablauf muss die Quelladresse des systemgenerierten Relay-Traffics mit sys-traffic-nat auf die Relay-IP festgelegt werden. Die folgenden Befehle werden nach dem SSH-Login in der Device Console ausgeführt. Unter SFOS 22.0 ist für diesen systemgenerierten Traffic keine zusätzliche system ipsec_route nötig.

Vor der Änderung den aktuellen Zustand sichern:

show advanced-firewall

⚠️ sys-traffic-nat add verändert die globale NAT-Konfiguration für systemgenerierten Traffic. Destination und Quelladresse müssen zum IPsec-Tunnel und zum Rückweg passen.

Für das Beispiel wird die Quelladresse des Relay-Interfaces zum DHCP-Server festgelegt:

set advanced-firewall sys-traffic-nat add destination 172.16.16.17 snatip 10.20.0.1

Anschliessend show advanced-firewall erneut ausführen und prüfen, ob genau dieser Eintrag vorhanden ist. Der Server muss 10.20.0.1 über den Tunnel erreichen können. War derselbe Eintrag bereits vor der Änderung vorhanden, gehört er nicht zum Rollback dieses Ablaufs.

Rollback für einen in diesem Ablauf neu angelegten Eintrag:

set advanced-firewall sys-traffic-nat delete destination 172.16.16.17 snatip 10.20.0.1

Weitere policy-based Routing-Sonderfälle und ältere SFOS-Abläufe erklärt IPsec Route auf Sophos Firewall erstellen.

Wenn die Zentrale selbst DHCP-Server ist

Nur für dieses policy-based Szenario, in dem die Sophos Firewall in der Zentrale selbst DHCP-Server ist, bleibt Create firewall rule in den IPsec-Verbindungen auf beiden Firewalls deaktiviert. Die DHCP-Kommunikation mit dem firewallinternen Server ist nicht mit dem Weiterleiten zu einem externen Server gleichzusetzen; die zuvor beschriebenen zentralen Weiterleitungsregeln gehören zum externen Server. IPsec-Zugriff von WAN unter Administration > Device access und erforderliche Regeln für anderen VPN-Nutzverkehr bleiben bestehen.

Arbeitet die zentrale Sophos Firewall bei policy-based IPsec selbst als DHCP-Server, wird unter Network > DHCP > Server ein Server-Scope erstellt oder bearbeitet. Accept client request via relay aktivieren, eine Lease-Range aus 10.20.0.0/24 eintragen und 10.20.0.1 als Gateway setzen. Am Relay-Agent wird als DHCP server IP das Server-Interface der zentralen Firewall eingetragen; im vorherigen NAT-Beispiel ersetzt dessen Adresse entsprechend 172.16.16.17.

⚠️ Version vor der globalen Änderung prüfen: Der folgende Enable-Ablauf gilt nur für das dokumentierte SFOS-22-Szenario. Die vorliegenden SFOS-23-Hilfeseiten widersprechen sich: HO firewall as DHCP server and BO firewall as relay agent beschreibt DHCP-Leases über IPsec als standardmässig aktiviert und ohne zusätzliche Konfiguration; die DHCP-Übersicht fordert weiterhin das Einschalten auf der CLI. Der Konflikt bleibt ungelöst. Daraus folgt weder ein bestätigter Ist-Zustand nach einem Upgrade noch, dass der Befehl entfernt wurde. Unter SFOS 23 nicht routinemässig global aktivieren: den genauen Build und Ist-Zustand erfassen und die Notwendigkeit einer Änderung zuerst mit Sophos Support klären. Ist der Zustand nicht eindeutig oder der Statusbefehl nicht verfügbar, vor einer Änderung stoppen.

Den genauen SFOS-Build notieren und vor einer Änderung den Zustand auf der lease-ausstellenden zentralen Firewall in der Device Console anzeigen und sichern:

system dhcp lease-over-IPSec show

⚠️ Die folgende Einstellung wirkt global auf DHCP-Leases über IPsec. Nur auf der Firewall aktivieren, die selbst die Leases ausstellt. Den angezeigten Ausgangszustand notieren, damit der Rückbau keine bereits bestehende Konfiguration abschaltet.

Nur unter SFOS 22, wenn der erfasste Zustand deaktiviert ist, aktivieren und danach mit dem vorherigen show-Befehl prüfen. Bei bereits aktiviertem Zustand nichts ändern:

system dhcp lease-over-IPSec enable

Nur wenn die Funktion auf der lease-ausstellenden zentralen Firewall zuvor deaktiviert war und im autorisierten Ablauf tatsächlich aktiviert wurde, lautet der Rollback:

system dhcp lease-over-IPSec disable

War sie bereits aktiviert, bleibt sie aktiviert. In beiden Fällen bestätigt system dhcp lease-over-IPSec show den wiederhergestellten Zustand.

Funktion testen und Fehler beheben

Eine erfolgreiche Relay-Konfiguration erkennt man nicht allein am gespeicherten Agent. Mit einem Testclient wird die Lease erneuert und unter Diagnostics > Packet capture > Configure im Feld Enter BPF string ein enger Filter gesetzt:

port 67 or port 68

Im Paketfluss sollten nacheinander Client-Anfrage, weitergeleitete Anfrage, Server-Offer und Rückweg sichtbar sein. Die Spalten In interface, Out interface, Source IP, Destination IP, Ports [src, dst] und Status zeigen, an welcher Stelle der Austausch endet. Relay-Pakete können dabei als Generated oder Forwarded erscheinen. Bei Violation liefert Reason den nächsten Prüfhinweis. Die Bedienung und Felder erklärt Packet Capture im Sophos Firewall WebAdmin.

Typische Fehler lassen sich so eingrenzen:

• Keine Client-Anfrage sichtbar: VLAN, Switch-Port, Client-Interface oder lokalen DHCP-Client prüfen.
• Anfrage erreicht die Firewall, wird aber nicht weitergeleitet: Relay-Interface, Server-IP, Route und bei policy-based IPsec Relay through IPsec prüfen.
• Server erhält die Anfrage, antwortet aber nicht: Scope für das Relay-Subnetz, Server-Autorisierung und lokale Server-Firewall prüfen.
• Offer erreicht die Zentrale, aber nicht den Client: Rückroute, zentrale Firewall-Regeln, IPsec-Subnetze und NAT-Eintrag prüfen.
• Client erhält eine falsche Konfiguration: Ermitteln, welcher Server zuerst antwortet, und Scopes sowie DHCP-Optionen auf allen Relay-Zielen vergleichen.

Konfiguration zurücknehmen

Für einen geplanten Rückbau zuerst sicherstellen, dass im Client-Netz wieder ein erreichbarer DHCP-Server vorhanden ist. Danach den Relay-Agent unter Network > DHCP > Relay löschen. Dedizierte Routen, Hostobjekte und Regeln erst entfernen, wenn Packet Capture keine Relay-Anfragen mehr zeigt; gemeinsam mit anderem VPN-Traffic genutzte Objekte bleiben bestehen. Bei policy-based IPsec zusätzlich nur den in diesem Ablauf neu angelegten sys-traffic-nat-Eintrag löschen. lease-over-IPSec nur auf der zentralen Firewall zurücksetzen, die selbst die Leases ausstellt, und nur wenn der Zustand während des autorisierten Ablaufs tatsächlich geändert wurde; dabei den zuvor notierten Zustand wiederherstellen. Für Relay zu einem externen DHCP-Server oder einen unveränderten Zustand gehört dies nicht zum Rückbau.

Häufige Fragen