Multiple VLANs Single DHCP Server - Relay

[killtux 11]

Hallo Forum,

 

folgende Situation/Fragestellung bzgl. DHCP & Relay. Ich glaube das haben nicht Viele bemerkt weil die Situation nur unter der "Ausgangssituation" auftritt die wohl

nicht so Viele haben. 

 

Ausgangssituation:

- Mehrere VLANs (der einfachheit VLAN-A,B,C,D...) mit eigenen IP Subnets

- VLANs getrennt (segmentiert) von einander und durch Firewall getrennt

- Ein DHCP Server (in VLAN A), mit nur Schnitstelle/Interface in VLAN-A

- Relay Agent auf Firewall, zielend auf DHCP Server in VLAN A

- DHCP Server: 2012R2, Clients W7/10

- Firewall hat in allen VLANs ein Interface

- Es gibt Rechner/Geräte die von VLANA in B, etc wechselnd "unterwegs" sind

 

Ablauf sollte lt. Theorie ja sein, DHCP:
1. DHCP Client in VLAN B ->  Discovery, Broadcast, Wo ist ein DHCP Server

2. Relay Agent auf Firewall übernimmt das Broadcast Frame,

3. Relay Agent setzt das Relay Agent Flag und übergibt das Frame dem DHCP Server in VLAN A 

3. DHCP Server in VLAN A erhält das Frame von Firewall, sieht das Relay Flag, erkennt VLAN-B (wo er einen Bereich hat) und sucht eine IP aus VLAN-B

4. DHCP Server sendet DHCP Offer mit IP aus VLAN B in Richtung Firewall die es dem Client in VLAN-B Weiter reicht

 

So und jetzt kommt das "Dumme".

5. Der Client sieht wohl die IP aus dem Offer, nimmt aber stattdessen die IP die er bereits hatte (In Windows HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\xYzGUID ) und gibt diese IP in den Request den er wieder abschickt

6. Der DHCP empfängt den Request mit (der alten) IP und gibt diese Frei (DHCP-ACK). 

 

Aber!: Wenn der Client von VLAN B, in VLAN C wechselt, !der gleiche Client! dann nimmt der knallhart die !letze! IP die er hatte, und das ist blöderweise die vom falschen VLAN und der DHCP Server, der sowhl Client HW-ID als auch IP Adresse hat erkennt diese, sagt "ist eh noch frei" und bestätigt dem Client diese mit dem ACK. 

 

Das einzige was hilft, ist interessanterweise nicht ipconfig /release && ipconfig /renew am Client, sondenr das ist Netzwerkkarte am Client deaktivieren/aktivieren. 

Nur dann scheint er die "alte IP" am Client tatsächlich zu vergessen und "lässt sich" auf eine neue IP ein.

 

Auch interessant:

Dieses Verhalten tritt >nicht< auf wenn der DHCP Server anstelle Relay, in jedem VLAN ein Interface hat.

 

 

So... wer hat hier eine Lösung :-)....

Ich könnte mir vorstellen, dass man am DHCP Server die Clientseitige IP im Request einfach ignorieren müsste und immer die IP "aus Server sicht" verwendet, dann würde es ja gehen. Der Client macht ja das Chaos rein weil er sich so verhält. Aber wie - ich habe schon rum gegoogelt, aber keine Info gefunden wie man das am DHCP Server ignorieren könnte...

 

 

Tja... jetzt sind echte Fachkundige gefragt... 

 

ciao

bearbeitet 30. November 2017 von killtux

[NilsK 2.934]

Moin,

 

wow, das ist ein interessantes Ergebnis. Das war mir in der Tat unbekannt.

 

Ist das bei den Clients unabhängig von der Windows-Version? Für mich sieht das nach einem Fehler auf der Clientseite aus. Ich würde dazu einen Case bei Microsoft aufmachen, um das zu klären.

 

Gruß, Nils

[zahni 554]

Ich würde mal prüfen, ob die Firewall etwas filtert, z.B. NAKs vom DHCP in Richtung Client.

Normalerweise ist es so, dass der Client probiert vom DHCP seine  alte Adresse  erneut  zu bekommen. Wenn dies nicht geht gibt der DHCP ein NAK aus. Wenn das nicht  ankommt...

Was ist das denn für eine Firewall bzw. Relay Agent?

 

Test: Auf Server und Client mal Wireshark oder Netmon installieren. Netmon funktioniert bei 2012 und Windows 7 noch.

