21
DHCP verteilt keine IPs in einem neuen IP-Netz
Hi zusammen.
Folgender Setup:
Eine Sophos UTM Firewall ist die Brücke zwischen altem und neuen Core-Switch. Der alte Core bzw. die ganze alte Infra hat IP's im Bereich 172.26.x.x. Darin liegt auch der DHCP Server (Windows Server 2008 R2). In der neuen Infrastruktur gibt es neue IP-Netze im Bereich 172.16.x.x.
Beide neuen Core-Switche sehen sich gegenseitig und auch die Firewall. Ebenso kann der neue Coreswitch auch den alten Domain Controller wunderbar erreichen.
Nun ist im neuen VLAN für die User der Domain Controller aus dem alten Netz als IP Helper-Adresse eingetragen. Der neue DHCP-bereich ist auch sauber angelegt. Allerdings bekomm ich im Client keine IP zugewiesen und lande im "guten" alten 169er Bereich.
Ich hatte vorher im neuen Server-Netz einen Windows DHCP-Server laufen und das hat wunderbar funktioniert. Daher nun die Frage ob ich irgendwas übersehe.
Sagt mir gern wo ich noch genauer beschreiben soll.
Gruß
Julian
Folgender Setup:
Eine Sophos UTM Firewall ist die Brücke zwischen altem und neuen Core-Switch. Der alte Core bzw. die ganze alte Infra hat IP's im Bereich 172.26.x.x. Darin liegt auch der DHCP Server (Windows Server 2008 R2). In der neuen Infrastruktur gibt es neue IP-Netze im Bereich 172.16.x.x.
Beide neuen Core-Switche sehen sich gegenseitig und auch die Firewall. Ebenso kann der neue Coreswitch auch den alten Domain Controller wunderbar erreichen.
Nun ist im neuen VLAN für die User der Domain Controller aus dem alten Netz als IP Helper-Adresse eingetragen. Der neue DHCP-bereich ist auch sauber angelegt. Allerdings bekomm ich im Client keine IP zugewiesen und lande im "guten" alten 169er Bereich.
Ich hatte vorher im neuen Server-Netz einen Windows DHCP-Server laufen und das hat wunderbar funktioniert. Daher nun die Frage ob ich irgendwas übersehe.
Sagt mir gern wo ich noch genauer beschreiben soll.
Gruß
Julian
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: 368677
Url: https://administrator.de/contentid/368677
Ausgedruckt am: 22.11.2024 um 08:11 Uhr
21 Kommentare
Neuester Kommentar
Der Client macht zu Beginn einen Broadcast, der nicht in das andere Netz geroutet wird. Daher kommt der DHCP Discover nie beim Server an. Also entweder einen eigenen DHCP-Server für das zweite Netz oder einen DHCP Relay Agent, der die Anfragen an den Server weiterleitet. Was auch geht, wäre eine zweite Netzwerkkarte im DHCP-Server, die im zweiten Netz liegt.
1
In die Richtung bin ich auch schon. Es gibt in der UTM ein Interface der neuen Netze und diese wurde als DHCP Relay dort eingetragen. Müsste im neuen Core dann die UTM als IP-Helper eingetragen werden?
Ein Beinchen des alten DHCP im neuen Netz wäre natürlich ideal. Würde ich auch als einer der nächsten Schritte testen wenn es nicht auf die andere Weise umsetzbar ist.
EDIT: Ich könnte für das vlan interface auf dem neuen core auch ip directed-broadcast auf enable stellen. Bin mir aber nicht sicher ob es den gewünschten Effekt bringt.
Ein Beinchen des alten DHCP im neuen Netz wäre natürlich ideal. Würde ich auch als einer der nächsten Schritte testen wenn es nicht auf die andere Weise umsetzbar ist.
EDIT: Ich könnte für das vlan interface auf dem neuen core auch ip directed-broadcast auf enable stellen. Bin mir aber nicht sicher ob es den gewünschten Effekt bringt.
Zitat von @Julian92:
Nun ist im neuen VLAN für die User der Domain Controller aus dem alten Netz als IP Helper-Adresse eingetragen.
Nun ist im neuen VLAN für die User der Domain Controller aus dem alten Netz als IP Helper-Adresse eingetragen.
Was hat der DC damit zu tun? Der IP Helper muss auf den DHCP-Server zeigen, nicht auf den DC (es sei denn, da läuft auch der DHCP drauf).
Dein Core hat im neuen VLAN auch eine IP-Adresse, welche identisch mit der Router-IP in deinem neuen DHCP-Scope ist?
Die konkrete HW kenne ich nicht. Im Prinzip geht es so. Im Netz ohne eigenen DHCP steht der Relay Agent. Im Relay Agent wird die IP des DHCP-Servers eingetragen, damit er die Anfragen weiterleiten kann. Die FW muss das natürlich durchlassen. D. h. die DHCP-Ports müssen in beide Richtungen offen sein.
1
Moin,
Evtl. sind an der Sophos noch (Firewall) Regeln aktiv die den DHCP Verkehr verhindern? Oder sowas wie DHCP Spoofing Protection o.Ä.?
lg,
Slainte
Es gibt in der UTM ein Interface der neuen Netze und diese wurde als DHCP Relay dort eingetragen.
Was genau bedeutet das denn? Der DHCP Helper sollte am Switch in den entsprechenden VLAN eingetragen sein und auf den DHCP Server (deinen DC) zeigen. Am Switch muss idR keinerlei Broadcast Routing oder ähnliches eingestellt sein.Evtl. sind an der Sophos noch (Firewall) Regeln aktiv die den DHCP Verkehr verhindern? Oder sowas wie DHCP Spoofing Protection o.Ä.?
lg,
Slainte
1
Beide neuen Core-Switche sehen sich gegenseitig
Wie meinst du das genau ?? Sehen sich im Layer 2 oder sehen sich im Layer 3 ?für die User der Domain Controller aus dem alten Netz als IP Helper-Adresse eingetragen.
Ein Domain Controller ist natürlich kein DHCP Server ! Das kann also nicht gehen !Die neuen IP Netze bzw. VLANs die KEINEN DHCP Server haben müssen am Layer 3 Punkt also an dem Gerät was das Routing in das IP Netz mit dem DHCP Server macht eine IP Helper Adresse, sprich einen UDP Forwarder konfiguriert haben.
Logisch, denn DHCP basiert auf UDP Broadcasts die ein Layer 3 Device (sprich Router) prinzipienbedingt NICHT forwardet.
Mit der Helper bzw. Forwarder IP definiert man dort die IP Adresse des DHCP Servers.
Der Router mit dem Helper ersetzt dann beim UDP Broadcast die Absender IP mit seiner Interface IP und sendet dieses Pakete an den DHCP Server. Anhand der Absender IP erkennt er den Scope, reserviert eine IP aus dem Pool und schickt einen DHCP Offer an den Router zurück.
Der wiederum packt in den Layer 2 Header ans Endgerät dessen Mac Adresse (hat er gecacht) und so erreicht den Client der DHCP Offer, den er dann umsetzt.
Das zur Theorie....
Von Firewall Regeln die jetzt UDP 67 oder 68 filtern erstmal gar nicht geredet.
Dein Fehler ist also das du:
- vergessen hast einen richtigen Helper zu definieren am L3 Device was das VLAN Segment terminiert
- eine falsche IP Adresse für den DHCP Server definiert hast
- der DHCP Server per Routing nicht erreichbar ist vom Forwarder.
Mit einem einfachen und simplen Wireshark Trace hättest du das auch in Sekundenschnelle selber gesehen.
Ist der Core Switch auch am VLAN Routing beteiligt ??
Fazit:
Falsche oder Fehlerhafte Forwarder Konfig im L3 !
Wireshark ist wie immer dein Freund !
auch ip directed-broadcast auf enable stellen
Ist natürlich Blödsinn und hat mit dem Problem nicht das Geringste zu tun. Zeigt eher das du nicht wirklich weisst was du da tust...sorry1
Ja DHCP läuft auf dem Domain Controller. Hätte ich sagen sollen.
Der neue Core hat mit der .1 in jedem VLAN/Subnet sein Beinchen drin. Für die Verbindung zur UTM gibt es ein Transfer-Netz mit 2 IPs. Die eine hat der Core, die andere das Interface der UTM.
Das User-Netz ist 172.16.103.0/24. Der DHCP Scope ist 172.16.103.21 - 230.
Der neue Core hat mit der .1 in jedem VLAN/Subnet sein Beinchen drin. Für die Verbindung zur UTM gibt es ein Transfer-Netz mit 2 IPs. Die eine hat der Core, die andere das Interface der UTM.
Das User-Netz ist 172.16.103.0/24. Der DHCP Scope ist 172.16.103.21 - 230.
Danke erstmal für die Antworten. Ich werde mich gleich nochmal in Ruhe damit auseinander setzen.
@aqui: Danke für die ausführliche Analyse. Ich denke da ist sicher die richtige Antwort bei. Allerdings stellt man ja auch Fragen um was dabei zu lernen. Leuten hier zu sagen dass sie nicht wissen was sie da tun ist schon ein bisschen Ironie. Aber wie gesagt, danke dir.
Zitat von @aqui:
Ist natürlich Blödsinn und hat mit dem Problem nicht das Geringste zu tun. Zeigt eher das du nicht wirklich weisst was du da tust...sorry
Ist natürlich Blödsinn und hat mit dem Problem nicht das Geringste zu tun. Zeigt eher das du nicht wirklich weisst was du da tust...sorry
@aqui: Danke für die ausführliche Analyse. Ich denke da ist sicher die richtige Antwort bei. Allerdings stellt man ja auch Fragen um was dabei zu lernen. Leuten hier zu sagen dass sie nicht wissen was sie da tun ist schon ein bisschen Ironie. Aber wie gesagt, danke dir.
Leuten hier zu sagen dass sie nicht wissen was sie da tun ist schon ein bisschen Ironie
Na ja wenn du im freien Fall über directed Broadcasts zu diesem Thema schwadronierst und rumrätst was primär mit dem Fehlerbild nun rein gar nix zu tun hat, dann kann man ja schon mal solche Gedanken bekommen.Wüsstest du was es ist würdest du ja sicher auch nicht quizartig darüber in einem Thread rumraten. Schon gar nicht wissentlich in einem Administrator Forum, oder ?
Aber du hast recht...da man sich nicht sieht kann man sich mit seinen Annahmen schon mal irren....keine Frage !
1
Geplänkel beiseite, ist nicht produktiv.
@TE veranschaulich das mal mit ner Zeichnung, wie genau deine Sophos und deine Cores zusammenhängen.
@TE veranschaulich das mal mit ner Zeichnung, wie genau deine Sophos und deine Cores zusammenhängen.
@aqui
Hm, sicher das immer am L3 Gateway sein muss? ich war bisher der Meinung, das der IP Helper irgendwo im L2 Segment laufen kann, Hauptsache er st mit der korrekten IP des DHCP Servers konfiguriert und hat selbst eine IP aus dem (V)LAN das DHCP erhalten soll. Ist das nicht so?
Die neuen IP Netze bzw. VLANs die KEINEN DHCP Server haben müssen am Layer 3 Punkt also an dem Gerät was das Routing in das IP Netz mit
dem DHCP Server macht eine IP Helper Adresse, sprich einen UDP Forwarder konfiguriert haben.
dem DHCP Server macht eine IP Helper Adresse, sprich einen UDP Forwarder konfiguriert haben.
Hm, sicher das immer am L3 Gateway sein muss? ich war bisher der Meinung, das der IP Helper irgendwo im L2 Segment laufen kann, Hauptsache er st mit der korrekten IP des DHCP Servers konfiguriert und hat selbst eine IP aus dem (V)LAN das DHCP erhalten soll. Ist das nicht so?
1Zitat von @SlainteMhath:
@aqui
Hm, sicher das immer am L3 Gateway sein muss?
@aqui
Die neuen IP Netze bzw. VLANs die KEINEN DHCP Server haben müssen am Layer 3 Punkt also an dem Gerät was das Routing in das IP Netz mit
dem DHCP Server macht eine IP Helper Adresse, sprich einen UDP Forwarder konfiguriert haben.
dem DHCP Server macht eine IP Helper Adresse, sprich einen UDP Forwarder konfiguriert haben.
Hm, sicher das immer am L3 Gateway sein muss?
Es muss ein Gateway (Layer 3) sein, der IP-Helper selber wird aber dort auf VLAN-Ebene (Layer 2) eingetragen.
Der UDP Forwarder hat damit aber nichts zu tun, ist ein separates Paar Schuhe und auch ein separater Befehl auf dem Gateway. IP Helper ist ein Broadcast-Forwarder.
1
Nur um kurz ein kleines Update zu geben. Ich kann mich leider erst am Freitag wieder damit beschäftigen. akuter Personalmangel :/
Sobald ich hier weiter bin gibt es weitere Infos / Erkenntnisse.
Danke nochmal soweit.
Sobald ich hier weiter bin gibt es weitere Infos / Erkenntnisse.
Danke nochmal soweit.
Wir sind gespannt... 
Hi, ich hab mich jetzt wieder damit befassen können. Ich hab zusätzlich mal versucht das etwas grafisch darzustellen:
Das Transfer-Netz:
Vlan 50 im Core: 172.16.50.252/30.
Das vlan auf dem Core hat dann die IP 50.253 bekommen und eine Schnittstelle an der FW die 254.
Auf der Firewall gibt es eine statische Gateway Route vom Netzwerk 172.16.0.0/12 mit dem GW 172.16.50.253 (Core)
Ebenso sind auf der FW die Regeln für Port 67 und 68 an den DC (der DHCP macht) eingetragen und steht auf allow.
Auf der FW ist ein DHCP Relay hinterlegt für die Schnittstelle "TransferLan" mit der IP 172.16.50.254.
Und die 172.26.32.101 ist halt noch als ip helper für das vlan 103 eingetragen. vlan 103 ist u.A. untagged auf dem Port, an dem der "neue" Client angeschlossen ist. Dieser ist derzeit in keiner Domäne.
Vielen Dank bisher und für weitere Hilfestellungen.
Gruß
Julian
Das Transfer-Netz:
Vlan 50 im Core: 172.16.50.252/30.
Das vlan auf dem Core hat dann die IP 50.253 bekommen und eine Schnittstelle an der FW die 254.
Auf der Firewall gibt es eine statische Gateway Route vom Netzwerk 172.16.0.0/12 mit dem GW 172.16.50.253 (Core)
Ebenso sind auf der FW die Regeln für Port 67 und 68 an den DC (der DHCP macht) eingetragen und steht auf allow.
Auf der FW ist ein DHCP Relay hinterlegt für die Schnittstelle "TransferLan" mit der IP 172.16.50.254.
Und die 172.26.32.101 ist halt noch als ip helper für das vlan 103 eingetragen. vlan 103 ist u.A. untagged auf dem Port, an dem der "neue" Client angeschlossen ist. Dieser ist derzeit in keiner Domäne.
Vielen Dank bisher und für weitere Hilfestellungen.
Gruß
Julian
Nur mal nachgefragt:
Der Neue Core, ist das ein Layer 3 Switch ?? Bzw. routet der die VLANs ?
Wäre ja der Normalfall aber dann ist natürlich der DHCP Forwarder auf der Firewall grundfalsch !
Klar, denn der Client 172.16.103.x hätte ja dann seine Gateway IP auf dem neuen Core, logisch denn der ist ja Router.
HIER müsste dann aber zwingend der DHCP Helper (Forwarder) konfiguriert werden auf die 172.26.32.101, denn hier auf dem neuen Core Switch ist ja die Route Boundary !
Der Relay auf der Firewall ist also völlig sinnfrei dann, denn da kommt der DHCP Request schon gar nicht mehr an, weil ja schon schon vorher der neue Core diesen gar nicht erst weiterreicht durch den dort fehlenden Helper Eintrag auf dem VLAN 103 IP Interface.
Da ist es klar das das dann scheitert...
Es ist jetzt etwas verwirrend ob du das so gemacht hast oder nicht ?!
Der Helper auf der Firewall ist so oder so überflüssiger Unsinn, denn dort kommen ja DHCP Pakete an die einen Ziel- und Absender IP haben.
Da muss logischerweise niemals ein Helper hin. Verschlimmert das ganze nur
Tip:
Schmeiss mal einen Wireshark an und check mal ob der neue Core den DHCP Request an die ihm konfigurierte Helper IP weiterleitet.
Da müsste ein DHCP Request kommen mit der Absender IP 172.16.103.1 Port 68 and den DHCP Server 172.26.32.101 Port 68.
Klar, denn der neue Core ersetzt das DHCP Broadcast Paket des Clients (Absender 0.0.0.0 Port 68 Ziel 255.255.255.255 Port 67) mit einem Unicast seiner VLAN IP Adresse zum DHCP Server.
Dieses Paket sollte so auch sowohl an der Firewall als auch am DHCP Server ankommen wenn das Routing sauber stimmt bei dir im Netz. Traceroute ist hier wieder dein Freund !
Du kannst daran schon sehen das die Helper IP auf der Firewall sinnfrei und überflüssig ist, denn dort kommt ja ein komplett routebares UDP Paket an !
Domänenkram spielt bei DHCP keine Rolle.
Also...Wireshark anschmeissen und suchen...
Vermutung: Helper falsch konfiguriert (was ja der Fall ist) oder es bleibt in der Firewall wegen falscher Regel hängen.
Der Neue Core, ist das ein Layer 3 Switch ?? Bzw. routet der die VLANs ?
Wäre ja der Normalfall aber dann ist natürlich der DHCP Forwarder auf der Firewall grundfalsch !
Klar, denn der Client 172.16.103.x hätte ja dann seine Gateway IP auf dem neuen Core, logisch denn der ist ja Router.
HIER müsste dann aber zwingend der DHCP Helper (Forwarder) konfiguriert werden auf die 172.26.32.101, denn hier auf dem neuen Core Switch ist ja die Route Boundary !
Der Relay auf der Firewall ist also völlig sinnfrei dann, denn da kommt der DHCP Request schon gar nicht mehr an, weil ja schon schon vorher der neue Core diesen gar nicht erst weiterreicht durch den dort fehlenden Helper Eintrag auf dem VLAN 103 IP Interface.
Da ist es klar das das dann scheitert...
Es ist jetzt etwas verwirrend ob du das so gemacht hast oder nicht ?!
Der Helper auf der Firewall ist so oder so überflüssiger Unsinn, denn dort kommen ja DHCP Pakete an die einen Ziel- und Absender IP haben.
Da muss logischerweise niemals ein Helper hin. Verschlimmert das ganze nur
Tip:
Schmeiss mal einen Wireshark an und check mal ob der neue Core den DHCP Request an die ihm konfigurierte Helper IP weiterleitet.
Da müsste ein DHCP Request kommen mit der Absender IP 172.16.103.1 Port 68 and den DHCP Server 172.26.32.101 Port 68.
Klar, denn der neue Core ersetzt das DHCP Broadcast Paket des Clients (Absender 0.0.0.0 Port 68 Ziel 255.255.255.255 Port 67) mit einem Unicast seiner VLAN IP Adresse zum DHCP Server.
Dieses Paket sollte so auch sowohl an der Firewall als auch am DHCP Server ankommen wenn das Routing sauber stimmt bei dir im Netz. Traceroute ist hier wieder dein Freund !
Du kannst daran schon sehen das die Helper IP auf der Firewall sinnfrei und überflüssig ist, denn dort kommt ja ein komplett routebares UDP Paket an !
Domänenkram spielt bei DHCP keine Rolle.
Also...Wireshark anschmeissen und suchen...
Vermutung: Helper falsch konfiguriert (was ja der Fall ist) oder es bleibt in der Firewall wegen falscher Regel hängen.
Der neue Core routet innerhalb der neuen vlans, ja.
Die 172.26.32.101 ist ja die ganze Zeit bereits im interface vlan 103 als Helper-Adresse eingetragen. Ich dachte das UDP Paket wird von der Firewall halt nicht weitergegeben.
Das vlan interface in der aktuellsten runningConfig:
der Client hängt an 1/17.
Die 172.26.32.101 ist ja die ganze Zeit bereits im interface vlan 103 als Helper-Adresse eingetragen. Ich dachte das UDP Paket wird von der Firewall halt nicht weitergegeben.
Das vlan interface in der aktuellsten runningConfig:
interface Vlan 103
description User1-Netz
name User1-Netz
ip address 172.16.103.1/24
tagged GigabitEthernet 3/1-3/16
tagged Port-channel 51-98
untagged GigabitEthernet 1/17-1/32
untagged GigabitEthernet 2/17-2/32
ip helper-address 172.26.32.101
no shutdown
! der Client hängt an 1/17.
Der neue Core routet innerhalb der neuen vlans, ja.
OK, wie vermutet und die Helper IP am VLAN 103 Port ist dann auch richtig !Da ist also alles OK !
Ich dachte das UDP Paket wird von der Firewall halt nicht weitergegeben.
WIE "dachtest" du das denn ? Bei fehlenden Regeln kann das durchaus der Fall sein.Aber der Reine nach...
Der Helper selber macht die Umwandlung des DHCP Client Broadcasts in einen Unicast an den DHCP Server.
Sprich der neue Core Switch macht die Umwandlung des Client DHCP Broadcast Paketes Absender 0.0.0.0 (klar der Client hat ja noch keine IP !) Quellport UDP 68 auf das Ziel 255.255.255.255 (All IP Broadcast Adresse) Zielport UDP 67.
Dieser Broadcast würde ohne Helper am neuen Core Switch Prinzipien bedingt geblockt.
Der Helper an VLAN 103 sorgt dafür das der Switch diesen UDP DHCP Broadcast in einen Unicast umwandelt.
Er selber (der Core Switch) macht daraus ein Unicast Paket mit der Absender IP 172.16.103.1 (seine VLAN 103 IP) Quellport UDP 68 auf die Ziel IP 172.26.32.101 (den DHCP Server) Zielport UDP 67.
Dieses Paket schickt der neue Core Switch jetzt via VLAN 50 auf die Reise.
Erste Station ist das Inbound Interface der Firewall 172.16.50.254 !
Hier greifen jetzt die Firewall Regeln. Hier musst du eine entsprechende Regel definiert haben die das Paket in die Firewall passieren lässt.
für Port 67 und 68 an den DC (der DHCP macht) eingetragen und steht auf allow.
Das WIE ist hier die Frage ! Beachte das diese UDP Ports beim Reply des DHCP Servers wechseln !! Guckst du hier:https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Ablauf ...
Die Firewall hat ja nun eine statische Route 172.16.0.0 /12 auf den alten Core.
Hier musst du aufpassen ob die Firewall auch eine Outbound Rule hat also Richtung alter Core und ob sie hier auch filtert !
Da du nichts zu den Regeln sagst musst du das also genau checken !
Das Unicast Packet wird von der Firewall wie ein normales UDP Paket anhand der Quell und Ziel IP Adresse geroutet. Genau wie jedes andere Packet auch. Deshalb ist hier auf der Firewall jegliche Helper Adresse sinnlos und überflüssig und eher kontraproduktiv. Sollte also schnellstens wieder entfernt werden.
Klar denn der eigentliche Client Broadcast kommt da ja niemals an. Siehst du selber anhand des oben beschriebenen Packet Walks, oder ?!
Gut, gehen wir davon aus das die Firewall nix filtert und das Paket an den alten Core forwardet. Der routet das dann final zum DHCP Server. Dieser antwortet dann mit einem DHCP Offer Paket:
Quell IP 172.26.32.101 Quellport UDP 67 und Ziel IP 172.16.103.1 Zielport UDP 68.
Diese IP kommt dann wieder am Switch an und der forwardet das dann an die gecachte Mac des Clients im VLAN 103.
Fertig, so bekomtm der die IP.
Spannend ist nun...
- A.) Kommt das Unicast Paket des neuen Core Switches an der Firewall, am alten Core und am DHCP Server an
- B.) Kommt der Reply vom DHCP Server an der Firewall und am neuen Core an
- A.) einen Mirror Port am neuen Core einrichten und den inbound Firewall Port auf den Wireshark spiegeln
- B.) einen Mirror Port am alten Core einrichten und den outbound Firewall Port und den DHCP Server Port auf den Wireshark spiegeln
Fehlt es irgendwo, bleibt es sehr wahrscheinlich in der Firewall hängen weil dort die Regeln falsch sind ?!
Die eher ernüchternde Erkenntnis aktuell: Da kommt kein einziges DHCP-Paket in der Firewall an :/
Das Discover-Paket sollte ich doch im Log sehen können, auch wenn es durch irgendeine Einstellung danach geblockt werden sollte, oder?
Edit: Ich versteh einfach nicht wie es sein kann, dass wenn der Core eine statische Route drin hat (0.0.0.0/0 172.16.50.254) und die ip helper-adresse im vlan interface richtig hinterlegt ist, nichts an DHCP-Paketen an der Firewall ankommt.
Edit2: Haha! Anstatt im Log für DHCP hab ich was im allgemeinen Firewall Log gefunden. Pakete von 172.26.32.101 nach 172.16.103.1 (sourceport 67 und zielport 67) werden gedropped.
Sollte der Quellport nicht 68 sein? Es gibt auf jeden Fall eine FW-Regel die Port 67 und 68 vom Domain Controller nach 172.16.50.252/30 erlaubt.
Das Discover-Paket sollte ich doch im Log sehen können, auch wenn es durch irgendeine Einstellung danach geblockt werden sollte, oder?
Edit: Ich versteh einfach nicht wie es sein kann, dass wenn der Core eine statische Route drin hat (0.0.0.0/0 172.16.50.254) und die ip helper-adresse im vlan interface richtig hinterlegt ist, nichts an DHCP-Paketen an der Firewall ankommt.
Edit2: Haha! Anstatt im Log für DHCP hab ich was im allgemeinen Firewall Log gefunden. Pakete von 172.26.32.101 nach 172.16.103.1 (sourceport 67 und zielport 67) werden gedropped.
Sollte der Quellport nicht 68 sein? Es gibt auf jeden Fall eine FW-Regel die Port 67 und 68 vom Domain Controller nach 172.16.50.252/30 erlaubt.
Ok. Hab den Fehler gefunden.
Die DHCP-Pakete kamen ja mit der Source IP 172.16.103.1 an der FW an. In den DHCP-FW-Regeln war aber statt 172.16.0.0/12, dass Transfer-Netz 172.16.50.252/30 hinterlegt :/
Schande auf mein Haupt. Et lüppt nu.
Die DHCP-Pakete kamen ja mit der Source IP 172.16.103.1 an der FW an. In den DHCP-FW-Regeln war aber statt 172.16.0.0/12, dass Transfer-Netz 172.16.50.252/30 hinterlegt :/
Schande auf mein Haupt. Et lüppt nu.
Die eher ernüchternde Erkenntnis aktuell: Da kommt kein einziges DHCP-Paket in der Firewall an :/
Böses Faul !!Das bedeutet de facto das die IP Helper Funktion auf dem neuen Core Switch nicht funktioniert ! Oder....
je nachdem WO du gemessen hast die FW diese DHCP Unicasts vom neuen Core filtert !
Das Discover-Paket sollte ich doch im Log sehen können, auch wenn es durch irgendeine Einstellung danach geblockt werden sollte, oder?
Ja ! Wenn du VOR dem inbound Firewall Port misst. Dort MUSS es ankommen.und die ip helper-adresse im vlan interface richtig hinterlegt ist, nichts an DHCP-Paketen an der Firewall ankommt.
Genau DAS ist die Schlüsselfrage !! 
Hast du mal ein show ip route gemacht auf dem neuen Core ob es ggf. eine 2te Route gibt ?
Und...Traceroute vom DHCP Client bzw. einem Client im VLAN 103 mal auf den DHCP Server gemacht ?!
Der Traceroute zeigt dir alle Routerhops einzeln an. Dort kannst du h´genau sehen wie der Weg zum Ziel aussieht !
Firewall Log gefunden. Pakete von 172.26.32.101 nach 172.16.103.1 (sourceport 67 und zielport 67) werden gedropped.
Aha !!! Doch die Firewall der böse Buhmann !! Da blockt ihr den Rückweg mit dem DHCP Offer !!Sollte der Quellport nicht 68 sein?
Laut Standard ja: https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Ablauf ...FW-Regel die Port 67 und 68 vom Domain Controller nach 172.16.50.252/30 erlaubt.
Die Regel ist ja kompletter Schwachsinn !Sorry aber die 172.16.50.252/30 kann ja niemals die Zieladresse bzw. das Zielnetz des DHCP Offers sein !
Das ist immer die IP Adresse des jeweiligen VLAN Interfaces mit dem Helper.
Bitte lies dir oben mal GENAU durch wie das geht ! Genau deshalb haben wir dir das Relay Prozedere doch so genau aufgeschrieben hier ! Lesen hilft !
Ok. Hab den Fehler gefunden. Die DHCP-Pakete kamen ja mit der Source
Später Erkentniss ! Einfach nur mal die Threads LESEN hier !!Et lüppt nu.
Glückwunsch. Schwere Geburt aber gut wenn nun alles rennt wie es soll !1
