DHCP Server und DHCP Relay Konfiguration - Grundlagen
Guten Tag,
Ich bekomme aus dem Subnetz keine IP Adresse vom DHCP Server. Bin durch die lange Fehlersuche nun auch verunsichert wie der DHCP und der Relay Agent konfiguriert werden muss.
Der DHCP Relay Agent ist eine Securepoint UTM. Ich habe folgende Konfiguration.
Es besteht eine S2S Verbindung über den Tunnel in das Netz 192.168.2.0/24
Das Netz hinter der Firewall ist 192.168.100.0/24 ->Transfernetz->192.168.2.0/24
Die UTM selbst hat die 192.168.100.1.
Die Regeln stehen aktuell noch auf ANY zur Fehlersuche.
Der DHCP Server ist virtuell und hat 2 NIC.
1. NIC 192.168.2.10 verbunden mit dem virtuellen Switch.
2. NIC 192.168.100.11 nicht verbunden.
DHCP Server IP 192.168.2.10/24
Auf dem Server ist ein weiterer Bereich eingerichtet der dann die IP Adressen aus dem 100er Netz vergeben soll und wie folgt an die Clients vergeben soll.
IP Range 192.168.100.15 bis 192.168.100.50
DNS 192.168.100.1
Gateway 192.168.100.1
In der UTM ist der DHCP Relay Agent wie folgt konfiguriert.
192.168.2.10 (DHCP Server)
Was muss ich an dem DHCP Server einstellen? Kann ich mit Bereichsgruppen arbeiten?
Ich bin nicht sicher ob ich ein Design Fehler habe. Denn es hat schon einmal (wirklich nur einmal) funktionert.
Es wurde nichts verändert.
Da nun langsam der Securepoint Support (welcher echt gut ist) und ich an meine Grenzen stoßen, wollte ich gerne über das Forum abklären ob es so funktionieren kann.
Oder auch wie es richtig eingerichtet wird. Ich muss sicherstellen das meine Konstellation funktioniert oder auch nicht funktioniert.
Gruß
Andreas
Ich bekomme aus dem Subnetz keine IP Adresse vom DHCP Server. Bin durch die lange Fehlersuche nun auch verunsichert wie der DHCP und der Relay Agent konfiguriert werden muss.
Der DHCP Relay Agent ist eine Securepoint UTM. Ich habe folgende Konfiguration.
Es besteht eine S2S Verbindung über den Tunnel in das Netz 192.168.2.0/24
Das Netz hinter der Firewall ist 192.168.100.0/24 ->Transfernetz->192.168.2.0/24
Die UTM selbst hat die 192.168.100.1.
Die Regeln stehen aktuell noch auf ANY zur Fehlersuche.
Der DHCP Server ist virtuell und hat 2 NIC.
1. NIC 192.168.2.10 verbunden mit dem virtuellen Switch.
2. NIC 192.168.100.11 nicht verbunden.
DHCP Server IP 192.168.2.10/24
Auf dem Server ist ein weiterer Bereich eingerichtet der dann die IP Adressen aus dem 100er Netz vergeben soll und wie folgt an die Clients vergeben soll.
IP Range 192.168.100.15 bis 192.168.100.50
DNS 192.168.100.1
Gateway 192.168.100.1
In der UTM ist der DHCP Relay Agent wie folgt konfiguriert.
192.168.2.10 (DHCP Server)
Was muss ich an dem DHCP Server einstellen? Kann ich mit Bereichsgruppen arbeiten?
Ich bin nicht sicher ob ich ein Design Fehler habe. Denn es hat schon einmal (wirklich nur einmal) funktionert.
Es wurde nichts verändert.
Da nun langsam der Securepoint Support (welcher echt gut ist) und ich an meine Grenzen stoßen, wollte ich gerne über das Forum abklären ob es so funktionieren kann.
Oder auch wie es richtig eingerichtet wird. Ich muss sicherstellen das meine Konstellation funktioniert oder auch nicht funktioniert.
Gruß
Andreas
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 571482
Url: https://administrator.de/contentid/571482
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
14 Kommentare
Neuester Kommentar
Moin,
ich würde vom Grundsatz erstmal ein Wireshark o.Ä. auf die Verbindung zwischen DHCP-Server und -Relay setzen. Dann siehst Du, ob da Requests laufen bzw. beantwortet werden. Wenn da keine Requests flie
Die 100er IP auf dem DHCP-Server sieht irgendwie störend aus, auch wenn die nicht verbunden ist. Die würde ich einfach mal testhalber rausnehmen.
Gruß
Bernhard
ich würde vom Grundsatz erstmal ein Wireshark o.Ä. auf die Verbindung zwischen DHCP-Server und -Relay setzen. Dann siehst Du, ob da Requests laufen bzw. beantwortet werden. Wenn da keine Requests flie
Die 100er IP auf dem DHCP-Server sieht irgendwie störend aus, auch wenn die nicht verbunden ist. Die würde ich einfach mal testhalber rausnehmen.
Gruß
Bernhard
Ist denn mein Aufbau korrekt? Zweifel hier noch.
Ja, ist er.Der Relay Agent ist immer auf dem Routing Device in dem Netz was keinen DHCP Server hat.
Der Relay Agent ersetzt dann die Absender IP Adresse des DHCP Clients mit seiner eigenen und forwardet den Request per Unicast dann an den DHCP Server der im Relay Agent konfiguriert ist.
Kommt der am DHCP Server an erkennt der am DHCP Relay Feld das Subnetz und antwortet mit einem Unicast Reply. Siehe dazu auch hier Punkt 3.1:
https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/un ...
Wie Kollege @BernhardMeierrose oben schon richtig sagt solltest du am DHCP Server mal einen Wireshark oder Microsoft Network Monitor laufen lassen und dir mal genau ansehen ob an deinem Wireshark überhaupt die DHCP Requests des UTM Relay Agents ankommen.
Wenn diese gar nicht erst ankommen, kann natürlich keine IP Adresse vergeben werden.
Aber auch wenn die DHCP Reply Pakete vom Server in der Firewall durch falsche Regeln blockiert werden hast du natürlich auch ein Problem.
Fazit: Messen und den Fehler dann eingrenzen !
Zitat von @Andreas377:
Ja da laufen DHCP Request. Aber es werden keine IP´s aus dem 100er Netz vergeben.
Ja da laufen DHCP Request. Aber es werden keine IP´s aus dem 100er Netz vergeben.
Was bedeutet das genau?
Kommen aus dem 100er-Netz Requests am DHCP-Server an, die vom DHCP-Relay stammen?
Wenn ja, werden die gar nicht oder falsch vom DHCP-Server beantwortet ? (darfst auch gerne Infos aus dem Wireshark posten)
Und irgendwo zwischden dem entferntem UTM in der Zweigestelle und dem DHCP-Server steht ja noch eine Firewall, die lässt auch die DHCP-Relay-Pakete durch?
Gruß
Bernhard
...und bitte nicht immer in unübersichtlichen Einzelthreads antworten im Minutenabstand !
Das kann man auch intelligent in einem einzigen zusammen fassen wenn man @_Nickname benutzt !
Das kann man auch intelligent in einem einzigen zusammen fassen wenn man @_Nickname benutzt !
Hier lag der Hund begraben, durch eine Fehlkonfiguration der UTM Schnittstelle wurde das falsche Subnetz mitgeschickt.
Klassischer Flüchtigkeitsfehler wenn man die Konfig nicht kontrolliert