Nun auf DHCP filtern und mal schauen was bei rausschicken und auf  der jeweils anderen Seite  ankommt.

Ich tippe auf den Relay Agent als Ursache.

bearbeitet 30. November 2017 von zahni

[NilsK 2.934]

Moin,

 

gegen diese Vermutung spricht, dass der TO als Schritt 6 ja ausdrücklich ein DHCP ACK angibt. Wenn das stimmt, gibt der Server ja kein NACK aus.

 

Gruß, Nils

[zahni 554]

Wie  gesagt: Wireshark.

Es gibt wohl noch die Möglichkeit,  dass  der DHCP-Server denkt, dass der Client im gleichen Subnet ist wie er selber und gibt dann auch kein NAK aus.

Liegt  dann aber wohl  auch wieder am Relay Agent:

 

https://blogs.technet.microsoft.com/teamdhcp/2006/10/26/when-is-dhcp-nak-issued/

 

Besonders lustig wird es, wenn irgendeine Komponente die Reihenfolge der Pakete  ändert...

[NilsK 2.934]

Moin,

 

wenn der Ablauf, den der TO angibt, bestätigt so stattgefunden hat, scheidet der Relay Agent aus dem Kreis der Verdächtigen eher aus. Wäre also abzuwarten, ob der Vorgang so "on the wire" beobachtet wurde oder nur vermutet ist.

 

Gruß, Nils

[NorbertFe 2.034]

Wäre aber trotzdem interessant zu wissen, welcher Hersteller Switch/Firewall/Relayagent genutzt wird.

[zahni 554]

Wir  haben hier jedenfalls keine Probleme. Unser Relay Agent kommt von Cisco. 

Hilfreich könnte übrigens noch ein Debug-Log im DHCP  sein.

An der Beschreibung oben kann auch etwas nicht stimmen.

Eigentlich sendet ein Client kein DHCPDISCOVER wenn er schon eine Lease besitzt und er bekommt auch kein DHCPOFFER zurück.

Der Ablauf ist hier beschrieben:  https://technet.microsoft.com/en-us/library/cc780760(v=ws.10).aspx

[NilsK 2.934]

Moin,

 

An der Beschreibung oben kann auch etwas nicht stimmen.

Eigentlich sendet ein Client kein DHCPDISCOVER wenn er schon eine Lease besitzt und er bekommt auch kein DHCPOFFER zurück.

 

ja, das fiel mir beim nochmaligen Lesen auch auf. Daher müssen wir mal warten, was der TO sagt - vermutet oder wirklich beobachtet.

 

Gruß, Nils

[NorbertFe 2.034]

Wir  haben hier jedenfalls keine Probleme. Unser Relay Agent kommt von Cisco.

Ich kann das bisher auch nicht bestätigen. Weder bei den Cisco Infrastrukturen noch bei Extreme Networks habe ich solche Phänomene bisher gesehen. Aber ich habe schon "merkwürdige" Effekte gesehen, wenn man DHCP Redundanz konfiguriert hat aber der Relay-Agent nur einen der beiden Server konfiguriert bekommen hat. ;)

 

Bye

Norbert

[zahni 554]

Nicht  das  da noch jemand Broadcast Forwarding konfiguriert hat...

[killtux 11]

Hallo,

 

danke den regen DIskussionen. 

Die Firewall ist in diesem Fall eine Sophos SG Firewall. Das ist eigentlich ein Spitzen-Gerät und verfügt dank des Linux Kernels über alle "linux-möglichen" logging Methoden.

 

Ja, ich habe natürlich bereits mit Wireshark sowohl das Interface auf der Firewall (in diesem Fall, VLAN-B) sowie am Client gesnifft und die DHCP Einträge geprüft. 

Mir Fällt da nichts wesentliches auf, was nicht so wäre was sonst "schon" wäre. Wenn ich den selben Client nehme (es ist ein W10) und in ein anderes Netz (damit mein ich jetzt andere Firma) gehe zu einem Kollegen, der allerdings mit einzigen Unterschied einen DHCP Server mit Interfaces pro VLAN hat, tritt das Phänomen nicht auf.

 

Jetzt kommts... Wenn ich in der Vmware auch "physische" Interfaces am DHCP dazu geb, - na was wohl... - kommt's auch hier nicht mehr. 

 

