7
DHCP-Relay: Anfragen landen nicht beim gewünschten DHCP
Hallo zusammen,
ich würde gerne den DHCP Server relayen und dafür gegeben ist folgender Aufbau:
Standort A: 192.168.178.0/24, pfSense bei 192.168.178.1
Standort B: 10.0.0.0/24, pfSense bei 10.0.0.1, Windows DHCP und DNS bei 10.0.0.2
A und B sind via IPsec miteinander verbunden.
Ich habe testweise eine allow-any-rule bei LAN und IPsec in der pfSense gesetzt bei A und B. Die Firewall am Windows DHCP habe ich testweise vollständig deaktiviert und den DHCP-Server bei der pfSense 192.168.178.1 auf Relay zu 10.0.0.2 umgestellt.
Wenn ich nun versuche, eine IP via DHCP bei irgendeinem Client auf A zu ziehen, kommt es zu einer Zeitüberschreitung.
Mit Wireshark finde ich am Windows DHCP keine Pakete mit dem Protokoll "dhcp", wenn ich z.B. an einem Client "ipconfig /renew" probiere.
Langsam stehe ich ein bisschen auf dem schlauch und frage mich, woran es noch liegen könnte, dass ich gar nicht erst bis zum DHCP Server komme. Der 10.0.0.2 selbst ist grundsätzlich von den Clients via Ping, RDP etc erreichbar.
Ich freue mich auf eure Lösungsvorschläge und Gedankenanstöße.
Danke!
ich würde gerne den DHCP Server relayen und dafür gegeben ist folgender Aufbau:
Standort A: 192.168.178.0/24, pfSense bei 192.168.178.1
Standort B: 10.0.0.0/24, pfSense bei 10.0.0.1, Windows DHCP und DNS bei 10.0.0.2
A und B sind via IPsec miteinander verbunden.
Ich habe testweise eine allow-any-rule bei LAN und IPsec in der pfSense gesetzt bei A und B. Die Firewall am Windows DHCP habe ich testweise vollständig deaktiviert und den DHCP-Server bei der pfSense 192.168.178.1 auf Relay zu 10.0.0.2 umgestellt.
Wenn ich nun versuche, eine IP via DHCP bei irgendeinem Client auf A zu ziehen, kommt es zu einer Zeitüberschreitung.
Mit Wireshark finde ich am Windows DHCP keine Pakete mit dem Protokoll "dhcp", wenn ich z.B. an einem Client "ipconfig /renew" probiere.
Langsam stehe ich ein bisschen auf dem schlauch und frage mich, woran es noch liegen könnte, dass ich gar nicht erst bis zum DHCP Server komme. Der 10.0.0.2 selbst ist grundsätzlich von den Clients via Ping, RDP etc erreichbar.
Ich freue mich auf eure Lösungsvorschläge und Gedankenanstöße.
Danke!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 33017849402
Url: https://administrator.de/forum/dhcp-relay-anfragen-landen-nicht-beim-gewuenschten-dhcp-33017849402.html
Ausgedruckt am: 22.12.2024 um 03:12 Uhr
7 Kommentare
Neuester Kommentar
Moin @bluelight
vergibt denn der Windows DHCP überhaupt IP Adressen für den Bereich in Netzwerk A?
Wäre es nicht schlauer, DHCP an Ort und stelle zu vergeben, anstatt das auf einem anderen Standort zu machen? es sind doch eh zwei unterschiedliche Netze.
Kreuzberger
vergibt denn der Windows DHCP überhaupt IP Adressen für den Bereich in Netzwerk A?
Wäre es nicht schlauer, DHCP an Ort und stelle zu vergeben, anstatt das auf einem anderen Standort zu machen? es sind doch eh zwei unterschiedliche Netze.
Kreuzberger
Hi @kreuzberger,
der Windows DHCP ist für den entsprechenden Bereich konfiguriert.
Es sind zwei unterschiedliche Netze, allerdings bin ich gerade am rumprobieren und möchte gerne sowas (testweise) auf die Beine stellen.
Gruß
der Windows DHCP ist für den entsprechenden Bereich konfiguriert.
Es sind zwei unterschiedliche Netze, allerdings bin ich gerade am rumprobieren und möchte gerne sowas (testweise) auf die Beine stellen.
Gruß
Moin,
aus performancegründen: setz bei beiden Standorten ein DNS/DHCP Server auf. Baue Standorte im AD und die Clients suchen sich den in Ihrem Netzwerk verfügbaren DNS/DHCP Server. Wesentlich schneller als wenn jede Anfrage ständig über die VPN muss.
Gruß
aus performancegründen: setz bei beiden Standorten ein DNS/DHCP Server auf. Baue Standorte im AD und die Clients suchen sich den in Ihrem Netzwerk verfügbaren DNS/DHCP Server. Wesentlich schneller als wenn jede Anfrage ständig über die VPN muss.
Gruß
Hey @accesviolation,
vielen Dank für deinen Vorschlag - diesen werde ich im Hinterkopf behalten. Trotzdem sollte der gewünschte Erfolg mit meiner Konfiguration möglich sein, oder nicht?
Ich wäre daher für Vorschläge, die zur Lösung des Problems (ohne den Aufbau grundlegend zu ändern) beitragen, wirklich dankbar.
Gruß
vielen Dank für deinen Vorschlag - diesen werde ich im Hinterkopf behalten. Trotzdem sollte der gewünschte Erfolg mit meiner Konfiguration möglich sein, oder nicht?
Ich wäre daher für Vorschläge, die zur Lösung des Problems (ohne den Aufbau grundlegend zu ändern) beitragen, wirklich dankbar.
Gruß
Mit Wireshark finde ich am Windows DHCP keine Pakete mit dem Protokoll "dhcp"
Mh, womöglich blockt etwas anderes? Kann die PF beide Netzwerke sehen und pingen?Viele Grüße
@bluelight
Vielleicht hilft dir das ja weiter, hier sind die Registry-Parameter beschrieben.
https://support.microsoft.com/de-de/topic/update-dhcp-verbindung-dauert- ....
Kreuzberger
Vielleicht hilft dir das ja weiter, hier sind die Registry-Parameter beschrieben.
https://support.microsoft.com/de-de/topic/update-dhcp-verbindung-dauert- ....
Kreuzberger
Moin,
+1 für einen eigenen DHCP-Server am RemoteStandort. Wenn mal der Tunnel morgen zwischen 07 und 08 Uhr nicht geht, sind ein Haufen User Arbeitslos, weil die Endgeräte beim Einschalten keine IP bekommen.
Ansonsten.
Wenn am Windows-Server keine Pakete ankommen, dann rückwärts analysieren, bis man die ersten Pakete des Clients sieht.
Da ja zwei Gateways/ Router zum EInsatz kommen (Standort A und Standort B):
prüfe mal, ob an beiden ein DHCP-Relay aktiv sein muss.
Schaue mal hier: https://community.checkpoint.com/t5/Security-Gateways/DHCP-Relay-over-Si ...
Das betrifft zwar eine Checkpoint, verfolgt aber dasselbe Ziel.
Hier hat ein User eine SNAT-Regel etabliert.
+1 für einen eigenen DHCP-Server am RemoteStandort. Wenn mal der Tunnel morgen zwischen 07 und 08 Uhr nicht geht, sind ein Haufen User Arbeitslos, weil die Endgeräte beim Einschalten keine IP bekommen.
Ansonsten.
Wenn am Windows-Server keine Pakete ankommen, dann rückwärts analysieren, bis man die ersten Pakete des Clients sieht.
Da ja zwei Gateways/ Router zum EInsatz kommen (Standort A und Standort B):
prüfe mal, ob an beiden ein DHCP-Relay aktiv sein muss.
Schaue mal hier: https://community.checkpoint.com/t5/Security-Gateways/DHCP-Relay-over-Si ...
Das betrifft zwar eine Checkpoint, verfolgt aber dasselbe Ziel.
Hier hat ein User eine SNAT-Regel etabliert.
