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. Für route-based VPN zuerst die unten beschriebene Quellenlage und die Unterstützung des genauen Builds mit Sophos Support klären; der Kurzablauf ist keine Freigabe für diesen Aufbau.

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. Dies ist ein IPv4-Beispiel: Alle Adressen, das Client-Interface und den Namen an das eigene Netz anpassen. Der Scope ist der Adressbereich samt Netzparametern, aus dem der Server Leases vergibt. Das Gateway muss im Client-Netz liegen und erreichbar sein; ein DNS-Server muss vom Client aus erreichbar sein. Vor dem Wechsel bestehende Scopes, Relay-Agenten und Routen sichern und einen Testclient verwenden, der Adressen automatisch per DHCP bezieht.

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.

Auch auf derselben Sophos Firewall sind DHCPv4-Server und Relay möglich:

• Der Server lauscht auf einem anderen Interface.
• Accept client request via relay ist aktiviert.
• Pro Client-Subnetz besteht ein eigener Server-Scope mit passender Lease-Range, Subnetzmaske, Gateway und DNS.

Der Relay-Agent verwendet das jeweilige Client-Interface und als Ziel die Adresse des Server-Interfaces. Für Clients im Server-Subnetz bleibt die direkte Vergabe ohne Relay bestehen.

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 konsistente Netzwerkparameter und Optionen ausliefern. Die Adressvergabe muss dabei entweder durch Server-Failover gemäß der Serverdokumentation koordiniert werden oder über nicht überlappende dynamische Vergabebereiche erfolgen. 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. Für dieses Beispiel unter IP version IPv4 auswählen. Für IPv6 nicht die IPv4-Adressen oder UDP-Ports aus dieser Anleitung übernehmen.
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.

XML-API: Identität und IPv6-Validierungsgrenze

Bei der Automatisierung gehört dieselbe Konfiguration zum Objekt DHCPRelay: Name bezeichnet den Relay-Agent, Interface das Client-Interface, IPFamily die bewusst gewählte Familie IPv4 oder IPv6 und DHCPServerIP die Serverliste. Die Add/Edit-Dokumentation für SFOS 22 und 23 kennzeichnet diese vier Felder als erforderlich; der dokumentierte Default für IPFamily ist IPv4. DHCPServerIP ist als ARRAY mit IPADDRESS und IPADDRESS6 beschrieben: mehrere Werte sind zulässig, doppelte werden ignoriert, LINKLOCAL ist ausgeschlossen. Damit bleiben mehrere Relay-Ziele möglich; das einzelne Platzhalterfeld im Beispiel belegt weder die Listenserialisierung noch eine IPv6-Kodierung. Den Zustand von Relay through IPsec passend zur unten erläuterten VPN-Variante bewusst beibehalten, nicht aus einem API-Beispiel ableiten.

Die Parametertabelle nennt für DHCPServerIP gleichzeitig maximal 15 Zeichen. Diese Angabe passt nicht allgemein zur erlaubten IPv6-Adressdarstellung mit IPADDRESS6: Die Dokumentation ist hier inkonsistent und belegt nicht, wie der Validator des konkreten Builds IPv6 verarbeitet. Daraus folgt weder, dass DHCPv6 Relay im Produkt nicht unterstützt wird, noch eine alternative Kodierung oder die Erlaubnis, Adressen zu kürzen.

Für IPv6 zunächst die manuelle Konfiguration im WebAdmin verwenden und vor IPv6-Automatisierung das Schema samt Adressvalidierung und Serverlistenformat für die genaue SFOS-Version und den Build mit Sophos Support klären. Eine gespeicherte GUI-Konfiguration oder eine erfolgreiche Client-Lease bestätigt keine gültige IPv6-XML-Anfrage. Die Client- und Paketflussprüfungen sowie der zustandsbezogene Rückbau unten bleiben erforderlich; IPv4-Adressen und UDP-Ports dieses Beispiels werden nicht für IPv6 übernommen.

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- und SFOS-23-Hilfe dokumentiert DHCP Relay über XFRM zu einem externen DHCP-Server hinter der zentralen Firewall. Der beschriebene 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 in SFOS 22 und SFOS 23 widersprüchlich: Sowohl die DHCP-Übersicht als auch Routing and NAT for IPsec tunnels verneinen DHCP Relay über route-based VPN. Add a DHCP relay und die separate route-based Anleitung beschreiben dagegen den folgenden Any-to-Any-Aufbau. Daraus lässt sich keine bestätigte Produktunterstützung ableiten. Bei abweichenden Feldern nicht auf policy-based Optionen ausweichen, sondern die Topologie und den genauen 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.

Der dokumentierte Aufbau umfasst die folgenden Voraussetzungen. Die Details dienen bis zur Klärung mit Sophos Support nur zur Planung; Konfigurationsänderungen erfolgen erst nach Bestätigung:

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:

• Source: Any
• Destination: Host 172.16.16.17
• Service: DHCP
• Gateway: 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.

