46
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 X (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: 12.03.2025 um 11:03 Uhr
46 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 @151434:
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
Zitat von @151434:
Firewall Profil und Freigaben der VM auf dem Interface gecheckt?
Firewall Profil und Freigaben der VM auf dem Interface gecheckt?
Ja
Speedports waren ja eigentlich schon immer crapware, am besten gleich entsorgen/verschenken.
1Scheinbar ist es wirklich das Speedport, welches die DHCP-Pakete anderer DHCP-Server raus filtert
Wenig verwunderlich bei so einer Plaste Gurke... Der "DHCP Snooping" Einwand von oben!Also sollte sich das Problem wohl dann gelöst sein
Wie kann ich einen Beitrag als gelöst markieren?Zitat von @151434:
Speedports waren ja eigentlich schon immer crapware, am besten gleich entsorgen/verschenken.
Speedports waren ja eigentlich schon immer crapware, am besten gleich entsorgen/verschenken.
Leider bin ich hier noch eine Weile auf ein solches Teil angewiesen wegen Hybrid-Verbindung (DSL ist zu langsam und was anderes gibt es vor Ort nicht).
Zitat von @aqui:
Scheinbar ist es wirklich das Speedport, welches die DHCP-Pakete anderer DHCP-Server raus filtert
Wenig verwunderlich bei so einer Plaste Gurke... Der "DHCP Snooping" Einwand von oben!Naja, WLAN Geräte würden dann eben dennoch nicht funktionieren, aber das kann ich wohl Zukünfig umgehen. Für reinen Internetzugang reicht das, da die Geräte dann eine IPv6 bekommen, das lässt sich am speedport ja ebenfalls nicht deaktivieren.
Wenn das morgen mit dem anderen Switch klappt mach ich das
Leider bin ich hier noch eine Weile auf ein solches Teil angewiesen
Nöö, kann jeder popelige Dual WAN Router oder Firewall auch. Leider ein weit verbreiteter Irrglaube.da die Geräte dann eine IPv6 bekommen, das lässt sich am speedport ja ebenfalls nicht deaktivieren.
Macht ja auch Sinn wenn man an einem Dual Stack Provider hängt. Warum sollte man das deaktivieren wollen?! 🤔Dann sind wir mal auf morgen gespannt...
Zitat von @aqui:
Leider bin ich hier noch eine Weile auf ein solches Teil angewiesen
Nöö, kann jeder popelige Dual WAN Router oder Firewall auch. Leider ein weit verbreiteter Irrglaube.Leider klappt das nicht so einfach wegen gelockter SIM und es muss auch VoIP funktionieren. Hab da schonmal ewig recherche betrieben, zumindest das Bonding wird mit 3rd-party-hardware/software im Telekom netz schwierig, redundanz bekommt man easy hin, aber das ist nicht der grund überhaupt hybrid gewählt zu haben.
da die Geräte dann eine IPv6 bekommen, das lässt sich am speedport ja ebenfalls nicht deaktivieren.
Macht ja auch Sinn wenn man an einem Dual Stack Provider hängt. Warum sollte man das deaktivieren wollen?! 🤔Dann sind wir mal auf morgen gespannt...
weil sich das interne netz mit IPv6 nich so geil konfigurieren lässt außer man setzt voll auf DNS. Das würde ich gern zusätzlich machen wenn der DHCP ordentlich läuft und somit die DNS Einträge am DC automatisch aktualisiert werden.
Ich persönlich komm aber beser klar mir mal ne v4 IP zu merken anhand der ich auch gleich noch sehen kann was das für ein gerätetyp sein soll wenns ordentlich konfiguriert ist.
Extern v6 ist ja super und im home-bereich ist das auch für die internen netze ok, aber im Firmennetz find ich das weniger geil wenn jedes gerät ne GUA bekommt, mit vernünfig verwalteter ULA gern, aber bitte nicht über das Speedport. Geht ja auch darum z.B. den internen DNS Server anzukündigen, da nützt mir das gar nix wenn das Speedport einfach irgendwas vergibt was die Telekom so toll findet.
fd00:bade:affe:cafe:: ist doch einfach merkbar! 🤣
https://sophiedogg.com/funny-ipv6-words/
https://danrl.com/ipv6/
https://sophiedogg.com/funny-ipv6-words/
https://danrl.com/ipv6/
Fehlt ja nur noch der Haken am Beitrag.
1
Zitat von @RamboNo5:
Extern v6 ist ja super und im home-bereich ist das auch für die internen netze ok, aber im Firmennetz find ich das weniger geil wenn jedes gerät ne GUA bekommt, mit vernünfig verwalteter ULA gern, aber bitte nicht über das Speedport. Geht ja auch darum z.B. den internen DNS Server anzukündigen, da nützt mir das gar nix wenn das Speedport einfach irgendwas vergibt was die Telekom so toll findet.
Extern v6 ist ja super und im home-bereich ist das auch für die internen netze ok, aber im Firmennetz find ich das weniger geil wenn jedes gerät ne GUA bekommt, mit vernünfig verwalteter ULA gern, aber bitte nicht über das Speedport. Geht ja auch darum z.B. den internen DNS Server anzukündigen, da nützt mir das gar nix wenn das Speedport einfach irgendwas vergibt was die Telekom so toll findet.
Ein Speedport hat in einem Firmennetz noch weniger verloren als eine Fritte. Die Fritte ist ja noch einigermaßen Firmentauglich, wenn man keine allzu hohen Ansprüche hat, aber Speedports gehören gleich in die Tonne, so kastriert wie die sind.
lks
1Fehlt ja nur noch der Haken am Beitrag.
Ob Rambo denn überhaupt Foren FAQs liest?? 🤣Wie kann ich einen Beitrag als gelöst markieren?
1
Also ich habe jetz einen dummen switch im netzwerk und auch da funktioniert es nicht über die NIC vom Mainboard. Über die PCIe Netzwerkkarte funktioniert es. Allerdings sollte es schon über die vom MB laufen, da diese auch 2.5G unterstützt (für die Anbindung ans Intranet).
Ich habe auch nochmals verifiziert, dass nirgendwo was mit VLANs gesetzt ist, das habe ich auf den Schnittstellen sogar deaktiviert und nichts ändert sich.
Das Problem ist also leider noch nicht gelößt und das Speedport auch nicht die Ursache, auch wenn es erst danach aussah. Wäre ja auch irgendwie zu einfach gewesen...
Würde ich schon gern raus hauen aber schwierig in der konstellation hier.
Jetzt hab ich sie aber ausschließlich als Gateway hinter einer pfSense laufen, damit ist's ziemlich egal was die kann oder nicht.
Angenommen den Windows-DHCP bekomm ich gar nicht mehr zum laufen und sonst hat hier auch niemand eine weitere Idee: wäre es möglich die DNS-Updates auch von der pfSense aus zum Windows-DNS-Server zu schieben?
Oder das umgehen indem ich im Windows-DNS einfach eine entsprechende weiterleitung einrichte? Könnte das Probleme verursachen, wenn ich den Windows-DNS als Primären DNS im Netzwerk verteile?
Ich habe auch nochmals verifiziert, dass nirgendwo was mit VLANs gesetzt ist, das habe ich auf den Schnittstellen sogar deaktiviert und nichts ändert sich.
Das Problem ist also leider noch nicht gelößt und das Speedport auch nicht die Ursache, auch wenn es erst danach aussah. Wäre ja auch irgendwie zu einfach gewesen...
Zitat von @Lochkartenstanzer:
Ein Speedport hat in einem Firmennetz noch weniger verloren als eine Fritte. Die Fritte ist ja noch einigermaßen Firmentauglich, wenn man keine allzu hohen Ansprüche hat, aber Speedports gehören gleich in die Tonne, so kastriert wie die sind.
lks
Ein Speedport hat in einem Firmennetz noch weniger verloren als eine Fritte. Die Fritte ist ja noch einigermaßen Firmentauglich, wenn man keine allzu hohen Ansprüche hat, aber Speedports gehören gleich in die Tonne, so kastriert wie die sind.
lks
Würde ich schon gern raus hauen aber schwierig in der konstellation hier.
Jetzt hab ich sie aber ausschließlich als Gateway hinter einer pfSense laufen, damit ist's ziemlich egal was die kann oder nicht.
Angenommen den Windows-DHCP bekomm ich gar nicht mehr zum laufen und sonst hat hier auch niemand eine weitere Idee: wäre es möglich die DNS-Updates auch von der pfSense aus zum Windows-DNS-Server zu schieben?
Oder das umgehen indem ich im Windows-DNS einfach eine entsprechende weiterleitung einrichte? Könnte das Probleme verursachen, wenn ich den Windows-DNS als Primären DNS im Netzwerk verteile?
Moment.....
Die Info ist neu:
Kannst Du mal bitte ein Bild machen, was an welcher Stelle wie zusammengesteckt ist......?
Gruß
Looser
Die Info ist neu:
Jetzt hab ich sie aber ausschließlich als Gateway hinter einer pfSense laufen, damit ist's ziemlich egal was die kann oder nicht.
Kannst Du mal bitte ein Bild machen, was an welcher Stelle wie zusammengesteckt ist......?
Gruß
Looser
2Zitat von @Looser27:
Moment.....
Die Info ist neu:
Kannst Du mal bitte ein Bild machen, was an welcher Stelle wie zusammengesteckt ist......?
Gruß
Looser
Moment.....
Die Info ist neu:
Jetzt hab ich sie aber ausschließlich als Gateway hinter einer pfSense laufen, damit ist's ziemlich egal was die kann oder nicht.
Kannst Du mal bitte ein Bild machen, was an welcher Stelle wie zusammengesteckt ist......?
Gruß
Looser
Das ist auch erst neu so eingerichtet, pfSense hab ich im moment auch nur laufen um das Speedport zu isolieren und später auch noch für z.B. vpn.
Habe es mal schematisch dargestellt:
Das kuriose daran: Wenn ich einen DHCP auf der pfSense laufen lasse klappt das auf beiden NICs
Ein neu installieren des Windows-DHCP hat auch nichts verändert.
EDIT: Im Bild sollte natürlich "DHCP" und nicht "SHCP" stehen :D
Ich hab jetzt einfach nur die pfSense als DHCP-Relay eingerichtet und es funktioniert. Keine Ahnung was hier der Fehler sein soll.
Zitat von @RamboNo5:
Ich hab jetzt einfach nur die pfSense als DHCP-Relay eingerichtet und es funktioniert. Keine Ahnung was hier der Fehler sein soll.
Ich hab jetzt einfach nur die pfSense als DHCP-Relay eingerichtet und es funktioniert. Keine Ahnung was hier der Fehler sein soll.
Kann es sein, daß die der switch nicht direkt mti dem DC verbunden ist, sondern die pfsene da noch dazwischenklemmt und die DHCP-Paket rausfiltert?
lks
Zitat von @Lochkartenstanzer:
Kann es sein, daß die der switch nicht direkt mti dem DC verbunden ist, sondern die pfsene da noch dazwischenklemmt und die DHCP-Paket rausfiltert?
lks
Kann es sein, daß die der switch nicht direkt mti dem DC verbunden ist, sondern die pfsene da noch dazwischenklemmt und die DHCP-Paket rausfiltert?
lks
Nein, die pfSense VM ist nur neben dem DC im gleichen Subnetz (auf der Intranet-Schnitstelle) und wenn diese Ausgeschaltet ist habe ich wieder das gleiche verhalten wie zuvor.
Also selbst wenn nur der DC aktiv ist und ich meinen Laptop direkt am server an die 2,5G-Schnitstelle anschließe funktioniert DHCP nicht. Wenn ich das gleiche an der anderen Schnitstelle mache klappt es.
Keine Ahnung was hier der Fehler sein soll.
Das zeigt eindeutig das die virtuelle NIC des DC/DHCP nicht an den vSwitch adaptiert ist sondern in einem separaten (gerouteten) Segment liegt. Wie oben schon vermutet besteht dann keine Layer 2 Connectivity so das die DHCP Broadcasts nicht ankommen.Die DHCP Relay Funktion überwindet diese Restriktion um DHCP Broadcasts über 2 Router Interfaces übertragen zu können. Dabei ersetzt der Router mit der Relay Funktion die ursprüngliche (Client) Absenderadresse mit seiner eigenen und forwardet den DHCP Request an den Server. Der antwortet dann dem Router (Relay) und der forwardet es dann letztendlich zum Client. So erreicht man das ein zentraler DHCP Server auch geroutete IP Segmente bedienen kann.
Das dieser falsche Workaround funktioniert zeigt eindeutig das entweder die pfSense falsch oder fehlerhaft eingerichtet wurde und hier mit 2 separaten, gerouteten Netzwerk Interfaces arbeitet oder die NIC des Server falsch an den vSwitch angebunden wurde! Es besteht ja de facto keine Layer 2 Verbindung im Client/Server Netz.
Da es mit der falschen Konfig eines DHCP Relays funktioniert, ist es wahrscheinlicher das die pfSense hier falsch im Bereich ihres LAN Interfaces konfiguriert wurde!
Interessant dürfte das Setup sein wenn man den Server testweise einmal in den DHCP Client Mode versetzt und den DHCP Server auf der pfSense aktiviert. Der Server sollte dann keine IP bekommen auch wenn die Clients im Netz entsprechende IPs bekommen. Das verifiziert dann das die vNIC des Server nicht korrekt im selben L2 Netz am vSwitch hängt sondern separat isoliert an einem 2ten Port der Firewall ohne Verbindung ins Client Netz. Letztlich also eine falsche Firewall Interface Konfig und/oder einen falsche Zuordnung im Layer 2 dieser Interfaces auf dem vSwitch.
Ohne das Setup genau zu kennen kann man hier aber nur im freien Fall raten...
Das der pfSense DHCP und der des DC Servers niemals parallel arbeiten dürfen sollte auch klar sein. Hier gilt das Highlander Prinzip: "Es kann nur einen geben!"
Beispiele einer virtualisierten Firewall in einer VLAN Umgebung sind z.B. hier geschildert
Pfsense in Proxmox als Router
VLAN mit Cisco SG220, ESXIund Pfsense
Zitat von @aqui:
Das zeigt eindeutig das die virtuelle NIC des DC/DHCP nicht an den vSwitch adaptiert ist sondern in einem separaten (gerouteten) Segment liegt. Wie oben schon vermutet besteht dann keine Layer 2 Connectivity so das die DHCP Broadcasts nicht ankommen.
Die DHCP Relay Funktion überwindet diese Restriktion um DHCP Broadcasts über 2 Router Interfaces übertragen zu können. Dabei ersetzt der Router mit der Relay Funktion die ursprüngliche (Client) Absenderadresse mit seiner eigenen und forwardet den DHCP Request an den Server. Der antwortet dann dem Router (Relay) und der forwardet es dann letztendlich zum Client. So erreicht man das ein zentraler DHCP Server auch geroutete IP Segmente bedienen kann.
Das dieser falsche Workaround funktioniert zeigt eindeutig das entweder die pfSense falsch oder fehlerhaft eingerichtet wurde und hier mit 2 separaten, gerouteten Netzwerk Interfaces arbeitet oder die NIC des Server falsch an den vSwitch angebunden wurde! Es besteht ja de facto keine Layer 2 Verbindung im Client/Server Netz.
Da es mit der falschen Konfig eines DHCP Relays funktioniert, ist es wahrscheinlicher das die pfSense hier falsch im Bereich ihres LAN Interfaces konfiguriert wurde!
Interessant dürfte das Setup sein wenn man den Server testweise einmal in den DHCP Client Mode versetzt und den DHCP Server auf der pfSense aktiviert. Der Server sollte dann keine IP bekommen auch wenn die Clients im Netz entsprechende IPs bekommen. Das verifiziert dann das die vNIC des Server nicht korrekt im selben L2 Netz am vSwitch hängt sondern separat isoliert an einem 2ten Port der Firewall ohne Verbindung ins Client Netz. Letztlich also eine falsche Firewall Interface Konfig und/oder einen falsche Zuordnung im Layer 2 dieser Interfaces auf dem vSwitch.
Ohne das Setup genau zu kennen kann man hier aber nur im freien Fall raten...
Das der pfSense DHCP und der des DC Servers niemals parallel arbeiten dürfen sollte auch klar sein. Hier gilt das Highlander Prinzip: "Es kann nur einen geben!"
Beispiele einer virtualisierten Firewall in einer VLAN Umgebung sind z.B. hier geschildert
Pfsense in Proxmox als Router
VLAN mit Cisco SG220, ESXIund Pfsense
Das zeigt eindeutig das die virtuelle NIC des DC/DHCP nicht an den vSwitch adaptiert ist sondern in einem separaten (gerouteten) Segment liegt. Wie oben schon vermutet besteht dann keine Layer 2 Connectivity so das die DHCP Broadcasts nicht ankommen.
Die DHCP Relay Funktion überwindet diese Restriktion um DHCP Broadcasts über 2 Router Interfaces übertragen zu können. Dabei ersetzt der Router mit der Relay Funktion die ursprüngliche (Client) Absenderadresse mit seiner eigenen und forwardet den DHCP Request an den Server. Der antwortet dann dem Router (Relay) und der forwardet es dann letztendlich zum Client. So erreicht man das ein zentraler DHCP Server auch geroutete IP Segmente bedienen kann.
Das dieser falsche Workaround funktioniert zeigt eindeutig das entweder die pfSense falsch oder fehlerhaft eingerichtet wurde und hier mit 2 separaten, gerouteten Netzwerk Interfaces arbeitet oder die NIC des Server falsch an den vSwitch angebunden wurde! Es besteht ja de facto keine Layer 2 Verbindung im Client/Server Netz.
Da es mit der falschen Konfig eines DHCP Relays funktioniert, ist es wahrscheinlicher das die pfSense hier falsch im Bereich ihres LAN Interfaces konfiguriert wurde!
Interessant dürfte das Setup sein wenn man den Server testweise einmal in den DHCP Client Mode versetzt und den DHCP Server auf der pfSense aktiviert. Der Server sollte dann keine IP bekommen auch wenn die Clients im Netz entsprechende IPs bekommen. Das verifiziert dann das die vNIC des Server nicht korrekt im selben L2 Netz am vSwitch hängt sondern separat isoliert an einem 2ten Port der Firewall ohne Verbindung ins Client Netz. Letztlich also eine falsche Firewall Interface Konfig und/oder einen falsche Zuordnung im Layer 2 dieser Interfaces auf dem vSwitch.
Ohne das Setup genau zu kennen kann man hier aber nur im freien Fall raten...
Das der pfSense DHCP und der des DC Servers niemals parallel arbeiten dürfen sollte auch klar sein. Hier gilt das Highlander Prinzip: "Es kann nur einen geben!"
Beispiele einer virtualisierten Firewall in einer VLAN Umgebung sind z.B. hier geschildert
Pfsense in Proxmox als Router
VLAN mit Cisco SG220, ESXIund Pfsense
Wenn ich den DC testweise als DHCP-Client betriebe und den DHCP-Server an der pfSense aktiviere bekommt die DC eine IP von der pfSense.
Das nicht zwei DHCP-Server parallel im selben Subnetz laufen dürfen ist mir bewusst. Die Grundlagen von Netzwerken hatte ich ebenfalls in der Ausblidung und das ist auch nicht das allereste Netz was ich mit Hyper-V aufsetze, weshalb mich das hier auch so verwundert das es nicht funktionieren will wie es sollte.
Wie gesagt ist die pfSense auf der LAN-Seite einfach nur neben den anderen Geräten/VMs eingerichtet.
IP der pfSense (LAN Seite): 172.16.1.5/16
IP des DC: 172.16.1.2/16
dabei hängen beide am selben vSwitch im Hyper-V und daran ist auch das restliche Client-Netz angebunden.
Eine andere VM am gleichen vSwitch bekommt direkt vom DC eine IP (geht auch deutlich schneller) und was über den NIC des Hypervisors angeschlossen ist läuft dann nur über das Relay der pfSense (dauert auch spürbar länger) und ohne dieses funktioniert es gar nicht.
VLANs sind nach wie vor nirgends konfiguriert und die VLAN funktionalitäten der physischen wie auch virtuellen NICs deaktiviert.
Bitte nicht immer alles unnötig zitieren! Wir können hier alle lesen!.
Bitte nicht immer alles unnötig zitieren! Wir können hier alle lesen!.
Als Fehlerquelle bleibt dann eigentlich nur noch die lokale Firewall des Servers!
Wenn alle Netzwerk Komponenten innerhalb des L2 Netzes an der pfSense sich fehlerlos verhalten und es einzig nur der Server ist dann bleibt ja fast nur dessen lokale Firewall.
Du kannst ja spasseshalber mal eine ganz einfache Debian VM mit den gleichen virtuellen NIC Settings statt der Winblows Server VM laufen lassen. Mit apt install tcpdump dort noch einen Sniffer installieren und mal schnell einen ISC DHCP Server dort aufsetzen wie u.a. HIER beschrieben.
Damit kannst du dann sehr genau das DHCP Verhalten an dem Server checken wie oben schon erklärt.
Was dabei rauskommt wäre mal sehr spannend?!
Als Fehlerquelle bleibt dann eigentlich nur noch die lokale Firewall des Servers!
Wenn alle Netzwerk Komponenten innerhalb des L2 Netzes an der pfSense sich fehlerlos verhalten und es einzig nur der Server ist dann bleibt ja fast nur dessen lokale Firewall.
Du kannst ja spasseshalber mal eine ganz einfache Debian VM mit den gleichen virtuellen NIC Settings statt der Winblows Server VM laufen lassen. Mit apt install tcpdump dort noch einen Sniffer installieren und mal schnell einen ISC DHCP Server dort aufsetzen wie u.a. HIER beschrieben.
Damit kannst du dann sehr genau das DHCP Verhalten an dem Server checken wie oben schon erklärt.
Was dabei rauskommt wäre mal sehr spannend?!
OK
Außerdem funktionierte es ja, wenn ich dem DC zum anderen NIC/vSwitch zugewiesen habe. Die firewall in der VM kann doch gar nicht wissen an welchem vSwitch ich das in der VM-Config zugewiesen habe.
Die pfSense übernimmt aus sicht der Clients exakt die funktion, die du mit dem Debian beschreibst und hat der wurde auch der gleiche NIC zugewiesen, dort funktioniert es. Sowohl mit ISC als auch Kea.
Als Fehlerquelle bleibt dann eigentlich nur noch die lokale Firewall des Servers!
Die bei der Installation des DHCP-Servers automatisch erstellten Regeln für DHCP sind dort aktiv.Was dabei rauskommt wäre mal sehr spannend?!
Ich habe stattdessen mal die Firewall vom DC temporär komplett deaktiviert und habe das gleiche verhalten.Außerdem funktionierte es ja, wenn ich dem DC zum anderen NIC/vSwitch zugewiesen habe. Die firewall in der VM kann doch gar nicht wissen an welchem vSwitch ich das in der VM-Config zugewiesen habe.
Die pfSense übernimmt aus sicht der Clients exakt die funktion, die du mit dem Debian beschreibst und hat der wurde auch der gleiche NIC zugewiesen, dort funktioniert es. Sowohl mit ISC als auch Kea.
wenn ich dem DC zum anderen NIC/vSwitch zugewiesen habe.
Dann hast du ja ein Problem mit der ursprünglichen NIC. Die kann dann niemals im gleichen L2 Segment sein wie der Rest, also Firewall und Clients.Es muss also einen Unterschied im L2 Setting (vSwitch) zwischen der NIC mit der es klappt wenn du umschaltest und der NIC mit der es nicht klappt geben.
Das im letzteren Falle dann DHCP Relay klappt bestätigt dann auch das diese 2 NICs an unterschiedlichen (gerouteten) Firewall Segmenten hängen.
Irgendwo ist da also was faul bzw. falsch in der L2 Zuordnung der dieser 2 NICs.
Die pfSense übernimmt aus sicht der Clients exakt die funktion
Ist aber Äpfel mit Birnen, denn die nutzt ja eine völlig andere vNIC als der betroffene Server.Zitat von @aqui:
Es muss also einen Unterschied im L2 Setting (vSwitch) zwischen der NIC mit der es klappt wenn du umschaltest und der NIC mit der es nicht klappt geben.
Der einzige Unterschied ist, dass ich mittlerweile nur bei einem die "gemeinsame Verwendung" aktiviert habe, das hat aber am Verhalten nichts geändert.Es muss also einen Unterschied im L2 Setting (vSwitch) zwischen der NIC mit der es klappt wenn du umschaltest und der NIC mit der es nicht klappt geben.
Irgendwo ist da also was faul bzw. falsch in der L2 Zuordnung der dieser 2 NICs.
Im Hyper-V manager sind ja nicht so viele Optionen zu den vSwitches vorhanden, kann man da irgendwo mehr sehen, sodass man da mal nachschauen kann?Ist aber Äpfel mit Birnen, denn die nutzt ja eine völlig andere vNIC als der betroffene Server.
Nein, die hängt ebenfalls am selben NIC bzw. vSwitch wie der DC, siehe Abbildung oben.Also letzlich ist der pfSense VM egal an welchem NIC sie hängt, der DHCP läuft dort immer. Beim DC macht es allerdings einen unterschied und der DHCP vom DC läuft an dem 2.5G NIC nicht. Habe da schon die verschiendenen Kombinationen ausprobiert.
EDIT: Außerdem kommem am DC ja auch die Discovery-Pakete von Clients an, nur die Antworten vom DC verlassen den vSwitch nicht, den DC selbst aber sehr wohl (VMs am selben vSwitch bekommen eine IP). Die Antworten der pfSense wiederum verlassen den gleichen vSwitch auch und somit erhalten die Clients auch ihre IP.
Im Hyper-V manager sind ja nicht so viele Optionen zu den vSwitches vorhanden, kann man da irgendwo mehr sehen
Das müssten die Winblows Hyper-V Profis hier beantworten. Bei ESXi oder Proxmox ist das mit detailierten Angaben dazu gelöst wie man an den o.a. Threads ersehen kann.nur die Antworten vom DC verlassen den vSwitch nicht
DAS wird der Knackpunkt sein! Bei den o.g. Hypervisoren lassen sich das Broadcast und Promiscous Verhalten entsprechend customizen.Bis jetzt hast du ja leider keinen Screenshot deiner vSwitch Einrichtung gepostet um das einmal verifizieren zu können.
Siehe auch einen aktuellen Thread zu der Thematik.
Laut meinen Tests benötigt die physische NIC VMQ-Unterstützung, damit die DHCP-Offers auch ausserhalb der virtuellen Umgebung ankommen. Anscheinend ist das seit WS2025 neu oder M$ reicht die Funktion für NICs ohne VMQ noch nach.
2
