Kein DHCP-Relay am Sub-Switch HP

In anderen VLANs aber schon ??
Wirklich ??
Nimm ganz einfach einen Wireshark und sniffer eingehende DHCP Request am Port der Firewall / DHCP Server !
Wennd er L3 Switch dort per DHCP Relay die DHCPs forwardet funktioniert er fehlerlos.
Dann kannst du wenigstens den Switch schonmal sicher als Fehlerquelle ausschliessen und musst nur an der FW suchen.
Der Wireshark Trace wird also sofort sagen was los ist.
Unverständlich warum du nicht selber auf diesen Punkt gekommen bist zum Troubleshooten ?!

Bedenke das der L3 Switch mit DHCP Relay die Absender IPs umschreibt. Ggf. musst du die FW customizen um diese Pakete durchzulassen !

Oha...na das solltest du aber ja vorher mal wasserdicht testen. Ein Client im Gast WLAN und einen im dazu korrespondierenden VLAN per Kabel, beide statische IPs und dann mal checken ob die sich pingen können.
Ist ja in 5 Minuten erledigt....
Die Kardinalsfrage, die du leider nicht beantwortest, ist hier das WIE ??
Gut gehen wir mal davon aus das du ja wohl kaum in diesen Netzen einzelne DHCP Server hast und hier auf dem zentralen L3 Switch mit DHCP Relay, sprich einem Forwarder (helper ip) arbeitest und einen zentralen Winblows DHCP Server hast. Ist dem so ?
Das muss man auch nicht. Du musst nur einfach sehen ob da DHCP IP Pakete ankommen.
Obwohl wenn jemand wie du selber sagst sein Netzwerk in VLANs segmentiert hat und auch Routing eingerichtet hat und auch mit DHCP Relay erforlgreich arbeitet zeigt das einem Außenstehenden ja erstmal das da jemand am werkeln ist der sein (Netzwerk) Handwerk versteht und der eigentlich ja auch wissen müsste wie IP Pakete sich in einem Netzwerk bewegen.
Dann zu sagen man kann kein Wireshark klingt dann erstmal mehr als befremdlich...?!
Das ist ja schomal was. Obwohl ein "Offer" ost natürlich technischer Blödsinn, denn das kann ein Client niemals schicken, das kommt immer vom Server !
Die 2 wichtigsten Fragen sind nun:

• Kannst du sehen das der Client innerhalb seiner L2 Doamin also innerhalb seines VLANs den DHCP Request schickt ?
• Wenn ja ist die kommende Frage viel wichtiger: Kannst du am Server sehen das der Request, den ja der DHCP Forwarder am L3 Switch an den DHCP Server sendet da auch ankommt ??

Wenn ja dann müsstest du sehen das die Absender IP nicht mehr eine 0.0.0.0 ist die der Client ursprünglich hatte (klar, denn er hat ja noch keine gültige IP !) Durch die IP Adresse des Forwarders in diesem VLAN ersetzt sein müsste !
Daran kann der DHCP Server erkennen für welchen Scope er die IP zuordnen muss.
So einfach ist der Mechanismus.
Siehst du also diesen DHCP Request der jetzt im VLAN IP Segment des DHCP Servers zu diesem kommt, dann kannst du den L3 Switch und Forwarder komplett ausschliessen.
Denn sendet der DHCP Server dann als Antwort auf diesen eingehenden Request keinerlei Offer raus ist der Fehler ganz klar in der DHCP Server Konfig zu suchen !
Nein auch das ist Blödsinn ! Die Helper IP zeigt immer auf die IP des DHCP Servers zu dem diese Requests in dem Segment geforwardet werden sollen.
Bitte mal das Handbuch des Switches lesen, da ist das haarklein erklärt !
Auch hier ist es verständlich dokumentiert:
http://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation ...
Das ist auch bei gruseligen HP Schrottswitches nicht anders....

Hm, der TO sagt aber, dass im Gäste Netzt eine Firewall DHCP Server ist. Dann müsste doch die IP der Firewall als IP Helper eingetragen werden oder?

Da hast du absolut Recht !
Der TO fragt aber oben (Zitat) ob er die IP Adresse vom Switch dort als Helper IP eintragen soll, was natürlich technischer Quatsch wäre.

