22
Kein DHCP außerhalb von VMs
Hallo,
Ich habe bei mir einen Hyper-V Server mit Windows Server 2025 Datacenter aufgesetzt, darauf läuft unter anderem eine VM (ebenfalls Server 2025 Datacenter) als Domönencontroller und zusätzlich soll dort ein DHCP-Server laufen.
Nun habe ich das Problem, dass der DHCP zwar IPs an andere VMs vergeben kann, jedoch nicht im restlichen Netzwerk außerhalb des Hypervisors.
Es wurde weder der DHCP-Wächter noch der Roter-Wächter für die VM aktiviert. Der vSwitch, mit dem die VM verbunden ist, ist als externes Netzwerk mit gemeinsamer Verwendung konfiguriert.
Das Netz ist mit 172.16.0.0/16 konfiguriert und der DHCP-Bereich soll 172.16.254.0-255 beinhalten. Die DHCP-Optionen für Gateway, DNS und Broadcast (172.16.255.255) wurden als Serveroptionen konfiguriert und sind auch im IP-Bereich vorhanden. Richtlinien wurden keine konfiguriert.
Sonst ist im Netzwerk nichts besonderes vorhanden, keine VLANs, keine extra Firewall (außer die Standard-Firewall auf dem Speedport) und auch kein weiterer DHCP (wurde am Speedport deaktiviert).
Hat jemand schon mal ein solches Problem gehabt und vielleicht eine Lösung parat oder ist das evtl. ein Bug aktueller Updates?
Ich habe bei mir einen Hyper-V Server mit Windows Server 2025 Datacenter aufgesetzt, darauf läuft unter anderem eine VM (ebenfalls Server 2025 Datacenter) als Domönencontroller und zusätzlich soll dort ein DHCP-Server laufen.
Nun habe ich das Problem, dass der DHCP zwar IPs an andere VMs vergeben kann, jedoch nicht im restlichen Netzwerk außerhalb des Hypervisors.
Es wurde weder der DHCP-Wächter noch der Roter-Wächter für die VM aktiviert. Der vSwitch, mit dem die VM verbunden ist, ist als externes Netzwerk mit gemeinsamer Verwendung konfiguriert.
Das Netz ist mit 172.16.0.0/16 konfiguriert und der DHCP-Bereich soll 172.16.254.0-255 beinhalten. Die DHCP-Optionen für Gateway, DNS und Broadcast (172.16.255.255) wurden als Serveroptionen konfiguriert und sind auch im IP-Bereich vorhanden. Richtlinien wurden keine konfiguriert.
Sonst ist im Netzwerk nichts besonderes vorhanden, keine VLANs, keine extra Firewall (außer die Standard-Firewall auf dem Speedport) und auch kein weiterer DHCP (wurde am Speedport deaktiviert).
Hat jemand schon mal ein solches Problem gehabt und vielleicht eine Lösung parat oder ist das evtl. ein Bug aktueller Updates?
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: 671124
Url: https://administrator.de/forum/kein-dhcp-ausserhalb-von-vms-671124.html
Ausgedruckt am: 04.02.2025 um 14:02 Uhr
22 Kommentare
Neuester Kommentar
Moin,
ist denn die Netzwerkkarte, an dem das restliche Netz hängt dem vSwitch hinzugefügt?
Gruß
Looser
ist denn die Netzwerkkarte, an dem das restliche Netz hängt dem vSwitch hinzugefügt?
Gruß
Looser
1
Ja ist sie. Sämtliche kommuniktaion wie SMB, AD usw. funktioniert ja, wenn ich den Geräten manuell eine IP vergebe.
Nur DHCP macht probleme.
ich habe es jetzt mit Wireshark mal noch genauer untersucht:
- die DHCP-Discover Pakete kommen an und der Server antwortet auch mit einem DHCP-Offer
- es kommt nie zu einem DHCP-Request oder DHCP-ACK mit externen geräten
- es funktioniert reibungslos, wenn eine VM den DHCP nach einer IP fragt
- es werden keine Leases angezeigt, nur die von der einen VM die eben erfolgreich eine IP per DHCP bekommen hat
Nur DHCP macht probleme.
ich habe es jetzt mit Wireshark mal noch genauer untersucht:
- die DHCP-Discover Pakete kommen an und der Server antwortet auch mit einem DHCP-Offer
- es kommt nie zu einem DHCP-Request oder DHCP-ACK mit externen geräten
- es funktioniert reibungslos, wenn eine VM den DHCP nach einer IP fragt
- es werden keine Leases angezeigt, nur die von der einen VM die eben erfolgreich eine IP per DHCP bekommen hat
Ich habe es jetzt mit Wireshark mal noch genauer untersucht:
Und das auch richtig? 🤔 (Siehe zu der Thematik auch HIER)
Ich habs mal so gemacht, zuerst hatte ich nur den Filter "dhcp", hat aber keinen sichtbaren unterschied gemacht.
dhcp.pcapng.gz
1-8: 2x Verbindung der VM (läuft)
8-32: 3x Verbindungsversuch mit meinem Smartphone
liegt auch nicht am WLAN, Geräte die per LAN verbunden sind zeigen das gleiche bild.
Ich habe Wireshark auf dem Hypervisor ausgeführt und die Netzwerkbrücke mitschneiden lassen (vEthernet (Default Virtual Switch))
Es erscheint mir so, als würden die DHCP-Pakete vom Server nicht bei den Clients ankommen.
dhcp.pcapng.gz
1-8: 2x Verbindung der VM (läuft)
8-32: 3x Verbindungsversuch mit meinem Smartphone
liegt auch nicht am WLAN, Geräte die per LAN verbunden sind zeigen das gleiche bild.
Ich habe Wireshark auf dem Hypervisor ausgeführt und die Netzwerkbrücke mitschneiden lassen (vEthernet (Default Virtual Switch))
Es erscheint mir so, als würden die DHCP-Pakete vom Server nicht bei den Clients ankommen.
Ja, wenn ich auf einem anderen Client mit Wireshark beobachte sehe ich ausschließlich die Discover-Pakete und keinerlei antworten vom server.
Ich tippe mal auf eine fehlerhafte DHCP Config.
Am Besten damit nochmal von vorne beginnen.
Edit: Du kannst zuerst auch nochmal den DHCP Bereich löschen und neu definieren.
Aber wozu brauchst Du so ein riesiges Netz?
Am Besten damit nochmal von vorne beginnen.
Edit: Du kannst zuerst auch nochmal den DHCP Bereich löschen und neu definieren.
Aber wozu brauchst Du so ein riesiges Netz?
Bedenke das nur die Pakete bis zum "Discover" Broadcasts sind (255.255.255.255 bzw. Mac ff:ff:ff:ff:ff:ff)! Danach sind es Unicasts die ohne einen Mirror (Spiegel) Port im Switch sonst nicht zu sehen sind sofern das Broadcast Flag am Client nicht gesetzt ist, weil der logischerweise dann Mac basierend forwardet. Das gilt zumindestens für fremde DHCP.
Nur auf dem Wireshark PC selber kannst du den vollständigen DHCP Verlauf ohne Mirror Port sehen. Hast du das bedacht?
Das Verhalten mit oder ohne Broadcast Flag im Client ist unterschiedlich. Einmal nur Broadcast einmal der Wechsel auf Unicast.
Letzteres ist aus Sicherheitsgründen bei allen aktuellen DHCP Clients aktiviert damit man nicht netzwerkweit zugeteilte IP Adressen über den Broadcast "abschnorcheln" kann.
Ansonsten wie @Looser27 oben schon sagt ggf. mal den DHCP Server temporär deaktivieren und einen einfachen Test DHCP auf deinem Client PC aktivieren und checken oder der sich anders verhält mit den Clients.
https://www.dhcpserver.de/cms/
Wenn ja, würde das eine Fehlkonfig sicher verifizieren.
Nur auf dem Wireshark PC selber kannst du den vollständigen DHCP Verlauf ohne Mirror Port sehen. Hast du das bedacht?
Das Verhalten mit oder ohne Broadcast Flag im Client ist unterschiedlich. Einmal nur Broadcast einmal der Wechsel auf Unicast.
Letzteres ist aus Sicherheitsgründen bei allen aktuellen DHCP Clients aktiviert damit man nicht netzwerkweit zugeteilte IP Adressen über den Broadcast "abschnorcheln" kann.
Ansonsten wie @Looser27 oben schon sagt ggf. mal den DHCP Server temporär deaktivieren und einen einfachen Test DHCP auf deinem Client PC aktivieren und checken oder der sich anders verhält mit den Clients.
https://www.dhcpserver.de/cms/
Wenn ja, würde das eine Fehlkonfig sicher verifizieren.
Hast du einen Switch im Einsatz? Evtl. auf dem switch so etwas wie DHCP-Snooping aktiv?
1Zitat von @Looser27:
Ich tippe mal auf eine fehlerhafte DHCP Config.
Am Besten damit nochmal von vorne beginnen.
Ich tippe mal auf eine fehlerhafte DHCP Config.
Am Besten damit nochmal von vorne beginnen.
Aber dann würde es doch auch bei den VMs nicht funktionieren?
Habe nur eine Basic-DHCP config und den bereich gerade nochmal neu angelegt: keine veränderung.
Prinzipell funktioniert der ja, aber die Antwort-Pakete vom DHCP-Server verlassen den vSwitch nicht ins physische Netzwerk.
Edit: Du kannst zuerst auch nochmal den DHCP Bereich löschen und neu definieren.
Aber wozu brauchst Du so ein riesiges Netz?
Aber wozu brauchst Du so ein riesiges Netz?
Zur besseren Übersicht im Firmennetz. Ob ich nun ein /16 oder /24 Netz habe ist doch für die Funktionalität des DHCP unerheblich. Derzeit sind nur wenige Geräte im Netz, das wird sich aber noch ändern. Es soll später ja auch noch eine Filiale mittels Site-to-Site VPN angebunden werden.
Anderer Ansatz: Ist die Config auf dem Switch sauber, d.h. keine Altlasten wie VLAN's etc?
Den Switch evtl. mal resetten und als dummen unmanaged Switch laufen lassen.
Den Switch evtl. mal resetten und als dummen unmanaged Switch laufen lassen.
1Zitat von @aqui:
Bedenke das nur die Pakete bis zum "Discover" Broadcasts sind (255.255.255.255 bzw. Mac ff:ff:ff:ff:ff:ff)! Danach sind es Unicasts die ohne einen Mirror (Spiegel) Port im Switch sonst nicht zu sehen sind sofern das Broadcast Flag am Client nicht gesetzt ist, weil der logischerweise dann Mac basierend forwardet. Das gilt zumindestens für fremde DHCP.
Nur auf dem Wireshark PC selber kannst du den vollständigen DHCP Verlauf ohne Mirror Port sehen. Hast du das bedacht?
Das Verhalten mit oder ohne Broadcast Flag im Client ist unterschiedlich. Einmal nur Broadcast einmal der Wechsel auf Unicast.
Letzteres ist aus Sicherheitsgründen bei allen aktuellen DHCP Clients aktiviert damit man nicht netzwerkweit zugeteilte IP Adressen über den Broadcast "abschnorcheln" kann.
Ansonsten wie @Looser27 oben schon sagt ggf. mal den DHCP Server temporär deaktivieren und einen einfachen Test DHCP auf deinem Client PC aktivieren und checken oder der sich anders verhält mit den Clients.
https://www.dhcpserver.de/cms/
Wenn ja, würde das eine Fehlkonfig sicher verifizieren.
Bedenke das nur die Pakete bis zum "Discover" Broadcasts sind (255.255.255.255 bzw. Mac ff:ff:ff:ff:ff:ff)! Danach sind es Unicasts die ohne einen Mirror (Spiegel) Port im Switch sonst nicht zu sehen sind sofern das Broadcast Flag am Client nicht gesetzt ist, weil der logischerweise dann Mac basierend forwardet. Das gilt zumindestens für fremde DHCP.
Nur auf dem Wireshark PC selber kannst du den vollständigen DHCP Verlauf ohne Mirror Port sehen. Hast du das bedacht?
Das Verhalten mit oder ohne Broadcast Flag im Client ist unterschiedlich. Einmal nur Broadcast einmal der Wechsel auf Unicast.
Letzteres ist aus Sicherheitsgründen bei allen aktuellen DHCP Clients aktiviert damit man nicht netzwerkweit zugeteilte IP Adressen über den Broadcast "abschnorcheln" kann.
Ansonsten wie @Looser27 oben schon sagt ggf. mal den DHCP Server temporär deaktivieren und einen einfachen Test DHCP auf deinem Client PC aktivieren und checken oder der sich anders verhält mit den Clients.
https://www.dhcpserver.de/cms/
Wenn ja, würde das eine Fehlkonfig sicher verifizieren.
Dachte ich eigentlich auch, aber bei meinem mitschnitt sind die anderen Pakete ebenfalls Broadcast oder sieht das dann nur so aus?:
Wenn ich an einem Client selbst mitschneide und versuche mit diesem eine IP per DHCP zu beziehen sehe ich auch dort keine Antwort vom server, nur die ausgehenden Discover Pakete.
Wenn ich zum Test den DHCP am speedport wieder aktiviere sehe ich von diesem die entsprechenden Antwort-Pakete vom Speedport auch.
Es ist auch egal welcher Client, keiner bekommt eine IP außer eine andere VM auf dem Hypervisor.
Zitat von @Delta9:
Hast du einen Switch im Einsatz? Evtl. auf dem switch so etwas wie DHCP-Snooping aktiv?
Hast du einen Switch im Einsatz? Evtl. auf dem switch so etwas wie DHCP-Snooping aktiv?
Nein, im moment nicht. Es ist aktuell nur der interne Switch vom Speedport vorhanden. Das filtert doch nicht etwa DHCP-Pakete fremder DHCP-Server raus, oder? :D
Broadcast oder sieht das dann nur so aus?:
Leider kann man darauf nicht zielführend antworten weil du unten im WS den Inhalt nicht geöffnet hast um zu sehen ob das BC Flag gesetzt ist oder nicht. Siehe Beispiel oben. 
aber die Antwort-Pakete vom DHCP-Server verlassen den vSwitch nicht ins physische Netzwerk.
Das bedeutet dann, wie Kollege @Looser27 schon sagt, das die NIC und/oder der dort ggf. angeschlossene physische Switch falsch an den vSwitch angebunden sind!! Vermutlich taggst du hier etwas fälschlicherweise oder der Port steckt in einem falschen VLAN?Oder, solltest du einen dummen, ungemanagten externen Switch haben tagged der vSwitch fälschlicherweise was der Externe nicht versteht.
Auch das kannst du recht einfach überprüfen wenn du den Wireshark einmal direkt an die NIC ins externe Netzwerk klemmst. Dort kannst du checken ob dort VLAN Tags mitkommen oder nicht bei den DHCP Frames. (Beispiel hier mit ID 14)
Nein, im moment nicht. Es ist aktuell nur der interne Switch vom Speedport vorhanden.
Nimm mal, wie von @aqui vorgeschlagen nen dummen unmanaged Switch vom Grabbeltisch und häng den dazwischen.
Zitat von @aqui:
Oder, solltest du einen dummen, ungemanagten externen Switch haben tagged der vSwitch fälschlicherweise was der Externe nicht versteht.
Auch das kannst du recht einfach überprüfen wenn du den Wireshark einmal direkt an die NIC ins externe Netzwerk klemmst. Dort kannst du checken ob dort VLAN Tags mitkommen oder nicht bei den DHCP Frames. (Beispiel hier mit ID 14)
aber die Antwort-Pakete vom DHCP-Server verlassen den vSwitch nicht ins physische Netzwerk.
Das bedeutet dann das die NIC und/oder der dort ggf. angeschlossene physische Switch falsch an den vSwitch angebunden sind!! Vermutlich taggst du hier etwas fälschlicherweise oder der Port steckt in einem falschen VLAN?Oder, solltest du einen dummen, ungemanagten externen Switch haben tagged der vSwitch fälschlicherweise was der Externe nicht versteht.
Auch das kannst du recht einfach überprüfen wenn du den Wireshark einmal direkt an die NIC ins externe Netzwerk klemmst. Dort kannst du checken ob dort VLAN Tags mitkommen oder nicht bei den DHCP Frames. (Beispiel hier mit ID 14)
Wenn ich Wireshark direkt auf den NIC schalte statt dem vEthernet sehe ich auch auschließlich die ankommenden discover pakete von den clients und keine antworten vom DHCP Server
von VLANs keine Spur, hab auch nochmal bei der netzwerk config der VM geschaut, da ist VLAN deaktiviert. Habe ich auch hier nie Konfiguriert. der Hyper-V wurde auch von grund auf neu von mir eingerichtet, es gibt hier keine Altgeräte mit unbekannter config oder so, VLANs waren nie im Einsatz und das Speedport kann damit ohnehin nichts anfangen.
Zitat von @Looser27:
Nimm mal, wie von @aqui vorgeschlagen nen dummen unmanaged Switch vom Grabbeltisch und häng den dazwischen.
Nein, im moment nicht. Es ist aktuell nur der interne Switch vom Speedport vorhanden.
Nimm mal, wie von @aqui vorgeschlagen nen dummen unmanaged Switch vom Grabbeltisch und häng den dazwischen.
Das werd ich morgen mal probieren.
Ich habe am Server noch einen zweiten NIC, ich versuch mal meinen Laptop direkt da ran zu hängen und das mit dem zu konfigurieren, vielleicht geht das ja.
und keine antworten vom DHCP Server
Könnte auch sein das die Server VM dann fälschlicherweise selber tagged und der vSwitch das durchreicht an die NIC. Das müsste man dann aber im WS sehen weil diese Frames dann mit einem VLAN Tag kämen.Natürlich nur wenn der WS PC im Promiscous Mode arbeitet und die Tags anzeigt, sonst siehst du sie nicht!
https://wiki.wireshark.org/capturesetup/vlan
Ist der DHCP-Server in der VM denn überhaupt an das richtige Interface gebunden und der Haken dort gesetzt (Add/Remove Bindings)?
Gruß goldcap
Gruß goldcap
1Zitat von @Goldcap:
Ist der DHCP-Server in der VM denn überhaupt an das richtige Interface gebunden und der Haken dort gesetzt (Add/Remove Bindings)?
Gruß goldcap
Ist der DHCP-Server in der VM denn überhaupt an das richtige Interface gebunden und der Haken dort gesetzt (Add/Remove Bindings)?
Gruß goldcap
Ja, das habe ich auch bereits überprüft.
Zitat von @aqui:
Natürlich nur wenn der WS PC im Promiscous Mode arbeitet und die Tags anzeigt, sonst siehst du sie nicht!
https://wiki.wireshark.org/capturesetup/vlan
und keine antworten vom DHCP Server
Könnte auch sein das die Server VM dann fälschlicherweise selber tagged und der vSwitch das durchreicht an die NIC. Das müsste man dann aber im WS sehen weil diese Frames dann mit einem VLAN Tag kämen.Natürlich nur wenn der WS PC im Promiscous Mode arbeitet und die Tags anzeigt, sonst siehst du sie nicht!
https://wiki.wireshark.org/capturesetup/vlan
Ich habe in der VM nichts mit VLANs konfiguriert, das macht ein Windows Server doch nicht in der Standard-Config.
Firewall Profil und Freigaben der VM auf dem Interface gecheckt?
1Zitat von @RamboNo5:
Ich habe am Server noch einen zweiten NIC, ich versuch mal meinen Laptop direkt da ran zu hängen und das mit dem zu konfigurieren, vielleicht geht das ja.
Ich habe am Server noch einen zweiten NIC, ich versuch mal meinen Laptop direkt da ran zu hängen und das mit dem zu konfigurieren, vielleicht geht das ja.
Am zweiten NIC mit dem Laptop direkt dran funktioniert es.
Scheinbar ist es wirklich das Speedport, welches die DHCP-Pakete anderer DHCP-Server raus filtert. Finde dazu aber auch keinerlei Optionen im Speedport.
Also sollte sich das Problem wohl dann gelöst sein, wenn ich morgen einen einfachen Switch da ran hänge...
Danke für eure Denkanstöße
Ja
Speedports waren ja eigentlich schon immer crapware, am besten gleich entsorgen/verschenken.
