WLAN AP - Problem mit DHCP - Client bekommt keine IP

[crazy-kermit]

Hallo zusammen!

Nachdem ich u.a. mit Hilfe dieses Forums mein Heimnetzwerk komplett neu aufgebaut habe und bis auf mein PiHole alles soweit funktioniert, bin ich heute auf ein Problem gestoßen, welches ich nicht als Sackgasse ansehen möchte. Einige Themen hier reißen mein Problem an, behandeln nach meinem Verständnis aber andere Probleme oder es sind andere Konfigurationen wie unter Proxmox o.ä.

Vorweg meine Netzwegtopologie:



Ergänzung zum Bild - falls wichtig:

Modem = DrayTek Vigor 167
OPNsense = NRG-System IPU651
Switch 1 = Netgear GS110TPv2
Switch 2 = TP Link TL-SG3210

Bezüglich der LAGs und der VLANs klappt alles wie gewünscht. Ein paar Regeln für SMB etc. braucht es noch, doch das bekomme ich vermutlich alleine hin.

Nun war der WLAN-AccessPoint dran. Wie in der Topologie zu sehen, soll dieser 4 WLANs bereitstellen, welche entsprechend der VLANs getaggt sein sollen. Für meine Zwecke ausreichend empfand ich den Netgear WAX210.
In dessen WebGUI habe ich die VLANs mit eigenen SSID konfiguriert und auch die Stromversorgung via PoE klappt am Switch1 (Netgear GS110TPv2) super.
Nachdem ich zusätzliche Regeln für DHCP (Port 67 und 68) für den AP angelegt habe, hoffte ich alles zu haben.

Problem:

Am Smartphone stellte ich fest, dass dieses im WLAN100 (VLAN100) keine IP erhielt.
Nach langer Recherche auch in diesem Forum las ich was von DHCP-Relay. Für mich als Nicht-ITler eine neue weitere Herausforderung. Aber hey, ich wollte ja von der alten Fritzbox auf OPNsense wechseln.

Da ich trotzt eingerichten DHCP-Relay in OPNsense nicht weiterkam und eine fehlende Funktion im AP vermutete, kontaktierte ich den Netgear-Support. Dabei kam letztlich heraus, dass nicht der AP das Problem ist, sondern der Switch. Denn der GS110TPv2 unterstützt gar kein DHCP-Relay.

Der Support empfahl mir, den AP direkt an der OPNsense anzuklemmen, konnte mir dazu verständlicherweise aber keine weiteren Infos geben.
Das würde grundsätzlich auch gehen, da der Firewall-PC (IPU651) noch 3 freie Ports hat. Würde der AP dann aber nicht ein völlig eigenes Netzwerk haben?

Das Gast-WLAN wäre völlig egal, das könnte völlig eigenständig laufen (ist aus Sicherheitsgründen vermutlich eh besser als ein dediziertes VLAN, oder?!), doch innerhalb des VLAN100 möchte ich auch via WLAN auf das TrueNAS zugreifen können. Und: das WLAN1 (VLAN100) und WLAN2 (VLAN200) sollten eigentlich so über die OPNsense laufen, dass ich diese Netze via PiHole werbe- und trackingfrei halten kann.

Zusammenfassung meiner teils erfolgreich umgesetzten Planung:

✅ Privat1 und Privat2 sollen getrennte Netze sein
✅ Innerhalb Privat1 soll alles mit jedem dürfen
❌ Innerhalb WLAN100 sollen alles laufen wie im VLAN100-Privat1
✅ SmartTV und evtl. spätere weitere Smart-Geräte sollen an allem vorbei nur ins Internet dürfen - mehr nicht
❌ Gast-WLAN vom normalen getaggten WLAN getrennt (kein Zugriff auf die private Netze)
🔶 alle Netze sollen via PiHole (notfalls auch AdGuard) gefiltert werden - vor allem für die Kinder wichtig*1)
🔶 der Drucker soll aus VLAN100 und VLAN200 erreichbar sein
✅ nichts soll von außen erreichbar sein - auch nicht das TrueNAS

✅=fertig / ❌=Fehler/ 🔶=(noch)ausstehend

*1) vor allem will ich die vielen Hirnweichmacher wie Tiktok etc. rigoros sperren, deswegen sollen die Kinder eigentlich ins getaggte WLAN200/VLAN200, damit das geht.

DHCP ist auf allen VLANs aktiviert und die Verteilung der IPs auf den LAN-Clienten klappt tadellos. Nur eben nicht bei Clienten am WLAN-AP in denselben VLANs!

Habe ich mir das zu einfach vorgestellt bzw. habe ich mich da übernommen? Das sah auf dem Papier alles umsetzbar aus..  ???
Wie sollte ich mein Vorhaben alternativ umsetzen - gerne, ohne neue Hardware kaufen zu müssen.