Ja definitiv ! Das ist ganz sicher dann kein Helper Problem hier hast du ein grundlegendes Problem im L3.
Und dann hast du VLAN 200 disabled ??? Muss man sich ja dann nicht wundern ?!

Das hier ist Blödsinn in der Konfig:
ip default-gateway 10.128.94.250
ip route 0.0.0.0 0.0.0.0 10.128.94.250
Der Core Router sollte einzig und allein NUR die Default Route konfigurierten haben und nicht noch parallel ein Default Gateway !
Das Default Gateway solltest du besser löschen !

Was aber klar ist das wenn du das VLAN 200 auf dem Coreswitch disablest das man sich nicht groß wundern muss das nix rennt.
Mal ganz abgesehen davon das die Core Switch IP Adresse fehlt oder nicht konfiguriert ist. Damit ist ein Routing via Coreswitch vollkommen unmöglich !
Diese banale Tatsache springt einem doch sofort ins Auge wenn man deine Konfig sieht. Sowas kann man doch nicht übersehen ?!

Ja, das siehst du richtig !
Willst du das verhindern dann ist deine ursprüngliche Konfig natürlich richtig.
Keine IP Im Coreswitch VLAN 200 aber dann musst du die Firewall direkt mit einem untagged Port in das VLAN 200 stecken.
Hast du das gemacht ??
VLAN 200 Clients kommen dann nur noch über die Firewall bzw. den Firewall Port raus.
Dann musst du einzig auf der Firewall sicherstellen das diese IP Adressen per DHCP für das VLAN 200 rausgibt.
Das erfordert dann natürlich entsprechende Einstellungen und Regeln in der Firewall !!
Das richtige Firewall Setup ist dann hier der Schlüssel zum Erfolg !

Vielleicht bin ich einfach zu doof es zu verstehen, aber warum hast du nicht überall den Core Switch als DHCP Server?
Weshalb hast du im Gästenetz die Firewall als DHCP Server?
Nicht, dass es nicht machbar wäre, aber übersichtlicher und einfacher zu konfigurieren wäre doch das alles zentral zu verwalten.

Du kannst doch eh alles was du benötigst (VLANS, DHCP) am Coreswitch abfackeln und die Firewall regelt eben die Zugriffe zum Schluss wenn du nicht mit ACLs am Switch arbeiten möchtest

OK, sorry das hatte ich übersehen ! OK, wenn du mehrere IP Segmente über einen Link auf die Firewall bringen willst oder musst ist das natürlich absolut richtig !
Diese 3 IP Netze dürfen dann logischerweise NICHT mit einer IP Adresse am Core Switch konfiguriert sein, das wäre na klar tödlich (Backdoor Route).
ToDos bleiben aber so wie oben beschrieben, nur eben Tagged Port mit Subinterfaces an der FW.
Nein, das macht keinerlei Unterschied ! Ist völlig egal. Abgesehen von dem Punkt das du mehr Kabelfrickelei bei Untagged hast da du da ja 3 separate Kabel ziehen müsstest !
Sorry, aber das Argument ist ja technischer Blödsinn !!
Der Core Switch hat logischerweise KEINE IP Adresse mehr aus diesen 3 Segmenten !! Damit ist er in das L3 Forwarding, sprich das Routing aus diesen 3 IP Netzen überhaupt nicht mehr involviert !
Das macht dann logischerweise einzig und allein NUR die Firewall. So soll es ja vermutlich auch sein um das sicher zu machen.
Im Gegenteil wenn du IPs auf dem Core in diesen 3 Netzen hättest wäre das mega fatal, denn damit hast du einen backdoor Router der dir die gesamte Sicherheit der FW aushebelt.
Vergiss das also ganz schnell ! Der Core soll ja in Bezug auf L3 de facto nichts wissen für diese 3 VLANs !!
Auch das ist ja Unsinn und gelogen wenn man deine o.a. Konfig sieht.
Wenigstens für VLAN 200 stimmt das ja genau nicht.
Hier widersprichst du dich also mit Anspruch und wirklichkeit !
Fakt ist aber auf alle Fälle: IP Netze deren IP Forwarding nicht über den Core gehen dürfen aus Sicherheitsgründen dürfen auch keine IP am Core in ihrem VLAN definiert haben ! Warum ist ja oben nachdrücklich erklärt.
Für diese simple Logik reicht aber auch der gesunde Menschenverstand !
Nein, nicht unbedingt ! Das kommt darauf an was du willst.
Wenn du die Gefahr eines Einbruchs aus den 3 IP Netzen generell verhindern willst dann konfigurierst du diese gar nicht erst auf dem Core. So verhinderst du durch die physische Trennung der VLANs dann jegliches IP Forwarding da und gehst auf Nummer sicher. Da auch keine ACLs dann logischerweise erforderlich sind sparst du dir auch die Gefahr falsch konfigurierter ACLs.
Diese 3 VLANs terminieert man L3 seitig dann nur auf der FW.

