Ein UniFi Access Point kann ein starkes WLAN aufspannen, und trotzdem bekommt ein Endgerät keine Adresse vom Netz. Dann liegt das Problem oft nicht am Funk selbst, sondern an der Trennung zwischen VLAN-Zuordnung und DHCP-Vergabe. Genau diese beiden Wege solltest du getrennt prüfen, weil ein sauberer WLAN-Client nur dann online geht, wenn Layer 2 und Layer 3 zusammenpassen.
Die gute Nachricht: In vielen Fällen steckt die Ursache in einer falschen SSID-Zuordnung, einem fehlenden VLAN-Tag, einer falschen Port-Konfiguration am Switch oder einem DHCP-Server, der für das Zielnetz gar nicht erreichbar ist. Wer systematisch vorgeht, findet die Stelle meist schnell, ohne blind an mehreren Einstellungen gleichzeitig zu drehen.
Worum es bei dem Fehlerbild wirklich geht
Wenn ein Access Point sendet, aber der Client keine IP-Adresse erhält, funktionieren Funkverbindung und Authentifizierung häufig bereits. Das Gerät sieht das WLAN, verbindet sich vielleicht sogar erfolgreich, bleibt aber ohne nutzbare Netzwerkkonfiguration hängen. In der Praxis heißt das: Der Weg vom Client zum DHCP-Server ist unterbrochen oder die Zuordnung zum richtigen Netz ist falsch.
Das Problem wird oft vermischt, weil der erste Blick auf das WLAN fällt. Ein gutes Signal beweist aber noch nicht, dass der Traffic im richtigen VLAN landet oder dass ein DHCP-Server auf diesem Segment antworten kann. Wer beide Ebenen getrennt betrachtet, spart sich viele Umwege.
Die zwei Ebenen, die du getrennt prüfen solltest
Für die Diagnose lohnt sich eine einfache Denkweise. Zuerst prüfst du, ob der Client im richtigen VLAN landet. Danach prüfst du, ob in diesem VLAN ein erreichbarer DHCP-Server arbeitet und Antworten zurückkommen. Erst wenn beide Ebenen stimmen, bekommt das Endgerät zuverlässig eine Adresse.
Diese Trennung hilft auch bei Sonderfällen. Manche Netze verwenden nur ein einziges ungetaggtes WLAN. Andere setzen auf mehrere SSIDs mit verschiedenen VLANs. Wieder andere lassen den DHCP nicht im selben Gerät laufen, sondern auf Router, Firewall oder Server. Je nach Aufbau kann derselbe Fehler ganz unterschiedliche Ursachen haben.
- Ebene 1: SSID, VLAN, Switchport und Trunk prüfen.
- Ebene 2: DHCP-Server, Scope, Relay und Erreichbarkeit prüfen.
- Ebene 3: Client-seitige Störungen wie gespeicherte Profile oder feste IPs prüfen.
VLAN-Zuordnung sauber überprüfen
Die VLAN-Prüfung beginnt bei der SSID. In UniFi ist entscheidend, ob das Funknetz einem bestimmten Netzsegment zugewiesen ist oder ob es ungetaggt in das Standardnetz fällt. Wenn ein WLAN mit VLAN 20 konfiguriert ist, der Uplink-Port aber nur das Default-VLAN durchlässt, landet der Traffic im Nirgendwo oder im falschen Netz.
Typisch ist auch ein Missverständnis zwischen Switch und Access Point. Der AP selbst kann das WLAN korrekt ausstrahlen, aber der Switchport, an dem er hängt, muss die getaggten VLANs erlauben. Ist der Port als Access-Port statt als Trunk konfiguriert, kommen getaggte Frames oft nicht dort an, wo sie gebraucht werden.
Ein sauberer Kontrollgang sieht in der Praxis so aus: Prüfe die SSID-Zuordnung im UniFi-Controller, prüfe das Netzwerkprofil mit VLAN-ID, prüfe den Switchport des Access Points und prüfe danach, ob der Uplink zum Router oder Core-Switch die gleichen VLANs transportiert. Wenn an einer dieser Stellen ein Widerspruch auftaucht, ist die Fehlersuche fast immer dort zu Ende.
Ein häufiger Stolperstein ist das Native VLAN. Manche Umgebungen mischen ungetaggten und getaggten Verkehr auf demselben Port. Das funktioniert, solange alle beteiligten Geräte dieselbe Erwartung haben. Sobald ein Gerät ein anderes Native VLAN annimmt als das Gegenüber, wird die Zuordnung unsauber und der DHCP-Verkehr verschwindet scheinbar grundlos.
DHCP getrennt davon prüfen
Wenn das VLAN stimmt, muss noch ein DHCP-Server im Zielnetz antworten. Hier liegt der zweite große Fehlerbereich. Der Server kann aus, falsch konfiguriert, überlastet oder über einen falschen Pfad nicht erreichbar sein. Dann sendet der Client DHCP-Discovers, bekommt aber keine Offer-Antwort zurück.
Wichtig ist, den DHCP-Bereich nicht nur global zu betrachten. Ein Router kann für ein Netz sauber Adressen vergeben und im anderen Netz leer laufen, weil kein passender Scope existiert. Auch eine zu kleine Adressreserve kann dazu führen, dass neue Clients leer ausgehen, obwohl alles sonst richtig aussieht.
Wenn DHCP auf einem separaten Server läuft, muss die Weiterleitung stimmen. Das gilt besonders bei VLANs. Ein DHCP-Relay oder IP-Helper muss den Broadcast aus dem Client-VLAN an den Server weitergeben. Ohne diese Weiterleitung hört der Server schlicht nichts von den Anfragen.
Auch die Zeit ist relevant. Manche Geräte zeigen den Fehler erst nach ein paar Sekunden, andere werfen sofort auf eine Selbstzuweisung oder auf eine alte Adresse zurück. Wer den Verbindungsaufbau beobachtet, sieht oft erst beim DHCP-Schritt, dass die Kommunikation im Zielnetz nicht ankommt.
So gehst du sinnvoll vor
Beginne mit einem einzelnen Testgerät und einem einzelnen WLAN. So bleiben die Signale klar und du kämpfst nicht gleichzeitig mit mehreren Clients, mehreren SSIDs und mehreren Switches. Danach arbeitest du dich in dieser Reihenfolge durch die Strecke: Funkverbindung, SSID-zugewiesenes Netz, Switchport, DHCP-Erreichbarkeit.
- Prüfe, ob der Client sich sauber mit dem WLAN verbindet und ob das richtige SSID-Profil verwendet wird.
- Prüfe die VLAN-ID des Netzwerks, das dem WLAN zugeordnet ist.
- Prüfe den Port des Access Points am Switch und die dort erlaubten VLANs.
- Prüfe, ob der DHCP-Server für dieses VLAN Adressen vergibt.
- Prüfe, ob ein Relay, Helper oder eine Firewall-Regel den DHCP-Verkehr blockiert.
Wenn nach Schritt 3 noch kein Verdacht auf den DHCP-Teil vorliegt, dann lohnt sich ein Blick auf die Zuordnung zwischen Portprofil und Uplink. Wenn dagegen das VLAN sauber wirkt, der Client aber trotzdem keine Adresse bekommt, liegt die Ursache meist im DHCP-Pfad oder im Scope selbst.
Typische Fehlerbilder aus der Praxis
Ein klassischer Fall ist ein neues Gäste-WLAN, das ein eigenes VLAN bekommt, während der dazugehörige Switchport nur das Standardnetz weiterreicht. Das WLAN erscheint normal, Geräte verbinden sich, aber die Adressvergabe bleibt aus. Hier ist meist nicht der Access Point schuld, sondern die fehlende Freigabe des VLANs auf dem Kabelweg.
Ein anderer Fall ist ein DHCP-Server auf einem Windows-Server oder auf einer Firewall, die zwar grundsätzlich läuft, aber keinen Bereich für das neue VLAN hat. Der Access Point sendet brav, das Endgerät fragt nach einer Adresse, der Server schweigt. Ohne passenden Bereich bleibt das Segment leer.
Ein drittes Muster sieht man bei Mischumgebungen mit alter und neuer Infrastruktur. Der Access Point hängt an einem managed Switch, dahinter sitzt noch ein älterer Router, und irgendwo dazwischen wird ein VLAN durch einen unpassenden Portmodus abgeschnitten. Das WLAN wirkt stabil, aber die Adressvergabe scheitert an der unsichtbaren Grenze zwischen den Geräten.
Was du am Access Point selbst prüfen kannst
Der Access Point ist selten allein die Ursache, aber er ist ein guter Ausgangspunkt. Prüfe, ob die richtige SSID aktiv ist, ob eine VLAN-ID für das WLAN hinterlegt wurde und ob der AP die erwartete Konfiguration übernommen hat. Gerade nach Änderungen kann es etwas dauern, bis die Konfiguration auf allen Geräten sauber ankommt.
Wenn du mehrere APs nutzt, vergleiche deren Status. Ein einzelner falsch übernommener Konfigurationsstand kann dazu führen, dass ein Teil der Clients funktioniert und ein anderer Teil nicht. Dann sieht der Fehler wie ein Funkproblem aus, obwohl es nur eine abweichende Netzzuordnung ist.
Auch Firmware und Controller-Stand können eine Rolle spielen, wenn Konfigurationen zwar sichtbar sind, aber nicht sauber angewendet werden. Dann hilft oft ein kurzer Konfigurationsabgleich mehr als ein radikaler Reset. Erst prüfen, dann handeln, das spart Zeit und Nerven.
Was am Switch und Uplink stimmen muss
Der Switchport des Access Points ist oft der entscheidende Punkt. Er muss die VLANs tragen, die die SSIDs nutzen, und zwar in der Form, die das Netzdesign erwartet. Wenn der Port als reiner Access-Port läuft, aber der AP mehrere getaggte Netze ausstrahlen soll, entstehen sehr schnell Zuordnungsfehler.
Bei einem Trunk-Port ist außerdem wichtig, welches VLAN ungetaggt bleibt und welche VLANs getaggt passieren dürfen. Ein zu restriktives Portprofil kann einzelne SSIDs lahmlegen, während andere noch funktionieren. Gerade deshalb ist ein stufenweiser Test wertvoll: erst ein Netz, dann das nächste.
Auch der Uplink nach oben darf nicht vergessen werden. Wenn der Switch zum Router oder Core-Switch die VLANs nicht weiterträgt, nützt die beste AP-Konfiguration wenig. In vielen Netzen liegt genau dort die Ursache, weil der Uplink irgendwann manuell geändert wurde und niemand die Folgewirkung bemerkt hat.
Wenn DHCP eigentlich da ist, aber trotzdem nichts kommt
Manchmal ist DHCP vorhanden, aber der Client erhält dennoch keine Adresse. Dann blockiert häufig eine Firewall-Regel, ein falsches Relay-Ziel oder eine Port-Isolation den Rückweg. DHCP lebt von Broadcasts und Antworten, und diese Wege sind empfindlicher, als viele denken.
In größeren Netzen spielt auch die Trennung von Management- und Nutzdaten eine Rolle. Ein Access Point kann selbst verwaltet werden, ohne dass sein Clientnetz korrekt geroutet ist. Das wirkt zunächst widersprüchlich, ist aber in sauber segmentierten Netzen völlig normal. Der Verwaltungszugang ist eben nicht automatisch der Datenpfad für die WLAN-Clients.
Wenn ein DHCP-Server im selben Subnetz wie der Client sitzt, aber trotzdem keine Vergabe stattfindet, lohnt sich ein Blick auf Konflikte im Adressbereich. Doppelvergabe, ausgeschöpfte Scopes oder Reservierungen können den Eindruck erwecken, als würde gar nichts antworten, obwohl der Server aktiv ist. Ein kurzer Blick in die Lease-Liste bringt hier oft mehr Klarheit als langes Rätseln.
Woran du erkennst, dass das Problem auf Client-Seite liegt
Nicht jeder Fehler sitzt im Netz. Manche Endgeräte behalten alte WLAN-Profile, feste IPs oder Captive-Portal-Reste, die den automatischen Bezug stören. Dann liegt die Verbindung zwar an, aber der Client verhandelt nicht sauber neu.
Wenn nur ein einzelnes Gerät betroffen ist, andere Geräte im selben WLAN aber sofort eine Adresse bekommen, spricht das eher für eine lokale Ursache. Dann helfen gespeicherte Netzwerke löschen, das WLAN neu verbinden oder eine Netzwerkfreigabe zurücksetzen. Erst wenn mehrere Clients im gleichen Netz betroffen sind, solltest du wieder stärker auf die Infrastruktur schauen.
Besonders vorsichtig solltest du bei Geräten mit manueller IP-Konfiguration sein. Ein fest eingetragenes Gateway oder ein alter DNS-Server kann den Eindruck erwecken, als gebe es keinen Netzwerkzugang, obwohl die Adressvergabe gar nicht im Spiel ist. Dann ist die eigentliche Fehlerquelle schnell übersehen.
Ein sinnvoller Test ohne Werkzeugchaos
Du brauchst für die erste Eingrenzung keine Spezialausrüstung. Ein einziges Testgerät, Zugang zur UniFi-Verwaltung und, falls vorhanden, ein Blick in die DHCP-Logs reichen oft schon aus. Ziel ist nicht, alles gleichzeitig zu messen, sondern die Stelle zu finden, an der die Kette unterbrochen wird.
Praktisch funktioniert das so: Verbinde ein Testgerät mit dem betroffenen WLAN, beobachte die IP-Vergabe, prüfe dann in der Verwaltung, ob der Client im erwarteten VLAN auftaucht. Wenn die Zuordnung stimmt, der Client aber kein Lease erhält, liegt der Fokus danach klar auf DHCP, Relay oder Firewall. Wenn die Zuordnung schon falsch ist, musst du den DHCP-Teil noch gar nicht anfassen.
Wann ein Neustart hilft und wann nicht
Ein Neustart von Access Point, Switch oder DHCP-Dienst kann alte Zustände bereinigen, wenn Konfigurationen frisch geändert wurden. Das ist besonders nach VLAN-Umstellungen sinnvoll, weil manche Geräte ihre Tabellen oder Leases nicht sofort neu aufbauen. Ein sauberer Reboot ist oft der schnellste reversible Schritt.
Wenn das Problem danach bleibt, ist die Ursache meist strukturell und nicht nur temporär. Dann solltest du Portprofile, VLAN-Mapping und DHCP-Scope sauber gegeneinander halten. Ein bloßes Wiederholen desselben Reboots löst so ein Problem selten dauerhaft.
Woran man sich bei künftigen Änderungen orientieren kann
Bei WLANs mit mehreren Netzen hilft eine feste Reihenfolge bei jeder Änderung. Erst das VLAN planen, dann den Switchport vorbereiten, dann den DHCP-Bereich anlegen, danach die SSID zuweisen und am Ende mit einem Testclient prüfen. So vermeidest du die typische Situation, in der ein Teil des Pfads schon aktiv ist und der andere noch nicht.
Wer diese Reihenfolge einhält, erkennt Fehler außerdem schneller. Wenn ein neuer SSID-Eintrag nicht funktioniert, weißt du sofort, ob der Fehler bei der Zuordnung, beim Uplink oder beim DHCP liegt. Das macht spätere Änderungen deutlich überschaubarer, vor allem in Netzen mit mehreren Access Points und mehreren Segmenten.
Das Muster hinter dem Fehler
Das Kernproblem ist fast immer eine Unterbrechung zwischen zwei Ebenen. Entweder landet der Client im falschen Netz, oder das richtige Netz hat keinen funktionierenden DHCP-Pfad. Beides sieht für den Nutzer ähnlich aus, wird technisch aber an unterschiedlichen Stellen behoben.
Wer VLAN und DHCP getrennt betrachtet, spart sich unnötige Experimente. Erst die Netzzuordnung sichern, dann die Adressvergabe prüfen, danach erst auf Sonderfälle gehen. Genau so wird aus einem unklaren WLAN-Problem wieder ein sauber eingrenzbarer Netzfehler.
FAQ
Wie trenne ich VLAN-Problem und DHCP-Problem am schnellsten?
Der schnellste Weg ist ein Stufentest mit fester IP. Erreichst du damit andere Geräte im selben VLAN, aber kein DHCP-Client bekommt automatisch eine Adresse, liegt der Fokus auf dem DHCP-Pfad oder auf der Weiterleitung zwischen VLAN und Server.
Woran erkenne ich, ob der Access Point das richtige VLAN taggt?
Prüfe die SSID-Zuordnung im UniFi-Controller und die Port-Konfiguration am Switch. Der Uplink-Port zum Access Point muss den verwendeten VLAN-Tag als Tagged- oder Trunk-Verkehr führen, während das Management-VLAN nur dann untagged bleiben sollte, wenn das so geplant ist.
Welche Rolle spielt das Native VLAN am Switch-Port?
Das Native VLAN bestimmt, welcher Verkehr ungetaggt über den Port läuft. Ist es falsch gesetzt, landet der Access Point oder ein Client in einem anderen Netz als erwartet, obwohl die Funkverbindung selbst sauber wirkt.
Wie prüfe ich, ob der DHCP-Server überhaupt Antworten sendet?
Nutze einen DHCP-Discover-Test und beobachte, ob ein Offer zurückkommt. Kommt auf dem Server alles an, aber am Client nichts zurück, liegt oft ein Filter, ein VLAN-Fehler oder ein Problem auf dem Rückweg vor.
Kann ein funktionierendes WLAN trotzdem keine IP vergeben?
Ja, denn WLAN-Verbindung und IP-Vergabe sind getrennte Schritte. Die Funkstrecke kann stabil sein, während VLAN-Tagging, DHCP-Relay, Firewall-Regeln oder ein falscher Switch-Port die Adressvergabe blockieren.
Welche UniFi-Einstellungen sollte ich zuerst kontrollieren?
Beginne mit der SSID, dem zugewiesenen Netzwerk und der VLAN-ID. Danach prüfst du, ob der Access Point selbst im richtigen Management-Netz hängt und ob der Uplink-Port die passende Port-Profil-Zuweisung hat.
Wie finde ich heraus, ob der DHCP-Server im falschen Netz steht?
Vergleiche die Subnetzmaske, das Gateway und den Bereich der DHCP-Scopes mit dem VLAN des WLANs. Stimmen diese Werte nicht zusammen, erhält der Client entweder keine Antwort oder eine Adresse aus einem unpassenden Netz.
Was mache ich, wenn nur einzelne Clients keine IP erhalten?
Dann lohnt sich ein Blick auf die Client-Netzwerkeinstellungen, gespeicherte WLAN-Profile und eventuelle statische Adressen. Tritt das Problem nur auf einem Gerät auf, ist der Access Point meist nicht die Ursache.
Warum hilft ein Neustart manchmal nur kurz?
Ein Neustart kann einen hängen gebliebenen Prozess oder einen fehlerhaften Lease-Zustand beseitigen. Bleibt aber VLAN, Port-Profil oder DHCP-Relay falsch, kehrt der Fehler nach kurzer Zeit zurück.
Welche Messung ist für die Diagnose am aussagekräftigsten?
Am hilfreichsten ist eine Kombination aus DHCP-Log, Switch-Port-Status und einer festen Testadresse im Zielnetz. Damit siehst du schnell, ob das Paket am richtigen Ort ankommt und ob die Rückantwort den Client erreicht.
Fazit
Sauber getrennt geprüft, lässt sich das Fehlerbild meist zügig auflösen: Erst die VLAN-Strecke vom Client bis zum Gateway, dann die DHCP-Versorgung im Zielnetz. Wer Portprofil, SSID, Relay und DHCP-Scopes systematisch abgleicht, findet die Ursache meist ohne Umwege und verhindert, dass das Problem beim nächsten Umbau wieder auftaucht.
