DHCP (Win2012R2) verweigert seinen Dienst seit Einrichtung einer Netzwerkbrücke
Hallo zusammen,
wir betreiben einen Windows Server mit Win2012R2, der als AD Controller, DNS- und DHCP-Server fungiert.
Seit einiger Zeit sind wir auf (interne) VoIP Telefonie umgestiegen, und in den Server ist ein PCIe ISDN-Gateway (Beronet, deutscher Hersteller) gewandert.
Das Gateway gibt sich gegenüber Windows als Realtek Netzwerkkarte aus und erfordert keinerlei Treiber- oder Softwareinstallation, konfiguriert wird das Gateway ausschließlich per Webinterface.
Voraussetzung für den Betrieb des Gateways ist jedoch, dass man die vermeintliche Realtek NIC mit der NIC1 des Servers brückt, also eine Netzwerkbrücke zwischen den beiden NICs einrichtet.
Blöd ist nur, dass nach der Einrichtung der Bridge der DHCP Server nicht mehr funktioniert. Die requests von den Clients werden nicht mehr beantwortet und es kommt zu keiner Adresszuweisung mehr. Die replys des DHCP werden wohl wie es aussieht durch die Bridge auf die Beronet Karte gelenkt und gehen nicht mehr über die NIC1 ins LAN raus. Die Clients bekommen also nichts davon mit. Als Provisorium haben wir die NIC2 des Servers aktiviert, mit einer anderen IP ins gleiche Netz gehängt und dem DHCP gesagt er soll über diese NIC2 arbeiten.
Das Problem an der Sache ist dann allerdings, dass wir mit dieser Methode irgendwann nicht mehr telefonieren können, da irgendwann die SIP-Anfragen des Telefons fälschlicherweise an der NIC2 ankommen. (2 NICs im selben Netzwerk sind nicht gut, das wissen wir.)
Wir können also entweder telefonieren, oder haben einen DHCP im Netzwerk.
Die Frage ist also, warum verweigert der DHCP seinen Dienst, wenn an seiner konfigurierten NIC1 eine Bridge erstellt wird? Kann man ihm nicht trotzdem irgendwie Beine machen?
Der Support von Beronet ist überfragt und verweist auf den Microsoft Support. Wir sind anscheinend die einzigen Kunden von denen mit Windows Server OS, DHCP-Rolle und Beronet Gateway in einem Gerät. (Was meiner Meinung nach nichts besonderes darstellt.)
DHCP auf die Fritzbox auslagern kommt nicht in Frage, da man der Fritzbox mit original FritzOS nicht beibringen kann dass sie den Clients als DNS statt sich selbst den Windows-Server zuweisen soll, was dann wiederum Probleme mit dem AD ergibt wenn man es so macht.
Wir haben insgesamt schon Stunden damit verbracht, danach zu googeln oder das Problem selbst zu lösen, wir kommen auf keinen grünen Zweig bei dieser Sache.
Ich hoffe mich einigermaßen verständlich ausgedrückt zu haben und würde mich über eine Antwort von euch sehr freuen, vielen Dank!
wir betreiben einen Windows Server mit Win2012R2, der als AD Controller, DNS- und DHCP-Server fungiert.
Seit einiger Zeit sind wir auf (interne) VoIP Telefonie umgestiegen, und in den Server ist ein PCIe ISDN-Gateway (Beronet, deutscher Hersteller) gewandert.
Das Gateway gibt sich gegenüber Windows als Realtek Netzwerkkarte aus und erfordert keinerlei Treiber- oder Softwareinstallation, konfiguriert wird das Gateway ausschließlich per Webinterface.
Voraussetzung für den Betrieb des Gateways ist jedoch, dass man die vermeintliche Realtek NIC mit der NIC1 des Servers brückt, also eine Netzwerkbrücke zwischen den beiden NICs einrichtet.
Blöd ist nur, dass nach der Einrichtung der Bridge der DHCP Server nicht mehr funktioniert. Die requests von den Clients werden nicht mehr beantwortet und es kommt zu keiner Adresszuweisung mehr. Die replys des DHCP werden wohl wie es aussieht durch die Bridge auf die Beronet Karte gelenkt und gehen nicht mehr über die NIC1 ins LAN raus. Die Clients bekommen also nichts davon mit. Als Provisorium haben wir die NIC2 des Servers aktiviert, mit einer anderen IP ins gleiche Netz gehängt und dem DHCP gesagt er soll über diese NIC2 arbeiten.
Das Problem an der Sache ist dann allerdings, dass wir mit dieser Methode irgendwann nicht mehr telefonieren können, da irgendwann die SIP-Anfragen des Telefons fälschlicherweise an der NIC2 ankommen. (2 NICs im selben Netzwerk sind nicht gut, das wissen wir.)
Wir können also entweder telefonieren, oder haben einen DHCP im Netzwerk.
Die Frage ist also, warum verweigert der DHCP seinen Dienst, wenn an seiner konfigurierten NIC1 eine Bridge erstellt wird? Kann man ihm nicht trotzdem irgendwie Beine machen?
Der Support von Beronet ist überfragt und verweist auf den Microsoft Support. Wir sind anscheinend die einzigen Kunden von denen mit Windows Server OS, DHCP-Rolle und Beronet Gateway in einem Gerät. (Was meiner Meinung nach nichts besonderes darstellt.)
DHCP auf die Fritzbox auslagern kommt nicht in Frage, da man der Fritzbox mit original FritzOS nicht beibringen kann dass sie den Clients als DNS statt sich selbst den Windows-Server zuweisen soll, was dann wiederum Probleme mit dem AD ergibt wenn man es so macht.
Wir haben insgesamt schon Stunden damit verbracht, danach zu googeln oder das Problem selbst zu lösen, wir kommen auf keinen grünen Zweig bei dieser Sache.
Ich hoffe mich einigermaßen verständlich ausgedrückt zu haben und würde mich über eine Antwort von euch sehr freuen, vielen Dank!
Kommentieren
Teilen
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: 267906
Url: https://administrator.de/forum/dhcp-win2012r2-verweigert-seinen-dienst-seit-einrichtung-einer-netzwerkbruecke-267906.html
Ausgedruckt am: 12.05.2025 um 07:05 Uhr
12 Kommentare
Neuester Kommentar
Wenn du eine Bridge einrichtest, dann musst du den DHCP Server statt auf die physische NIC auf das Bridge Interface binden dann klappts wieder mit den DHCPs.
Die ganze Konfiguration ist ziemlich krank. Normalerweise gehört sowas auf ein dediziertes Voice Gateway unabhängig von einem Server, denn ist der Server mal weg oder wird gewartet kann man nicht telefonieren. Kein verantwortungsvoller Netzwerker löst das mit so einer Krücke.
Klassische Voice Installationen sehen auch immer so aus. Niemand will sich logischerweise mit seiner Telefonie an einen MS Server binden.
Mal ganz davon abgesehen davon das der gesamte Broad- und Multicast Traffic nun vom Server über beide NICs geforwardet werden muss und dieser damit erheblich belastet wird in seiner Performance.
Auch das man in einem Firmenumfeld eigentlich aus rechtlichen Gründen (Fernmeldegeheimnis) immer gezwungen ist das VoIP Netzwerk in ein separtes VLAN zu setzen wird hier völlig außer acht gelassen.
In so einer Konstellation wo Produktivdaten und Voice auf einem Draht liegen kann jeder im Netz z.B. mit dem freien Wireshark Sniffer jedes Telefongespräch mit einem simplen Mausklick belauschen und abspeichern.
Solch ein Telefonie Konzept haben sich bestimmt Kaufleute ausgedacht ?!
Die ganze Konfiguration ist ziemlich krank. Normalerweise gehört sowas auf ein dediziertes Voice Gateway unabhängig von einem Server, denn ist der Server mal weg oder wird gewartet kann man nicht telefonieren. Kein verantwortungsvoller Netzwerker löst das mit so einer Krücke.
Klassische Voice Installationen sehen auch immer so aus. Niemand will sich logischerweise mit seiner Telefonie an einen MS Server binden.
Mal ganz davon abgesehen davon das der gesamte Broad- und Multicast Traffic nun vom Server über beide NICs geforwardet werden muss und dieser damit erheblich belastet wird in seiner Performance.
Auch das man in einem Firmenumfeld eigentlich aus rechtlichen Gründen (Fernmeldegeheimnis) immer gezwungen ist das VoIP Netzwerk in ein separtes VLAN zu setzen wird hier völlig außer acht gelassen.
In so einer Konstellation wo Produktivdaten und Voice auf einem Draht liegen kann jeder im Netz z.B. mit dem freien Wireshark Sniffer jedes Telefongespräch mit einem simplen Mausklick belauschen und abspeichern.
Solch ein Telefonie Konzept haben sich bestimmt Kaufleute ausgedacht ?!
Moin zusammen,
wie @aqui schon sagt die Bindung des DHCP-Servers auf die Netzwerkbrücke legen:
DHCP-Server MMC > Kontextmenü > Bindungen hinzufügen/entfernen > Netzwerkbrücke auswählen
Zur Info: die Netzwerk-Settings müssen natürlich nach dem "brücken" auf dem Bridge-Interface vorgenommen werden.
Grüße Uwe
wie @aqui schon sagt die Bindung des DHCP-Servers auf die Netzwerkbrücke legen:
DHCP-Server MMC > Kontextmenü > Bindungen hinzufügen/entfernen > Netzwerkbrücke auswählen
Zur Info: die Netzwerk-Settings müssen natürlich nach dem "brücken" auf dem Bridge-Interface vorgenommen werden.
Grüße Uwe
Hallo und danke für eure Antworten.
Der DHCP ist natürlich an die Bridge gebunden. Wenn diese eingerichtet ist hat man auch nur die Bridge zur Auswahl, wenn man den DHCP an eine NIC binden will. Das klappt so aber leider nicht, wir haben es gerade nochmal geprüft: DHCP ist funktionslos.
Dass unsere Konfiguration was VoIP angeht unüblich ist, wissen wir. Unser Unternehmen besteht aus zwei Mitarbeitern, mir und meinem Kollegen. Wenn ich ein Gespräch abhören will dann setze ich meinen Schallschutzkopfhörer ab und höre zu, da er lediglich zwei Meter gegenüber mir am selben Schreibtisch sitzt.
An der Bindung liegt es also nicht. Habt ihr noch weitere Vorschläge?
Der DHCP ist natürlich an die Bridge gebunden. Wenn diese eingerichtet ist hat man auch nur die Bridge zur Auswahl, wenn man den DHCP an eine NIC binden will. Das klappt so aber leider nicht, wir haben es gerade nochmal geprüft: DHCP ist funktionslos.
Dass unsere Konfiguration was VoIP angeht unüblich ist, wissen wir. Unser Unternehmen besteht aus zwei Mitarbeitern, mir und meinem Kollegen. Wenn ich ein Gespräch abhören will dann setze ich meinen Schallschutzkopfhörer ab und höre zu, da er lediglich zwei Meter gegenüber mir am selben Schreibtisch sitzt.
An der Bindung liegt es also nicht. Habt ihr noch weitere Vorschläge?
Das klappt so aber leider nicht, wir haben es gerade nochmal geprüft: DHCP ist funktionslos.
OK dann muss das tatsächlich an der virtuellen NIC liegen. Habe das ganze hier mal in einer VM nachgespielt. DHCP-Requests und Offers gehen problemlos über das Bridge-Interface rein und raus.Eventuell macht das Interface selber einen DHCP so dass sich der des Servers von selbst deaktiviert. Checke auch mal das Firewallprofil auf dem Bridge-Interface, nicht das das die Kommunikation verhindert.
Eventuell macht das Interface selber einen DHCP so dass sich der des Servers von selbst deaktiviert. Checke auch mal das
Firewallprofil auf dem Bridge-Interface, nicht das das die Kommunikation verhindert.
Firewallprofil auf dem Bridge-Interface, nicht das das die Kommunikation verhindert.
Dem Interface ist eine feste IP zugewiesen. Der DHCP Dienst wird ausgeführt und hat sich nicht von selbst deaktiviert, es ist also auch nur ein DHCP Server im Netzwerk vorhanden. Die Firewall habe ich soeben zu Testzwecken komplett deaktiviert, das zeigt leider auch keine Wirkung.
Wir haben vor ca. 6 Wochen unseren Server neu aufgesetzt, vorher war Server 2012 installiert, jetzt 2012 R2. Das Problem bestand auch damals schon, also kann man das auch nicht auf ein unnatürliches Verhalten von genau dieser Windowsinstallation zurückführen.
@colinardo: wie prüfst du, ob die requests und offers über das Interface laufen? Mit Wireshark wie @aqui schon schrieb? Vielleicht könnte man damit was erkennen.
Mit Wireshark wie @aqui schon schrieb?
Exakt ...
Hier ein Screenshot von Wireshark, Liste nach Protokoll>DHCP sortiert. Fehlt da nicht der Request von den Clients? Vielleicht kann das jemand besser interpretieren als ich...
Was muss man da interpretieren. Das sieht auch ein blutiger Anfänger was da passiert !
Dummerweise zeigt dein Screenshot nicht den Detailmodus so das er nur eine grobe Übersicht ist.
Das Endgerät mit der 0.0.0.0 broadcastet ein Request ins Netzwerk (Discover) und darauf antwortet dann brav die .2.10 (vermutlich der Server ?!) mit einem Offer.
Klassisches DHCP Verhalten also nur das der Client vermutlich den Offern nicht sieht oder akzeptiert, denn er versucht es ja immer wieder.
Allerdings ist das jetzt mal spekulativ geraten, da die die Detailansicht nicht aufgeklappt hast.
Damit könnte man dann sehen ob der Request immer von ein und derselben Mac Adresse sprich also immer vom gleichen Endgerät kommt.
Sicher ist aber das der Server sich richtig verhält und antwortet. auf DHCP Requests.
Dummerweise zeigt dein Screenshot nicht den Detailmodus so das er nur eine grobe Übersicht ist.
Das Endgerät mit der 0.0.0.0 broadcastet ein Request ins Netzwerk (Discover) und darauf antwortet dann brav die .2.10 (vermutlich der Server ?!) mit einem Offer.
Klassisches DHCP Verhalten also nur das der Client vermutlich den Offern nicht sieht oder akzeptiert, denn er versucht es ja immer wieder.
Allerdings ist das jetzt mal spekulativ geraten, da die die Detailansicht nicht aufgeklappt hast.
Damit könnte man dann sehen ob der Request immer von ein und derselben Mac Adresse sprich also immer vom gleichen Endgerät kommt.
Sicher ist aber das der Server sich richtig verhält und antwortet. auf DHCP Requests.
Das Endgerät mit der 0.0.0.0 broadcastet ein Request ins Netzwerk (Discover) und darauf antwortet dann brav die .2.10
(vermutlich der Server ?!) mit einem Offer.
(vermutlich der Server ?!) mit einem Offer.
2.1 ist der Server, richtig. Hier mal Details von dem was der Server macht:
und hier vom Client Device:
Was mir aufgefallen ist: Wireshark übersetzt die ersten drei Bytes der MAC in den Namen des jeweiligen Herstellers, der die MAC Adresse registriert hat. Und da steht: Beronet! Wie kann eine unter Windows eingerichtete Netzwerkbrücke eine MAC erhalten die von Beronet registriert ist? Oder ist das ein normales Verhalten, dass die Brücke die ersten sechs Stellen von einer physikalischen NIC übernimmt und die letzten sechs dann wahllos generiert?
Wenn da wirklich die Beronet Karte im Spiel ist, war unsere anfängliche Vermutung richtig: dass sich die DHCP Anfragen über die Brücke irgendwo auf der Beronet Karte verlaufen.
Kann das von euch jemand anhand der Screenshots nachvollziehen?
Vielen Dank schon im Voraus
Wenn da wirklich die Beronet Karte im Spiel ist, war unsere anfängliche Vermutung richtig: dass sich die DHCP Anfragen über die Brücke irgendwo auf der Beronet Karte verlaufen.
Kann das von euch jemand anhand der Screenshots nachvollziehen?
Vielen Dank schon im Voraus
Das sieht normal aus. Mach mal ein Wireshark Trace an einem deiner Clients ob dort die Offer's des Servers überhaupt ankommen ...
Ich vermute das der Treiber von denen einfach nicht korrekt umgesetzt ist, wenn vom Server überhaupt keine Broadcasts mehr ins Netz kommen.
Du kannst auch mal versuchen testweise das IP-Routing zu aktivieren (RAS-Dienst aktivieren, evt. die Rolle nachinstallieren) ob das eine Besserung bringt. Hier wird zwar nix geroutet aber ich hatte mal etwas ähnliches bei dem es geholfen hat.
Im allgemeinen sind Netzwerkbrücken auf Windows Servern mit Vorsicht zu genießen und absolut nicht empfehlenswert, leider...
Wenn alles nichts hilft, pack die Karte auf ein anderes System im Netzwerk.
Oder ist das ein normales Verhalten, dass die Brücke die ersten sechs Stellen von einer physikalischen NIC übernimmt und die letzten sechs dann wahllos generiert?
normal ...Ich vermute das der Treiber von denen einfach nicht korrekt umgesetzt ist, wenn vom Server überhaupt keine Broadcasts mehr ins Netz kommen.
Du kannst auch mal versuchen testweise das IP-Routing zu aktivieren (RAS-Dienst aktivieren, evt. die Rolle nachinstallieren) ob das eine Besserung bringt. Hier wird zwar nix geroutet aber ich hatte mal etwas ähnliches bei dem es geholfen hat.
Im allgemeinen sind Netzwerkbrücken auf Windows Servern mit Vorsicht zu genießen und absolut nicht empfehlenswert, leider...
Wenn alles nichts hilft, pack die Karte auf ein anderes System im Netzwerk.
die Brücke die ersten sechs Stellen von einer physikalischen NIC übernimmt und die letzten sechs dann wahllos generiert?
Das ist normal !Irgendwas muss Microsoft ja machen. Ganz random können sie das niemals machen, da die Gefahr einer Mac Dopplung gegeben ist.
So macht man halt den Kompromiss das man den Vendor Code beibehält und den Rest random nimmt.
Netzwerkbrücken sind halt immer die denkbar schlechteste Lösung in einem Netzwerk und diese Kompromisse muss man schlucken.
Die Traces zeigen absolut korrektes Verhalten.
Der Client (Apple) sendet einen DHCP Request Broadcast und der Server antwortet wie er soll mit einem DHCP Offer. Der Server hat die 192.168.2.151 für den Apple angeboten.
Diesen DHCP Offer MUSST du auch am Client eingehend sehen !
