Verständnisfrage zu DHCP Relay

Diese Webseite finanziert sich ausschließlich durch freiwillige Spenden. Dank der Unterstützung unserer Nutzer können wir die Inhalte werbefrei und unabhängig anbieten. Jetzt Unterstützen

    Moin zusammen,
    ich habe einen MS DHCP Server, der für meine Netze (Zonen/VLANs) jeweils als DHCP-Relay eingetragen ist. Er befindet sich im selben Netz wie der Router (UXG-Pro) und die Unifi Network Application.
    Das funktioniert grundsätzlich auch alles einwandfrei, alle Clients aus diversen Zonen und VLANs bekommen vom MS DHCP schöne brav ihre IPs aus den jeweiligen Netzen.

    Nun fällt mir in den Firewall Logs immer wieder auf, daß manche Clients versuchen, direkt auf den MS DHCP zuzugreifen (Port 67), was erwartungsgemäß nicht funktioniert.
    Diese Clients haben dennoch die richtige IP bekommen, mutmaßlich über das Relay (so wie es soll).

    Wenn ich mir z.B. bei Windows per ipconfig die Settings anzeigen lasse, wird dort auch der MS DHCP Server angezeigt anstatt (wie ich erwarten würde) mein Router.
    Hab ich da ein Verständnisproblem?
    Großartig was falsch konfigurieren kann man da ja nicht.

    Ich bin jetzt nicht wahnsinnig tief drin im Protokoll, meine aber, dass alles korrekt läuft bei Dir. Ein neuer Client im Netz hat noch keinerlei Informationen (ich bleibe jetzt mal bewusst nur bei v4, was Du vermutlich auch meinst). Er schickt einen Broadcast auf der Suche nach "seinem" DHCP-Server, das sind dann die Logs, die Du beobachtest. Der Client kann nur das UXG-Pro erreichen, dieses reicht die Anfrage durch zum Windows-Server.

    Quote from Callahan

    Wenn ich mir z.B. bei Windows per ipconfig die Settings anzeigen lasse, wird dort auch der MS DHCP Server angezeigt anstatt (wie ich erwarten würde) mein Router.

    Das ist auch richtig so, denn Dein UXG ist ja zumindest in diesem Netz kein DHCP-Server. Ein Relay ist immer nur eine Durchreiche.

    EDIT: Falls Dich das Wording irritiert: "Relay" ist die UXG, nicht der Server.

    Ja, alles nur IPv4.
    Ich verstehe das dann so:
    - Client fragt per Broadcast in seinem Subnetz nach einem DHCP
    - das Relay (UXG) bekommt die Anfrage, reicht diese "nach hinten" weiter zum eigentlichen DHCP
    - der eigentliche DHCP gibt dem Relay eine IP (und weitere Parameter*)
    - das Relay reicht die IP (und weiteres) an den Client weiter

    *weitere Parameter:
    Außer der IP werden noch andere von mir festgelegte Infos, wie DNS, NTP, Domain usw., mitgegeben. Es scheint so, daß der DHCP auch sich selbst als Parameter einträgt (?) Was aber dann irgendwie dazu führt, daß der Client ab dann immer direkt zum DHCP will.

    Wenn das alles so stimmt, würde es das Verhalten erklären.

    Kommt das so hin?

    Quote from Callahan

    Kommt das so hin?

    Fast.

    Quote from Callahan

    - Client fragt per Broadcast in seinem Subnetz nach einem DHCP

    Er kennt sein Subnetz in diesem Moment ja noch gar nicht, sondern erfährt darüber erst etwas, wenn ein DHCP-Server geantwortet hat. Der Broadcast geht daher auf 255.255.255.255 (und auf Layer 2 zusätzlich an die MAC-Adresse FF:FF:FF:FF:FF:FF). Würde der Client sein Subnetz schon kennen, bräuchte er diesen Broadcast über den gesamte Adressraum nicht auszuführen.


    Quote from Callahan

    Es scheint so, daß der DHCP auch sich selbst als Parameter einträgt (?) Was aber dann irgendwie dazu führt, daß der Client ab dann immer direkt zum DHCP will.

    Es ist weniger ein "Eintragen" durch den DHCP-Server, ein Client merkt sich einfach die Adresse des Servers, von dem es zuletzt per DHCP Informationen erhalten hat. Irgendwann kurz vor Ablauf der Leasetime wird der Client dann gezielt bei diesem DHCP-Server wieder anfragen (per Unicast). Erst wenn dieser DHCP-Server nicht mehr antwortet, erfolgt wieder eine Anfrage per Broadcast.

    Quote from Networker

    ein Client merkt sich einfach die Adresse des Servers, von dem es zuletzt per DHCP Informationen erhalten hat

    Das wäre ja das Relay. Dennoch sehe ich im Client z.B. per ipconfig, daß die IP des MS DHCP als DHCP Server eingetragen ist, obwohl er die eigentlich nicht kennen kann.
    Die IP des DHCP Relays ist dieselbe wie die des Netz-Gateways, korrekt?

    Konkret sieht das bei mir beispielsweise so aus:



    Mein MS DHCP ist 192.168.10.254, also aus dem Netz 192.168.10.0/24. Der Client steht in 192.168.20.0/24. Die Netze sind gegeneinander geblockt.

    Deiner Erklärung folgend müsste bei DHCP-Server 192.168.20.1 stehen, tut es aber nicht.
    Oder steh ich auf dem Schlauch?

    Ich habe gerade mal ChatGPT und Wireshark bemüht. Wireshark zeigt ganz schön, was der Client (hier 192.168.20.201) so bekommt:


    Es ist einerseits irgendwie alles korrekt, andererseits auch nicht :/
    Option 54 müsste für den Client ja dann auch 192.168.20.1 sein.

    Nein muss es nicht... Das Relay ist ein Relay und nicht der DHCP Server.

    DHCP Lease renew funktioniert über Unicast. Wie soll der Client direkt mit dem DHCP Server kommunizieren, wenn der gar nicht bekannt wäre. Da würde das Relay nichts bringen.

    Zeigt wireshark doch auch so. Vielleicht mal google zur Funktionsweise befragen. Ich denke da findet sich eine ki lose website die das vernünftig erklärt.

    Verstehe Dein Verständnisproblem gerade nicht. Ich hatte Dir das oben doch schon einmal extra auch in Bezug auf die Bezeichnungen geschrieben:

    Quote from Networker

    EDIT: Falls Dich das Wording irritiert: "Relay" ist die UXG, nicht der Server.


    Quote from Callahan

    Wenn die IP vom Relay kam, sollte er dort auch nach dem Lease Renew fragen, korrekt?

    Nochmal: Das Relay macht rein gar nichts, außer auf den DHCP-Server zu verweisen. Jegliche Informationen zum Netzwerk hat der Client ausschließlich vom Server und man könnte sogar sagen, dass er vom Relay gar nichts weiß.

    Das relay ist quasi nur eine Hilfskrücke, wird im folgenden Relay Agent genannt. Die Google KI erklärt es ziemlich eindeutig:

    Ein DHCP-Relay-Agent ist ein Netzwerkgerät, das DHCP-Anfragen (Dynamic Host Configuration Protocol) von Clients in einem Subnetz weiterleitet, in dem sich kein DHCP-Server befindet, zu einem DHCP-Server in einem anderen Subnetz. Der Agent empfängt DHCP-Nachrichten (z.B. DISCOVER, REQUEST) vom Client und leitet diese an den konfigurierten DHCP-Server weiter. Nachdem der Server eine Antwort (z.B. OFFER, ACK) generiert hat, leitet der DHCP-Relay diese Antwort an den ursprünglichen Client zurück.


    Funktionsweise im Detail:

    1. 1. DHCP-Anfrage:

      Ein Client, der sich in einem Subnetz ohne DHCP-Server befindet, sendet eine DHCP-Anfrage (z.B. DHCPDISCOVER) mit einer Broadcast-Adresse, da er die IP-Adresse des Servers nicht kennt.


    2. 2. DHCP-Relay-Empfang:

      Ein DHCP-Relay-Agent, der sich im selben Subnetz wie der Client befindet, empfängt diese Broadcast-Nachricht.


    3. 3. Anpassung der Nachricht:

      Der DHCP-Relay-Agent ändert die DHCP-Nachricht, indem er seine eigene IP-Adresse als "Relay-Agent-Adresse" in der Nachricht einträgt. Er ändert auch die Zieladresse der Nachricht von der Broadcast-Adresse in die IP-Adresse des konfigurierten DHCP-Servers.


    4. 4. Weiterleitung:

      Der DHCP-Relay sendet die modifizierte DHCP-Anfrage als Unicast-Nachricht an den DHCP-Server.


    5. 5. DHCP-Antwort:

      Der DHCP-Server empfängt die Anfrage, bearbeitet sie und sendet eine Antwort (z.B. DHCPOFFER oder DHCPACK) zurück an den Relay-Agent.


    6. 6. Rücksendung der Antwort:

      Der DHCP-Relay-Agent empfängt die Antwort und leitet sie als Unicast-Nachricht an den ursprünglichen Client weiter, wobei die Adresse des Clients als Zieladresse verwendet wird.

    Quote from Networker

    "Relay" ist die UXG, nicht der Server.

    Das ist verstanden.

    Quote from Networker

    Das Relay macht rein gar nichts, außer auf den DHCP-Server zu verweisen. Jegliche Informationen zum Netzwerk hat der Client ausschließlich vom Server und man könnte sogar sagen, dass er vom Relay gar nichts weiß.

    Das kann so nicht stimmen. Der Client hat keine Möglichkeit, den DHCP Server zu erreichen, sämtliche Kommunikation wird durch die Firewall verhindert (was man auch im FW-Log sieht). Der Client MUSS seine Infos vom Relay bekommen, anders kann es nicht sein.

    Nein, tut er nicht. Ich habe Dir die Funktionsweise doch eigentlich ausführlich beschrieben... *seufzt*

    Dein Client merkt sich die Infos vom DHCP-Server. Irgendwann fragt er den Server erneut an, dieses Mal direkt, also per Unicast. Wenn das, wie in Deinem Fall, blockiert wird, fragt der Client halt wie beim allerersten Kontakt per Broadcast im gesamten Netz. Das Relay fängt diese Anfrage auf, leitet sie zum DHCP-Server weiter und dessen Antwort zurück an den Client.

    Ich weiß ehrlich nicht, wie ich es noch einfacher beschreiben könnte.

    Quote from DoPe

    Funktionsweise im Detail:


    .......

    Alle 6 Schritte sind klar. Hier wird erklärt, wie der Client initial seine IP bekommt. Meine Unklarheit beginnt danach . . . dann will der Client ja direkt mit dem DHCP kommunizieren.

    Quote from Networker

    Irgendwann fragt er den Server erneut an, dieses Mal direkt, also per Unicast. Wenn das, wie in Deinem Fall, blockiert wird, fragt der Client halt wie beim allerersten Kontakt per Broadcast im gesamten Netz. Das Relay fängt diese Anfrage auf, leitet sie zum DHCP-Server weiter und dessen Antwort zurück an den Client.

    Ok, evtl. fällt der Groschen langsam . . . d.h. es ist (im Falle des Release renew) ein zweistufes Verfahren?

    - Client braucht Lease Renew
    - 1) Client fragt DHCP direkt / per Unicast
    - DHCP ist nicht erreichbar
    - 2) Client fragt nun per Broadcast
    - Relay antwortet und holt vom DHCP das Lease Renew

    So?

    Halleluja . . . so ergibt es Sinn und und erklärt das Verhalten . . . also eigentlich gar nicht so kompliziert 8o

    Dann jetzt die Bonus-Frage:
    Nun wäre es ja sauberer, entsprechende Firewall-Regeln (Port 67/68 UDP) zum DHCP zu erstellen, um den Clients das Unicast zu ermöglichen und die Broadcasts etwas einzudämmen, oder?

    Korrekt, Leasetime ist je nach Subnetz zwischen 1 und 7 Tage bei ca. 60-70 DHCP-Clients.
    Für die Performance dann sicherlich zu vernachlässigen, hätte dann nur einen kosmetischen Effekt, weil das nicht mehr im Log auftaucht.
    Das überleg ich mir dann noch.

  • Callahan July 23, 2025 at 12:35 AM

    Set the label from offen to erledigt

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login