xaero1982
Goto Top

WLAN - 1 SSID - 2+ Subnetze + NPS -Server

Moin Zusammen,

folgendes ist gegeben:

15 Unifi AP AC Pro
Windows-Server für Radiusauthentifizierung über den Username
1 WLAN SSID
1 WLAN Subnetz mit 230 IP Adressen
Cisco Switche mit verschiedenen VLANs u.a. aktuell eins für die WLAN APs und Clients
DHCP auf einem Windows-Server

Problem:
Es werden mehr IP Adressen benötigt, wobei ich kein 23er Subnetz haben möchte.

Ziel:
Gerätespezifische Zuweisungen zb über Gerätenamen oder MAC Adressen zu verschiedenen Subnetzen.

Ich meine mal gelesen zu haben, dass das geht.

Ich bin mir nur gerade nicht ganz sicher bzgl. des Vorgehens.
Regeln für den Radius muss ich mal rumexperimentieren, was das sinnvollste ist für die Vergabe. Über diese Regeln kann ich dann auch das VLAN mitgeben.
D.h. ich brauche pro weiterem Subnetz natürlich ein weiteres VLAN auf den Switchen, welches ich den Accesspoint-Ports zuordne als tagged.
Am Accesspoint selbst sollte ich gar nichts ändern müssen?
Anpassungen noch an der PFSense für die neuen VLANs.

Mehr sollte es doch gar nicht sein oder?

Beste Grüße
x

Content-Key: 8675765327

Url: https://administrator.de/contentid/8675765327

Printed on: May 20, 2024 at 11:05 o'clock

Member: Visucius
Visucius Apr 25, 2024 at 11:52:37 (UTC)
Goto Top
Stichwort: Dynamische vLAN-Zuordnung über Radius
Member: NordicMike
NordicMike Apr 25, 2024 updated at 11:56:35 (UTC)
Goto Top
Für die Unifi APs musst du noch ein Radius Profil anlegen. Im Radius Profil muss angeklickt sein:
RADIUS-zugewiesenes VLAN für Drahtlos-Netzwerke aktivieren

Dann muss noch die IP vom Windows Server dort rein.

Das WLAN Profil muss auf WPA2-Enterprise umgestellt werden und dann kann man darunter auch angeben welches Radius Profil dafür zuständig ist. Da wählst du das neue oben erstelle Profil aus.

Das war es erst einmal Accesspoint seitig.


MAC Adressen werden nicht mehr verwendet, da es unsicher geworden ist. Jeder Client kann siene MAC Adresse ändern. Die MD5 Verschlüsselung dafür ist serverseitig auch schon deaktiviert und du müsstest es per Registry Eintrag wieder aktivieren. Das würde ich nur machen wenn keine Sicherheit nötig ist. Ist aber auch nicht nötig, da es nur Verwaltungsaufwand kostet, lieber machst du dir eine Regel z.B. anhand einer OU im AD.
Member: aqui
aqui Apr 25, 2024 updated at 12:30:31 (UTC)
Goto Top
Dynamische VLANs... Sollte doch auch für dich ein alter (WLAN) Hut sein. face-wink
Alle ToDos unter Freeradius Management mit WebGUI und seinen weiterführenden Links.
Member: ThePinky777
ThePinky777 Apr 25, 2024 updated at 12:38:16 (UTC)
Goto Top
also du hast den NPS Server schon ?

Falls nicht, man muss dort dann Clients erfassen (Clients = Switche)
und den switch mit dem server koppeln, hab das nur LAN mässig bisher gemacht aber
geht bestimmt mit dem WLAN Controller auch dann...

Dann gibts Network Policy Rules am NPS Server

hier gehts realtiv easy:

Du erstellst eine AD Gruppe z.B. Group_VLAN10 oder Group_VLAN12 oder what ever.
Da musst du dich entscheiden willst du user auth oder maschinen auth machen.
Wenn AD User technisch dann kommen halt user in die gruppe, wenn geräte spezifisch kommen computerkonnten in die gruppe.