Das einzige was ich an den Logs kenne/erkenne, dass die Kommunikation des Servers (samt allem was er Vorschlägt) korrekt ist. Nur eben im Request des Clients steht dann eine IP die da eigentlich nicht stehen sollte. Vielleicht gibt es im Wireshark einen Punk, einen Flag den ich übersehe anzuschauen, lass mich da gern updaten....

 

Die DHCP Redundanzen (falls jetzt das Windows "Failover-Zeugs" gemeint ist), das ja eigentlich fast nur Konfig-Import-Export zwischen den DHCP Servern macht. Nö, diesen Shmu habe ich nicht aktiv. 

Dzt. nur 1 DHCP, alleine schon wg. der Testerei. 

 

Zur Anmerkung bzgl. DHCP Discover... Ich habe zusätzlich, daher bin ich auch nicht drauf eingegangen, ok hab ich übersehen zu sagen... am DHCP Server die Lease Zeit auf das niedrigste das geht gedreht - das ist 1 Min. Weil ich wollte auch wissen was außerhalb von Lease Zeiten passiert - normal habe ich 8h. Da sieht man im übrigen dann auch, dass der Server nach Ablauf der Lease die bei ihm wieder entfernt - gut. Aber auch nach der Lease Zeit die da - wow - 2 Minuten wären :-).... - auch da kommt der Client wieder mit der alten IP angerauscht im Request.... 

 

Zu Cisco kann ich nichts sagen... ich steh nicht wirklich auf Cisco... aber Relay Agent's habe ich zugegeben bis dato nirgends verwenden (müssen), erst seit "wir" alle unsere Netzwerke absichern und eben segmentieren.

 

Ich kann natürlich auch die Firewall die DHCP Adressen ausgeben lassen. Das funktioniert auch prima von dem her. Mit dem Unterschied zum WIndows DHCP, dass die FW die DNS Einträge nicht in den DNS Server pumpt so wie das der Windows DHCP macht. Ja jtzt könnte ich am Client da einiges machen, da steckt'st du dann aber automatisch wieder in Rechte-Problematik etc, das ich mir sparen möchte...

 

 

Es ginge - obwohl ich nachvollziehen kann dass die Diskussion hier interessant ist.... ist ja auch ein nicht so oft anzutreffendes Phänomen... mir eigentlich darum ob ihr einen Weg wisst diese "Request IP" die der Client möchte Serverseitig am DHCP zu ignorieren. Dass also der DHCP immer die Friss-oder-Stirb methode macht. Es ist mir völlig Banane welche IP der Client gerne hätte. Er soll die haben die der Server ihm gibt. Die IP muss nicht immer gleich sein, wär mir sogar lieber wenn es eh nicht wäre... 

 

 

Aktuell umgehe ich das Problem mit einem  "nur und nichts Anderes Windows DCHP Server" mit NIC in jedem VLAN. Das gefällt mir aber auch sicherheits-Sicht nicht besonders gut. 

 

Danke Jungs...

 

ciao

[NorbertFe 2.034]

Die DHCP Redundanzen (falls jetzt das Windows "Failover-Zeugs" gemeint ist), das ja eigentlich fast nur Konfig-Import-Export zwischen den DHCP Servern macht.

Das ist schon etwas mehr als "import-Export". ;) MS hält sich da auch an die entsprechenden RFCs. Und Sophos kommt damit afair auch nicht wirklich klar, weil der relay Agent in der Firewall nur ein Ziel akzeptiert (zumindest als ich letztes Mal nachgeschaut hatte). Ansonsten kann ich leider erstmal nix konkretes beisteuern.

[zahni 554]

Jetzt kommts... Wenn ich in der Vmware auch "physische" Interfaces am DHCP dazu geb, - na was wohl... - kommt's auch hier nicht mehr.

Tut mir Leid. Das verstehe ich nicht. Was hast Du da wie konfiguriert und was ist bei Dir ein "physisches" Interface?

 

BTW: Der "Cisco Relay Agent" ist bei uns in einem teuren Switch verbaut ;)

bearbeitet 30. November 2017 von zahni

[NilsK 2.934]

Moin,

 

hm, also, wenn wirklich bestätigt ist, dass der Ablauf wie im ersten Post beschrieben ist, dann bleibe ich dabei, dass der Client der Hauptverdächtige für die Fehlfunktion ist. In dem Fall wäre es interessant, was ein MS-Call dazu ergibt.

 

Das mit VMware und den physischen Interfaces habe ich jetzt noch nicht ganz verstanden. Kannst du das noch mal erläutern?

 

Gruß, Nils