Will man verhindern, dass dieser Verkehr bei einem Tunnelausfall über ein anderes Gateway ausweicht, aktiviert man in beiden dedizierten SD-WAN-Routen Route only through specified gateways.

Für die dedizierten SD-WAN-Routen geht man nach der Bestätigung wie folgt vor:

1. Routing > SD-WAN routes öffnen.
2. IPv4 > Add wählen und einen eindeutigen Namen vergeben.
3. Unter Link selection settings die Option Primary and backup gateways wählen.
4. Unter Primary gateway das passende XFRM-Gateway der jeweiligen Firewall eintragen.
5. Danach speichern.

Die Firewall-Regel in der Zentrale wird unter Rules and policies > Firewall rules > Add firewall rule > New firewall rule mit den oben genannten Hosts und dem Service erstellt. Die Destination zone entspricht dem tatsächlichen Servernetz, etwa DMZ, nicht automatisch LAN.

Die Fail-closed-Option verhindert Ausweichrouting, bedeutet bei Tunnelausfall aber auch, dass keine neuen Leases über diesen Pfad bezogen werden können.

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. Ein bestehender, funktionierender Tunnel ist Voraussetzung.

Falls der Tunnel erst angelegt wird, erfolgt dies unter Site-to-site VPN > IPsec > IPsec connections > Add mit Connection type: Policy-based:

• Am Aussenstandort: Gateway type: Initiate the connection.
• In der Zentrale: Respond only.
• Listening interface ist jeweils das eigene WAN-Interface.
• Gateway address ist die WAN-Adresse der Gegenseite.

Authentifizierung und Preshared key müssen übereinstimmen. Lokale und entfernte Netze werden auf der Gegenseite gespiegelt. Für das externe Server-Beispiel sind dies 10.20.0.0/24 und das tatsächlich verwendete Servernetz.

IPsec-Zugriff von WAN unter Administration > Device access erlauben.

Am Aussenstandort braucht der systemgenerierte Relay-Verkehr keine automatisch erzeugte Firewall-Regel. In der Zentrale können die automatisch erzeugten Regeln auf die unten genannten DHCP-Hosts, Zonen und Services eingegrenzt werden.

Bestehende Regeln für sonstigen VPN-Verkehr nicht entfernen.

• 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.

Die spezielle Routing/NAT-Hilfe für SFOS 22 und 23 unterscheidet weitergeleiteten von systemgeneriertem Traffic: Für Letzteren ist keine zusätzliche system ipsec_route erforderlich. Die allgemeine DHCP-Übersicht nennt dagegen noch einen IPsec-Route-Schritt.

Dieser Unterschied ist kein Grund, routinemässig eine weitere Route anzulegen: zunächst die vorhandene Route und den Paketfluss prüfen, bei abweichendem Build-Verhalten Sophos Support einschalten.

• NAT ersetzt keine Route.
• destination bleibt die Serveradresse.
• snatip ist die Relay-Quelladresse, nicht die Serveradresse.
• Eine gewöhnliche WAN-MASQ-Regel ist kein Ersatz für sys-traffic-nat.

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:

1. Accept client request via relay aktivieren.
2. Eine Lease-Range aus 10.20.0.0/24 eintragen.
3. 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.

Ein anpassbares Beispiel für Dynamic IP lease ist 10.20.0.10 bis 10.20.0.30 mit Subnetzmaske 255.255.255.0. Gateway 10.20.0.1 und feste Infrastrukturadressen bleiben ausserhalb des Pools.

Den Pool nach Client-Anzahl und bereits reservierten Adressen wählen. Use device’s DNS settings nur verwenden, wenn die dort hinterlegten DNS-Server von der Filiale erreichbar sind.

Für diesen firewallinternen Server verwenden die policy-based Selektoren in der Zentrale die Server-Interface-Adresse und das Client-Netz. An der Filiale gilt die umgekehrte Zuordnung.

⚠️ 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 sichtbar sein:

1. Client-Anfrage
2. Weitergeleitete Anfrage
3. Server-Offer
4. Rückweg

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.

Ein Offer allein genügt nicht: Der Client muss die Adresse anfordern und ein ACK erhalten. Danach:

• Am Client die IP-Adresse aus dem vorgesehenen Pool, Subnetzmaske, Gateway und DNS prüfen.
• Den Lease-Eintrag auf dem ausstellenden Server kontrollieren.

Eine Ping-Antwort des Servers belegt weder UDP-Erreichbarkeit noch einen erfolgreichen DHCP-Austausch.

Diese Prüfungen sind vom Admin auszuführen.

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.
• Policy rule denied bei Source 0.0.0.0: Ein Client ohne Adresse beginnt mit dieser Quelladresse. Prüfen, ob auf dem richtigen Client-Interface ein DHCP-Server oder Relay zuständig ist; keine pauschale Allow-Regel für 0.0.0.0 oder Any anlegen, um das Symptom zu verdecken. Die Übersicht beschreibt den Drop bei fehlendem Server; im Relay-Szenario den tatsächlichen Paketpfad prüfen, statt daraus eine allgemeine Relay-Sperre abzuleiten.

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