Lasche Conditions:
NAS Port Type Ethernet oder Wireless halt einstellen
Und Add >> Windows Group, entsprechend erstellte Gruppe hinzufügen.

Dann Lasche Constraints
Bei Authentication Methods entsprechend korrekt einstellen wie sich die geräte authentifizieren werden,
Also PEAP und EAP-MSCHAP v2
Unten wenn man pech hat muss man PAP, SPAP enablen...

Lasche Settings:
Bei Standard >> Framed-Protokoll PPP
>> Service-Type Framed
>> Tunnel-Medium-Type 802 (includes all 802.....)
>> Tunnel-Pvt-Group-ID HIER VLAN NUMMER EINTRAGEN z.B. 12
>> Tunnel-Type Virtual LANs (VLAN)

Fertig.

Unter eventviewer
Custom Views
> Server Roles
> Network Policy and Access Services
kann man dann events sehen

kommt hier nix an passt was nicht, bedeutet keine kommunikation zwischen Device und NPS Server.
Wenn was ankommt wird entweder Access Granted oder eben nicht, wenn nicht bringen einen hier die Fehler realtiv leicht weiter zur Problem Lösung.
Member: aqui
aqui Apr 25, 2024 at 12:58:48 (UTC)
Goto Top
Falls nicht, man muss dort dann Clients erfassen...
Kollege @Xaero1982 ist ein alter Dot1x Hase wie seine themenbezogenen Threads dazu ja zeigen! face-wink
Member: Xaero1982
Xaero1982 Apr 25, 2024 at 16:00:18 (UTC)
Goto Top
Danke danke, aber vieles hatte ich ja schon geschrieben, was schon existiert und wie es aktuell auch schon läuft.

Mir ging es nur darum, ob ich noch irgendwas vergessen hatte. Der Rest mit der dynamischen VLAN Zuweisung ist dann klar. Darum ging es mir ja face-smile

Dann sollte das so passen. Ich danke euch und wünsche schon mal ein schönes Wochenende.

Danke @aqui face-smile mach das aber nun auch nicht täglich face-smile
Member: Xaero1982
Xaero1982 Apr 25, 2024 at 16:02:38 (UTC)
Goto Top
Die Regeln für die Verteilung muss ich mir durch den Kopf gehen lassen.
Die Nutzer verwenden halt 2-3 Geräte gleichzeitig und daher platzt der DHCP Bereich leider. D.h. über eine OU (alle sind in einer) wird das nichts. WLAN Geräte vom Kunden selbst kann ich separieren - dann mal weiter sehen.

Danke euch face-smile
Member: ThePinky777
ThePinky777 Apr 25, 2024 updated at 16:21:34 (UTC)
Goto Top
Zitat von @Xaero1982:

Die Regeln für die Verteilung muss ich mir durch den Kopf gehen lassen.
Die Nutzer verwenden halt 2-3 Geräte gleichzeitig und daher platzt der DHCP Bereich leider. D.h. über eine OU (alle sind in einer) wird das nichts. WLAN Geräte vom Kunden selbst kann ich separieren - dann mal weiter sehen.

Danke euch face-smile

Ja dann Geräte (Computerkonten) in eine AD Gruppe und per AD Gruppe in entsprechendes VLAN zuweisen.
Dann landen diese Geräte immer in dem Definierten VLAN. Und dann halt so lange rumskalieren bis es passt...

ODER Langfristig bestimmt besser