Willst du aber partout alles zentral auf dem Switch haben dann setzt du in allen VLANs auf IPs auf dem Core, routest da und schottest die 3 Netze mit entsprechenden ACLs auf dem Core ab.
Der Tagged Uplink dieser 3 Netze auf die Firewall ist dann natürlich sinnlos und damit obsolet...klar !
Im Gegenteil er ist dann sogar gefährlich und sollte immer entfernt werden.
Das ist doch alles eine ganz einafche Logik.
Die Konfig bzw. welche du nutzt hängt ganz klar von deiner Sicherheits Policy ab !

Es ist Unsinn einen Switch als DHCP Server zu konfigurieren für jedes VLAN Segment ! Sowas macht man in der Regel nicht als Netzwerker sondern betreibt einen zentralen DHCP mit IP Forwardern. Allein schon die DHCP zu DNS Kopplung bei Verwendung eines AD erzwingt das oft. Ein Switch kann sowas nicht leisten...soll er auch nicht.
Das müsste der TO. Ist ja auch logisch. Ohne IP Adresse auf dem Core mit einem isolierten L2 VLAN kann er ja nicht mit Forwardern arbeiten. Es sei denn über die Firewall. Dann müsste er aber wieder diverse Löcher bohren in diese was nicht eben sinnvoll ist. Folglich fungiert die FW dann für diese isolierten VLANs als DHCP. Das macht schon Sinn.
Erzwänge dann aber auch einen erheblichen zusätzlichen Aufwand ACL zu konfigurieren und auch zu pflegen auf dem Core. Entfällt bei isolierten VLANs und Zugang nur über die FW.
Ist aber wie oben schon gesagt Policy Sache...
Hier stellt sich aber dann wieder die Frage nach Effizienz, Sinnhaftigkeit und vor allen Dingen Sicherheit....?! Argumente siehe oben.
Was hier auch Sinn macht...

P.S.: Ist der Thread jetzt gelöst oder warum hat der TO den jetzt selber auf "gelöst" gesetzt ???

Was genau meinst du mit "an den Clients tut sich nix." ???
Mit Routing hast du gar nichts einzustellen.

Dein Gast VLAN 200 hat ja auf dem L3 Core Switch kein IP Interface konfiguriert !!! Das einzige IP Interface was im Gast VLAN 200 ist ist das der Firewall, da die mit einem untagged Port im VLAN 200 hängt.
Folglich ist also dann die Firewall für alle Clients im VLAN 200 der Weg nach draussen, sprich das Gateway.

Hier tut sich jetzt die erste Frage auf:
Wie kann es sein das du von einem Access Switch das VLAN 200 Gateway sprich also die IP Adresse der FW pingen kannst ?
Das dürfte bei richtiger Switchkonfig gar nicht möglich sein oder meinst du jetzt damit das du einen Client auf einem Access Switch ins VLAN 200 gesteckt hast und pingst jetzt von diesem VLAN 200 Client den Firewall Port ?
Das ist ja klar das das dann geht !!
Der Access Switch selber aber dürfte ja nie und nimmer nicht die Firewall im VLAN 200 pingen können.
Das ist auch klar, denn normal ist die Management IP des Switches im VLAN 1 und da der Core Switch keine IP im VLAN 200 hat kommen Ping Pakete mit einer Absender IP Adresse aus VLAN 1 nie ins VLAN 200. Wenn du vom Accessswith bzw. von dessen CLI Konsole pingst hast du ja dann zwangsläufig eine VLAN 1 Absender IP.
Soll ja auch genau so sein damit das Gast VLAN vollkommen isoliert ist und nur über die Firewall rauskommt...logisch !
Kannst du also irgendwas im VLAN 200 pingen von den VLANs am Core Switch wäre das fatal und ein gefährliches Sicherheitsloch. Zeigt dann auch gleichzeitig das du einen gravierenden Fehler im Switch Setup gemacht hast !!