Beste Grüße

[meyergru]

Also zunächst mal benötigt man keine speziellen Regeln für DHCP in den (V)LANs, es ist auch kein DHCP Relay notwendig. Das macht man nur, wenn man mehrere geroutete Netze hat, weil DHCP-Requests per Broadcast gesendet werden und man dann einen "Stellvertreter" im entfernten Netz hat (eben das DHCP Relay).

In Deinem Fall hast Du mit den Switches einen Backbone, der an den LAGG-Ports und am Port für den AP eben Trunks mit allen (V)LANs hat. Für Endgeräte schaltet man auf den Port eben die entsprechenden VLANs untagged auf. So hast Du es ja auch eingezeichnet.

Die Switches sollten natürlich managebar sein. Ich kenne den WLAN-AP nicht, ich setze selbst Unifi-APs ein, auf denen das genau so funktioniert mit 1:1-Zuordnung von VLANs auf WLANs. Offenbar kann der Netgear verschiedene Modi, auch solche, in denen er selbst DHCP macht.

Wenn er 1:1-Zuordnung kann, sollten die DHCP-Requests und -Replies der OpnSense aber durchgehen - wenn nicht, ist das Problem dort zu suchen.

[crazy-kermit]

Sorry für das späte Feedback, @meyergru. Was auch immer nicht stimmte...nach einer kompletten Neuinstallation der OPNsense und einem Firmware-Update mit anschließendem Neustart klappte es mit der IP-Verteilung des OPNsense-DHCP an die WLAN-Clienten. Bin mir nicht bewusst, etwas anderes eingerichtet zu haben, zumal ich mir selbst einen Leitfaden zusammengestellt habe, den ich auch beim ersten Mal exakt befolgt habe.

Ich hatte zwischendurch das Gefühl, dass etwas am Regelwerk nicht stimmen könnte, denn in der Liveansicht sah ich immer wieder DHCP-Anfragen, welche geblockt wurden, obwohl innerhalb eines Subnetzes doch alles nur bis zur Firewall gehen sollte, und nicht durch sie hindurch. Oder etwa doch?
Aber okay, DHCP am WLAN-AP klappt nun und es scheint auch nichts mehr geblockt zu werden.

Allerdings gibt es nun Probleme mit Samba: in der Liveansicht werden ständig netbios-Anfragen vom PC auf mein NAS geblockt. Es gibt aber gar keine manuelle Regel, die das besagt. Es greift ständig die "Default deny / state violation rule", was mich sehr verwundert. Ich weiß noch, dass diese Regel immer wieder bei dem DHCP-Problem in der Liveansicht stand.

Ich hatte testweise eine Regel nach dem Schema IPv4 TCP/UDP VLAN10-Netzwerk  *  VLAN10-Netzwerk Alias-NetBIOS (Ports 137,138,139,445) aktiviert. Immer wieder greift die "Default deny / state violation rule", sobald ich mit dem PC via SMB auf die Freigabe auf dem NAS zugreifen woll. Auch mein Backup-Tool (Macrium reflect), das sonst mit einem Affenzahn die Sicherungen aufs NAS schiebt, bricht wegen unerwarteter Netzwerkprobleme ab.

Nun habe ich alle Regeln deaktiviert und eine "VLAN10 allow any" Regel erstellt (von der "Default allow LAN to any rule" nach VLAN10 kopiert), die OPNsense rebootet und dennoch matcht ständig die "Default deny / state violation rule".





An welcher Stelle in der OPNsense muss ich da nach einem Fehler suchen? Nach meinem Verständnis sollte doch nun innerhalb des VLAN10 gar nichts mehr geblockt werden.

[meyergru]

Die Default Deny Regel schlägt oft dann zu, wenn Pakete im falschen State ankommen, z.B. wenn es asymmetrisches Routing gibt oder Pakete doppelt registriert werden.

Ich würde hier auf Probleme mit den VLANs oder dem LAG tippen - Du hast einen Mix aus zwei Switch-Herstellern und dann noch einen AP, der mit mehreren VLANs arbeitet. Da kann es überall sein, dass getaggte/ungetaggte Pakete an der falschen Stelle sichtbar werden. Man soll ja z.B. bei FreeBSD keine tagged/untagged VLANs mischen. Verschiedene Hersteller fassen das "ungetaggte" VLAN z.T. unterschiedlich auf.

Auch LAGG gibt es in verschiedenen Varianten - da müssen sich Netgear und TP-Link keineswegs "verstehen". Das ist natürlich schwierig zu debuggen, weil Dein Zoo ziemlich umfangreich ist. Ich würde als erstes mal die LAGGs entfernen bzw. jeweils ein Kabel kappen und mich dann vortasten.

Dass es nicht an den Regeln liegt, siehst Du ja. Es sind die States - da spuckt irgendwas rein.