man definiert sein netzwerk um oder neu, bedeutet grössere subnetzte in den VLANs,
seit dem ich das auch einmal durchleiden musste definiere ich meine Subnetze grundsätzlich 2-3 grösser als der realistische bedarf aktuell ist. Dann hat man immer genug luft zu atmen face-smile
Weil es ist dann ja auch voll die hölle das ganze dann mit mehreren standorten dann zu routen usw...
dann lieber client netzwerk /22 definieren als nur /24 oder Server auch gerne mal /23 statt /24, auch wenn man nur 150 server hat oder so....
Member: Xaero1982
Xaero1982 Apr 25, 2024 at 17:01:54 (UTC)
Goto Top
Ehm never kommt mir nen 23 oder 22er Netz ins Haus, so lange ich das vermeiden kann und das kann ich hier face-smile
Member: Visucius
Visucius Apr 25, 2024 at 17:13:30 (UTC)
Goto Top
Und wo läge da das Problem, ganz konkret?! Ich meine, bevor Du solche Klimmzüge machst um das zu umgehen?! Du hast doch nachher trotzdem nicht mehr Clients?!
Member: aqui
aqui Apr 25, 2024 updated at 17:27:05 (UTC)
Goto Top
Die Nutzer verwenden halt 2-3 Geräte gleichzeitig und daher platzt der DHCP Bereich leider.
Wenn du keine dynamischen VLANs verwenden willst segmentiere das dann nach Stockwerken, Gebäuden etc. Die SSID bleibt gleich wird dann aber lokal in unterschiedliche VLAN IDs je nach Stockwerk, Gebäude etc. gemappt.

Dynamische VLANs lösen dein Problem dann nicht wenn die User dann doch wieder dynamisch in ein und dasselbe VLAN kommen.
Du musst deine User dann gruppieren und den Gruppen dann dynamische VLANs zuweisen.
Eine dummes, flaches WLAN mit mehr als 100 gleichzeitigen Usern hat im WLAN noch fatalere Folgen als im Kupfer, weil das gesamte Broad- und Multicast Grundrauschen erheblich zu Lasten der Airtime geht. Ganz besonders wenn die WLAN HW keine Multicast zu Unicast Konvertierung supportet.
Solche Ratschläge wie von der rosa 777 WLAN L2 Domains unendlich groß zu machen sind völliger Unsinn und eher laienhaft. Sie führen zum schnellen Tod eines solchen WLAN Segmentes.
Die Maske per se sagt ja erstmal nichts über die Belastung des Netzes an sich aus. Das kannst du nur sehen wenn du im Controller die Anzahl der aktiven Clients siehst.
Ein /23 oder /22 Netz ist ja OK solange sich dort nur 50 User homogen verteilt auf 5 APs tummeln. DHCP Lease Times sollten dann logischerweise auf nicht höher als 1 Stunde dort gesetzt sein!
Member: Xaero1982
Xaero1982 Apr 25, 2024 at 19:37:01 (UTC)
Goto Top
Zitat von @aqui:

Die Nutzer verwenden halt 2-3 Geräte gleichzeitig und daher platzt der DHCP Bereich leider.
Wenn du keine dynamischen VLANs verwenden willst segmentiere das dann nach Stockwerken, Gebäuden etc. Die SSID bleibt gleich wird dann aber lokal in unterschiedliche VLAN IDs je nach Stockwerk, Gebäude etc. gemappt.


Leider alles nicht möglich so richtig. Da kann ich die noch am ehesten alphabetisch in Gruppen stecken face-smile Das wäre vielleicht noch das einfachste.

Dynamische VLANs lösen dein Problem dann nicht wenn die User dann doch wieder dynamisch in ein und dasselbe VLAN kommen.
Du musst deine User dann gruppieren und den Gruppen dann dynamische VLANs zuweisen.
Eine dummes, flaches WLAN mit mehr als 100 gleichzeitigen Usern hat im WLAN noch fatalere Folgen als im Kupfer, weil das gesamte Broad- und Multicast Grundrauschen erheblich zu Lasten der Airtime geht. Ganz besonders wenn die WLAN HW keine Multicast zu Unicast Konvertierung supportet.
Solche Ratschläge wie von der rosa 777 WLAN L2 Domains unendlich groß zu machen sind völliger Unsinn und eher laienhaft. Sie führen zum schnellen Tod eines solchen WLAN Segmentes.
Die Maske per se sagt ja erstmal nichts über die Belastung des Netzes an sich aus. Das kannst du nur sehen wenn du im Controller die Anzahl der aktiven Clients siehst.
Ein /23 oder /22 Netz ist ja OK solange sich dort nur 50 User homogen verteilt auf 5 APs tummeln. DHCP Lease Times sollten dann logischerweise auf nicht höher als 1 Stunde dort gesetzt sein!