Du musst jetzt einfach mal strategisch vorgehen:

• Wie gesagt: keine IP vom Core im VLAN 200. Einziges IP Gateway Interface ist das Firewall Interface im VLAN 200
• Firewall muss gültige VLAN 200 IP haben und ICMP erlauben damit es anpingbar ist
• Firewall muss zusätzlich DHCP Server spielen im VLAN 200 um den VLAN 200 Clients IP Adressen zu vergeben
• Ist das alles gemacht muss ein per Kabel angeschlossener Client im VLAN 200 auch IP Adressen von der FW bekommen. Das kannst du checken mit ipconfig i.d. Eingabeaufforderung
• Stimmen IP Adresse, Gateway und DNS (Gateway und DNS ist die FW) dann muss das Firewall Interface von diesem Client pingbar sein
• Ist es das pingst du jetzt mal eine Internet IP z.B. 8.8.8.8 ! Klappt das auch ist auch das Internet da
• Dann pingst du mal einen Domainnamen wie z.B. www.heise.de Klappt das funktioniert alles wie es soll

Damit kannst du dann sicher sein das kabelbasierend alles sauber funktioniert.
Wenn das Gastnetz auch per WLAN erreichbar sein soll, dann sollte es auch mit einem AP der im VLAN 200 steckt sauber funktionieren.

Vom Routing her must du NICHTS weiteres einstellen.
Clients im gast VLAN 200 bekommen die Firewall dort als Gateway und die routet ja eh ins Internet.
Clients am Core Switch (ohne VLAN 200 IP) bekommen als Gateway die Coreswitch IP in ihrem jeweiligen VLAN und der Switch hat eine Default Route auf die Firewall und so gelangen die ins Internet.
Allso alles ganz einfach un logisch !

Da einen tagged Port zu nehmen ist eigentlich sinnfrei ! Was soll das bringen ? Kannst du auch untagged lassen. Gut stören tut das Tagging nicht aber dir muss dann klar sein das der Port in VLAN 200 and dem die FW angeschlossen ist auch Tagged sein muss.
OK, das zeigt ja ganz eindeutig das du das VLAN 200 NICHT auf den Uplinks zu den Access Switches liegen hast ! Folglich wird VLAN 200 also auch nicht in den Access transportiert, klar !
Du musst auf allen Switch Uplinks vom Core zu den Access Switches logischerweise auch das VLAN 200 tagged dort konfigurieren !
Analog natürlich auch auf den Access Switches die das VLAN 200 bedienen. Auch auf deren Uplinks zum Core muss VLAN 200 tagged eingetragen sein !
Genau da liegt dein Fehler ! Das ist zu 99% vergessen worden oder fehlerhaft.

Es müsste ja schon ein simpler Ping scheitern zwischen 2 PCs oder Laptops die im VLAN 200 am Access und Core angeschlossen sind. Ggf. mit statischen Adressen.
Das wäre mal ein simpler Test das man eben diese 2 Rechner mal am Core in VLAN 200 steckt mit IP Adressen aus diesem VLAN und sie pingen lässt, was ja klappen sollte.
Nimm man einen nun am Access ins VLAN 200 sollte es eigentlich auch klappen.
Wenn wider Erwarten nicht, dann hast du genau das oben beschriebene Tagging Problem von VLAN 200 auf den Uplinks zum Access bzw. vom Access zum Core.
Das VLAN 200 ist dann im Tagging auf diesen Uplinks falsch oder fehlerhaft konfiguriert, das ist ganz eindeutig.