Zitat von @Visucius:

Und wo läge da das Problem, ganz konkret?! Ich meine, bevor Du solche Klimmzüge machst um das zu umgehen?! Du hast doch nachher trotzdem nicht mehr Clients?!

@aqui hat alles dazu gesagt face-smile
Member: aqui
aqui Apr 26, 2024 at 08:10:39 (UTC)
Goto Top
Da kann ich die noch am ehesten alphabetisch in Gruppen stecken
Letztlich ist das WIE einer Gruppierung ja egal. Du kannst auch die ersten 50 in VLAN x stecken die zweiten 50 in VLAN y usw.
Es sollte nur die Summe der User einigermaßen homogen in die VLANs verteilt sein. Wenn 80% der am meisten aktiven User in der Gruppe der ersten 50 sind hat man wenig gewonnen. Bei alphabetischer Sortierung sind die User deren Namen mit Q, X, Y, usw. oder die Meier und Schmidt Gruppe besser zu verteilen. Du verstehst vermutlich die Logik... face-wink

Wenn du ganz ohne diese dynamische Lösung arbeiten willst greifst du die Lösung der Stockwerks oder Gebäude Lösung auf indem man der MSSID dann statisch Gebäude oder Stockwerks spezifisch fest andere VLANs zuweist bei gleicher SSID. Das hat den gleichen Effekt so das User je nach Gebäude, Stockwerk etc. zwar die gleiche SSID nutzen aber in unterschiedliche VLANs verteilt werden.
Solltest du Gebäude auch ggf. noch sinnvollerweise routen statt in einem dummen, flachen Netz zu switchen kannst du sogar die gleiche VLAN ID in jeder eigenen Routing Domain verwenden.
Es gibt eben viele Wege nach Rom das sinnvoll zu segmentieren und damit zu lösen. face-wink
Member: NordicMike
NordicMike Apr 26, 2024 at 09:32:50 (UTC)
Goto Top
oder Stockwerks spezifisch fest andere VLANs zuweist
Funktioniert dann noch das Roaming? Wenn der AP wechselt, holen sich alle Clients sofort eine neue DHCP adresse? Oder erst, wenn die DHCP Lease abgelaufen ist?
Member: aqui
aqui Apr 26, 2024 updated at 11:24:07 (UTC)
Goto Top
Funktioniert dann noch das Roaming?
Guter Punkt und aufmerksam nachgedacht..!! ­čśë
Üblicherweise arbeitet man dann immer mit Mobile IP was dann die Client IP Adressen in die anderen VLANs mitnimmt. Es wäre aber wohl vermessen zu glauben das so ein Billigheimer wie UBQT so ein Feature supportet.
.11r und .11k werden die Gurken vermutlich können, so das ein nahtloses Roaming innerhalb der Gruppe von APs die ein Stockwerk oder Gebäude mit einem VLAN bedienen klappt.
Geht der Wechsel aber mit einem BSSID Wechsel einher der einen anderen AP mit anderem VLAN innerhalb der SSID betrifft, dann klappt das natürlich nicht mehr. Es kommt dann zu einer WPA Renegotiation und neuen DHCP Vergabe was beim Roaming ein paar Millisekunden mehr benötigt.
Mit anderen Worten: Bei aktiviertem .11r / .11k Roaming ist es innerhalb der L2 VLAN Domain nahtlos. Bei VLAN übergreifendem Roaming gibt es ein Fallback auf Client Roaming Verhalten.

Da Betreiber solcher WLAN Billighardware aber oft aus Unkenntniss so gut wie nie klassische Roaming Features wie .11r mit .11k und aktivieren, geschweige denn benutzen in ihren WLANs wird das Nutzern niemals auffallen. Es findet ja dann eh nur das übliche, Client basierte Roaming mit all seinen Nachteilen statt. Da kommt es ja bei einem AP Wechsel innerhalb einer L2 Domain auch zu einem Vollabbruch und Renegotiation.
Salopp gesagt ala Hans Scheibner..."das macht doch nix, das merkt doch keiner!"
WLANs dieser Größenordnung erzwingen bei solchen Billigherstellern eine strikte Segmentierung weil die APs meist eine schwachbrüstige und wenig skalierende Hardware verwenden. Gut, ökonomisch evident wenn man primär ein Kundenclientel bedient was rein nur nach diesen Kriterien einkauft. face-wink
Member: ThePinky777
ThePinky777 Apr 26, 2024 updated at 14:32:12 (UTC)
Goto Top
Zitat von @aqui:

Solche Ratschläge wie von der rosa 777 WLAN L2 Domains unendlich groß zu machen sind völliger Unsinn und eher laienhaft. Sie führen zum schnellen Tod eines solchen WLAN Segmentes.
Die Maske per se sagt ja erstmal nichts über die Belastung des Netzes an sich aus. Das kannst du nur sehen wenn du im Controller die Anzahl der aktiven Clients siehst.
Ein /23 oder /22 Netz ist ja OK solange sich dort nur 50 User homogen verteilt auf 5 APs tummeln. DHCP Lease Times sollten dann logischerweise auf nicht höher als 1 Stunde dort gesetzt sein!

hab ich über WLANs geredet?
Mein Text:
client netzwerk /22 definieren als nur /24 oder Server auch gerne mal /23 statt /24

Spätestens beim Wort Server sollte es klar gewesen sein das wir hier über LAN reden.

Aber ist schon ok ist besser die Geräte bleiben einfach offline weils subnet voll ist und keine freien IPs verfügbar, als möglichweise schlecht performant... immer im dienste der User... hast schon vollkommen recht man muss immer die optimale Lösung finden.

aber um die denkweise nochmal zumzudefinieren was die WLANs angeht.

warum nicht einfach folgendes:

einfach verschiedene WLAN SSIDs
und diese werden differenziert auf den Geräten eingerichtet.

Bedeeutet:

SSID_Internes_WLAN1 >> VLAN 11
SSID_Internes_WLAN2 >> VLAN 12
SSID_Internes_WLAN3 >> VLAN 13

jedes VLAN mit eingenem DHCP und eigenem /24 er Netz

Und WLAN per Zertifikat Authentfizierung.

Zertifikat ausrollung per GPO oder Intune per AD Gruppen Zugehörigkeit des PCs

- Bedeutet wird automatisch ausgeroll
- Man pflegt es per AD Gruppen (oderAzure AD Wurst...)

und mit dem NPS und Radius ist es eh wurst.

und zu guter letzt für NON Domain Clients wie z.B. Smart Phones dann halt
ein SSID_Internes_WLAN4 >> VLAN 14
Welches per Login + PW und NPS funktioniert.... what ever....
Da kommen dann halt die Müllgeräte rein

Und Gäste ja sowieso seperat.....

Vielleicht einfacher als NPS Radius rumfummeln zu müssen.
Member: Xaero1982
Xaero1982 Apr 29, 2024 at 19:12:31 (UTC)
Goto Top
Pinky, du gehst halt leider einfach komplett an dem vorbei was ich angesprochen habe.

Ich habs heute mal umgesetzt. So wie ich es schrieb hat alles funktioniert. Nur den DHCP Relay hatte ich vergessen, aber fiel mir dann noch ein und dann wuppte es auch erstmal.

Die Einteilung habe ich nun erstmal so gemacht, dass alle mobilen Geräte im AD in das zweite VLAN 101 gehen und von dort die IP bekommen und alle anderen, die sich mit Smartphones etc. anmelden kommen in das VLAN 100.

Vielleicht kommen irgendwann mal neue Accesspoints und dann wird das alles nochmal umgebaut. Im Moment klappt es erstmal und läuft face-smile

@aqui, Stockwerke etc. kann ich nicht nutzen, weil die immer überall unterwegs sind ... face-smile