Wer?
User-Labels beschreiben beispielsweise AAA-Gruppen, einzelne Wi‑Fi-Clients, APs oder WLANs.
1. Lernziele
- WxLAN als AP-nahe, benutzerzentrierte Zugriffskontrolle einordnen,
- User- und Resource-Labels fachgerecht modellieren,
- Template- und Site-Policies korrekt priorisieren,
- First-Match- und Allow-/Deny-Semantik sicher anwenden,
- RADIUS-Attribute in User-Gruppen übersetzen,
- VLAN-Overrides samt Vorrang und Datenpfad planen,
- Bonjour Discovery und tatsächlichen Datenzugriff unterscheiden,
- Policytreffer mit Client-, RADIUS- und Paketdaten nachweisen.
Leitfrage: Welcher Benutzer trifft aufgrund welcher nachgewiesenen Labels auf welche erste Regel – und wie wird jede betroffene Ressource dort behandelt?
2. Was ist WxLAN?
WxLAN verbindet Benutzer- beziehungsweise Clientgruppen mit Netzwerkressourcen und weist diesen Beziehungen eine Zugriffswirkung zu. Typische Ziele sind Segmentierung, rollenbasierter Zugriff, Mikrosegmentierung und Least Privilege.
Wohin?
Resource-Labels beschreiben Anwendungen, Hostnames, IP-Netze, Ports oder für Sonderfälle VLANs.
Was gilt?
Die passende Policy-Regel erlaubt oder blockiert die ausgewählten Ressourcen beziehungsweise weist ein VLAN zu.
User-Label + erste passende Regel + Resource-Label + Aktion = effektive WxLAN-Wirkung
WxLAN ersetzt nicht automatisch RADIUS, VLANs, Routing oder die zentrale Firewall. Es ergänzt diese Ebenen um eine Policyentscheidung nahe am WLAN-Client.
3. Das Policy-Modell
Identität / Kontext→User-Labels→erste passende Regel→Resource-Labels→Allow / Block
| Baustein | Bedeutung | Beispiel |
|---|---|---|
| User | Quellgruppe, für die eine Regel gilt | AAA-Rolle „Employee“ |
| Policy Rule | logische Zuordnung zwischen Usern und Ressourcen | Employees dürfen ERP erreichen |
| Resource | Ziel oder Dienst | 10.40.20.0/24 TCP 443 |
| Action | Allow oder Block für Ressource(n) | Allow ERP, Block übrige internen Netze |
| Scope | Template oder Site | globaler Standard plus lokaler Sonderfall |
Policy ist eine Aussage: „Wer darf wohin?“ muss vor der Portal-Konfiguration fachlich formuliert werden. Labels sind anschließend die technische Übersetzung dieser Aussage.
4. Labels: Benutzer und Ressourcen
| Seite | Labeltyp | Typische Verwendung |
|---|---|---|
| User | AAA Attribute | RADIUS-Gruppe oder -Rolle |
| User | Access Point | Clients an bestimmten APs beziehungsweise Bereichen |
| User | Wi‑Fi Client | konkrete MAC-Adressen; nur für kleine Sonderfälle |
| User | WLAN | alle Clients eines bestimmten WLANs |
| Resource | Application | vordefinierte Anwendung oder Kategorie |
| Resource | Hostname | DNS-basierte Zielgruppe |
| Resource | IP Address | Host, Subnetz oder adressbasierte Gruppe |
| Resource | Port | IP/Port/Protokoll-bezogener Dienst |
| Resource/Sonderaktion | VLAN | Client-VLAN per Policy überschreiben |
Benennung
Ein Labelname beschreibt Zweck und Inhalt, nicht die aktuelle Regel: USR-AAA-FINANCE, RES-ERP-HTTPS oder NET-INTERNAL-RFC1918 sind nachvollziehbarer als „Allow1“.
- eine fachliche Gruppe pro Label
- Owner und Datenquelle dokumentiert
- keine überlappenden Bedeutungen ohne Begründung
- MAC-Listen nicht als skalierbares Identitätsmodell verwenden
- veraltete Ressourcen regelmäßig entfernen
5. Organization-/Template- und Site-Scope
| Ebene | Labels | Policy | Typischer Zweck |
|---|---|---|---|
| Organization | Organization > Wireless > Labels | im WLAN Template | einheitliche Regeln für mehrere Sites |
| Site | Site > Wireless > Labels | Site > Wireless > Policy | echte lokale Ressourcen oder Sonderfälle |
Organization-Labels werden in Template-Policies verwendet, Site-Labels in Site-Policies. Entscheidend ist jedoch die Auswertungspriorität: Template-Policies werden für zugeordnete WLANs zuerst geprüft. Eine Site-Regel kommt nur zum Zuge, wenn zuvor keine passende Template-Regel gegriffen hat.
Client verbindet→Template-Policy prüfen→ kein Match →Site-Policy prüfen→Default
Keine additive Annahme: Eine Site-Policy ergänzt eine bereits passende Template-Regel nicht automatisch. Der Template-Match hat Vorrang.
6. Regelverarbeitung Schritt für Schritt
Für den Benutzer werden zunächst die Regeln der zutreffenden WLAN-Template-Policy betrachtet.
Regeln werden in der sichtbaren Reihenfolge von oben nach unten gelesen.
Innerhalb einer Regel müssen alle dort angegebenen User-Labels für den Client erfüllt sein.
Die erste passende User-Regel bestimmt die zu prüfenden Ressourcen. Spätere User-Regeln werden nicht zur Ergänzung herangezogen.
Allow-/Block-Einträge der passenden Regel bestimmen den Zugriff.
Nur ohne passenden Template-Match wird die Site-Policy entsprechend geprüft.
Am Ende der Site-Policy behandelt eine Default-Zeile übrige Benutzer und Ressourcen.
Mehrere User-Labels in einer Regel
Label A UND Label B UND Label C müssen für den User wahr sein
Eine Regel mit „Employee“ und „WLAN-Corp“ trifft nur, wenn der Client beide Bedingungen erfüllt. Soll ein logisches ODER entstehen, werden getrennte Regeln geplant – unter Beachtung der Reihenfolge.
7. Allow-, Deny- und Mischlogik
| Regelinhalt | Genannte Ressourcen | Übrige Ressourcen |
|---|---|---|
| nur Allow | erlaubt | gesperrt |
| nur Block/Deny | gesperrt | erlaubt |
| Allow und Deny gemischt | wie ausdrücklich angegeben | nicht automatisch „deny all“; Rest explizit behandeln |
Beispiel
| User | Aktion | Ressource | Ergebnis |
|---|---|---|---|
| Guest | Allow | Internet | nur Internet erlaubt, übrige Ressourcen gesperrt |
| Employee | Block | Streaming | Streaming gesperrt, übrige Ressourcen erlaubt |
| Contractor | Allow | Ticket-System | Ticket-System erlaubt |
| Contractor | Block | 0.0.0.0/0 | übriger IPv4-Verkehr ausdrücklich gesperrt; Ausnahmen müssen spezifisch sein |
Überlappende Ressourcen werden nach aktueller Juniper-Beschreibung nach Spezifität angewendet. Ressourcen werden in der Anzeige alphabetisch dargestellt; die sichtbare Reihenfolge ist daher kein Ersatz für eindeutige, nicht überlappende Definitionen.
Expliziter Rest: Gemischte Regeln sind besonders fehleranfällig. Der gesamte relevante Adressraum – einschließlich IPv6 – muss in positiven und negativen Tests abgedeckt werden.
8. Anwendungen, Hostnames, IPs und Ports
| Ressource | Stärke | Grenze |
|---|---|---|
| Application | verständliche anwendungsbezogene Policy | Klassifikation kann verschlüsselten, neuen oder atypischen Verkehr anders erkennen |
| Hostname | cloudfreundlicher als statische IP-Liste | DNS, CDN, Wildcards, Caching und verschlüsselte DNS-Verfahren beachten |
| IP Address/Subnet | deterministisch für bekannte Netze | Cloud-/CDN-Adressen ändern sich; gemeinsame IPs können mehrere Dienste tragen |
| IP/Port/Protocol | präzise Dienstdefinition | dynamische Ports und Protokollwechsel berücksichtigen |
Spezifität
Bei überlappenden Zielen ist eine Definition aus IP, Port und Protokoll besonders eindeutig. Beispiel: 10.20.30.15/32 TCP 443 ist genauer als das gesamte 10.20.30.0/24.
Anwendungserkennung
Application Labels werden mit realen Clients, Protokollvarianten, QUIC/HTTP3 und Ausweichpfaden geprüft. Eine fachliche Anwendung kann mehrere Domains, IPs und Transportprotokolle verwenden.
9. AAA-Attribute und RADIUS-Rollen
Ein AAA-Attribute-Label übersetzt ein vom RADIUS-Server geliefertes Attribut in eine WxLAN-Benutzergruppe. Die aktuelle Juniper-Dokumentation nennt für User-Labels in einem Access-Accept:
Filter-Idaruba-user-roleAirespace-ACL-Name
EAP/PSK/MAB→RADIUS Access-Accept→AAA Attribute→User Label→WxLAN Rule
| Prüfung | Beweis |
|---|---|
| Attribut gesendet? | RADIUS-Serverlog oder Packet Capture |
| Wert exakt? | Groß-/Kleinschreibung, Leerzeichen und erwarteter String |
| Client übernimmt Rolle? | Mist Client Details/Policyanzeige |
| Policy trifft? | effektive Regel und Zugriffstests |
| Roaming/Reauth? | Rolle bleibt über Sessionwechsel konsistent |
RADIUS-Erfolg genügt nicht: Ein Access-Accept beweist nur die AAA-Entscheidung. Attribut, Labelauflösung, Regelmatch und tatsächlicher Datenverkehr werden separat nachgewiesen.
10. Client-VLAN per WxLAN überschreiben
WxLAN kann passenden Clients ein VLAN über ein VLAN-Resource-Label zuweisen. Ein häufiger Einsatz ist standortabhängige VLAN-Zuordnung für mPSK-Rollen.
mPSK-/AAA-Rolle→User Label→WxLAN-Regel→VLAN Label→Client-VLAN
Vorrang
Das durch WxLAN zugewiesene VLAN überschreibt andere Client-VLAN-Zuweisungen, beispielsweise ein dynamisches VLAN aus RADIUS oder ein VLAN am mPSK.
| Voraussetzung | Grund |
|---|---|
| AP-Firmware mindestens 0.14.29091 | von Juniper dokumentierte Mindestversion für diese Funktion |
| VLAN im WLAN, an Eth0 oder im Mist Tunnel vorhanden | Policy erzeugt keinen fehlenden Datenpfad |
| VLAN-Label auf korrekter Ebene | muss in der verwendeten Policy verfügbar sein |
| Site Variable bei Org-Label korrekt aufgelöst | ermöglicht standortabhängige VLAN-IDs |
| DHCP, Gateway und Policy vorhanden | VLAN-Zuweisung allein liefert keinen IP-Dienst |
Starke Wirkung: Weil der WxLAN-VLAN-Override andere Zuweisungen überstimmt, muss die effektive Quelle in Design, Betrieb und Troubleshooting ausdrücklich dokumentiert sein.
11. WxLAN und Bonjour Gateway
Bonjour/mDNS entdeckt Dienste über Multicast. Ein Bonjour Gateway kann Serviceinformationen zwischen VLANs vermitteln. WxLAN-Labels können anschließend begrenzen, welche Benutzergruppen welche veröffentlichten Ressourcen erreichen dürfen.
mDNS Discovery→Bonjour Gateway→Service sichtbar→WxLAN Policy→Datenzugriff erlaubt/blockiert
Discovery und Nutzdaten sind getrennte Pfade. Ein Drucker kann in der Geräteliste sichtbar sein, während TCP 9100/IPP blockiert ist; umgekehrt kann die IP erreichbar sein, obwohl mDNS-Discovery fehlt.
| Prüfung | Beispiel |
|---|---|
| Service Discovery | mDNS Query/Response und Gateway-Weitergabe |
| Policy Match | User- und Ressourcenlabel treffen |
| Datenkanal | IPP, AirPlay oder Cast-Zielports erreichbar |
| Rückweg | Server/Client-Antworten erreichen korrektes VLAN |
12. IPv4, IPv6 und Layer-2-Grenzen
Eine Policy, die nur 0.0.0.0/0 behandelt, sagt nichts über IPv6. Dual-Stack-Clients können sonst über einen ungeprüften Pfad kommunizieren. IPv4- und IPv6-Ziele werden deshalb jeweils ausdrücklich modelliert und getestet.
| Ebene | Beispiel | Ergänzende Kontrolle |
|---|---|---|
| IPv4 | RFC1918, öffentliche Ziele, NAT | WxLAN plus Firewall/Egress |
| IPv6 | ULA, Global Unicast, Link Local | IPv6-Prefixe, RA/ND und Firewall |
| Layer 2 | ARP, Broadcast, Client-zu-Client | Peer-to-Peer-/Subnet-Isolation und Switchdesign |
| Multicast | mDNS, SSDP, Streaming | Filter, Bonjour Gateway und Multicastdesign |
Policygrenze kennen: WxLAN ist nicht die einzige Schutzschicht. Layer-2-Isolation, Stateful Firewall, Routing, Endpoint-Schutz und Serverberechtigungen bleiben erforderlich.
13. Entwurfsbeispiele
Gast: Internet, aber keine internen Netze
| User | Aktion | Ressource |
|---|---|---|
| WLAN-GUEST | Block | NET-INTERNAL-V4 |
| WLAN-GUEST | Block | NET-INTERNAL-V6 |
Bei einer reinen Block-Regel bleibt der übrige Verkehr erlaubt. Zusätzlich werden Firewall, NAT und Client-Isolation geprüft.
IoT: nur DNS, NTP und Broker
| User | Aktion | Ressource |
|---|---|---|
| AAA-IOT-SENSOR | Allow | DNS-SERVER |
| AAA-IOT-SENSOR | Allow | NTP-SERVER |
| AAA-IOT-SENSOR | Allow | MQTT-BROKER-TLS |
Eine reine Allow-Liste sperrt die übrigen Ressourcen. DHCP und notwendige Infrastrukturpfade werden im konkreten Produktverhalten und Datenpfad gesondert validiert.
Standortabhängiges mPSK-VLAN
| User Label | Org-VLAN-Label | Site A | Site B |
|---|---|---|---|
| AAA-ROLE-SCANNER | VLAN-SCANNER = Variable | VLAN 120 | VLAN 220 |
14. Policy-Designmethodik
Ressourcen, Daten, Anwendungen und Verwaltungszugänge erfassen.
Rollen nach fachlicher Aufgabe, nicht nach Einzelpersonen bilden.
Quelle, Ziel, Protokoll, Port, Richtung und Begründung dokumentieren.
Matrix in eindeutige User- und Resource-Labels übersetzen.
globalen Standard und echte lokale Ausnahmen trennen.
spezifische User-Regeln vor allgemeinen Regeln platzieren.
Allow-only, Deny-only oder gemischte Semantik ausdrücklich festlegen.
jede erlaubte und jede verbotene Beziehung positiv und negativ prüfen.
Least Privilege = nur fachlich notwendige Beziehungen + expliziter Nachweis + regelmäßige Rezertifizierung
15. Änderungen und Risikobetrachtung
| Änderung | Möglicher Radius | Kontrolle |
|---|---|---|
| Organization-Label | mehrere Templates und Sites | Referenzen und betroffene Policies vorab erfassen |
| Template-Regel | alle zugewiesenen WLANs/Sites | Pilot-Scope und erste Match-Regeln prüfen |
| Reihenfolge | andere Regel gewinnt | Policy-Simulation mit Rollenmatrix |
| RADIUS-Attribut | User verliert/gewinnt Label | AAA- und WxLAN-Change gemeinsam planen |
| VLAN-Override | IP-Wechsel und Sessionabbruch | VLAN, DHCP, Gateway und Reauth testen |
| Ressourcenprefix | zu breite Freigabe oder Sperre | Diff, Positiv-/Negativtests und Firewallvergleich |
- Istzustand und effektive Treffer sichern.
- betroffene Rollen, WLANs, Sites und Ressourcen bestimmen.
- erwartete Regel und Restsemantik formulieren.
- Pilot mit repräsentativen Clients durchführen.
- RADIUS, Client Events und Datenpfad validieren.
- Rollback und Rezertifizierung dokumentieren.
16. Policy-Nachweis und Abnahme
Eine Policy gilt erst als abgenommen, wenn Match und Datenwirkung nachgewiesen sind. „Konfiguration gespeichert“ ist kein Funktionsbeweis.
| Nachweis | Fragestellung |
|---|---|
| RADIUS-Log/Capture | welche Identität und Attribute wurden geliefert? |
| Mist Client Details | welche Rolle, VLAN- und Policyinformation ist effektiv? |
| DHCP/Gateway | hat ein VLAN-Override die erwartete IP-Domäne erzeugt? |
| Packet Capture | wird der erlaubte beziehungsweise blockierte Flow sichtbar? |
| Server-/Firewalllog | erreicht der Flow das Ziel oder wird er später blockiert? |
| Negative Tests | sind ausdrücklich verbotene Ziele über IPv4 und IPv6 gesperrt? |
Testfallformat
Rolle + WLAN + Site + Quell-IP + Ziel + Protokoll/Port + erwartete Regel + erwartetes Ergebnis
Beispiel: Finance | Corp | Berlin | 10.10.20.44 | ERP 10.40.2.10:443/TCP | Rule 20 | Allow.
17. Systematische Fehlersuche
MAC, Benutzer, WLAN, AP, Site, IP-Version und Zeitpunkt erfassen.
Access-Accept, Attribute und exakten Wert im RADIUS-Log prüfen.
Welche Organization-/Site-Labels werden tatsächlich erfüllt?
Greift bereits eine Template-Regel, bevor die Site-Policy erreicht wird?
Welche oberste Regel erfüllt alle User-Labels?
Welches Label trifft auf Ziel, Port, Protokoll und IP-Version?
Ist die Regel Allow-only, Deny-only oder gemischt?
VLAN, Routing, Firewall, DNS und Zielsystem getrennt prüfen.
| Symptom | Wahrscheinliche Ursache | Erster Beweis |
|---|---|---|
| Site-Regel scheint ignoriert | Template-Regel matcht zuerst | Template-Priorität und User-Labels |
| User hat zu viel Zugriff | Deny-only erlaubt den Rest | Regeltyp und Ressourcenliste |
| User hat zu wenig Zugriff | Allow-only sperrt den Rest | fehlende Abhängigkeit im Resource-Set |
| falsches VLAN | WxLAN-Override überstimmt RADIUS/mPSK | Policytreffer und VLAN-Label |
| IPv4 gesperrt, IPv6 geht | IPv6 nicht modelliert | Clientadressen und IPv6-Capture |
| Bonjour sichtbar, Dienst geht nicht | Discovery erlaubt, Datenport blockiert | mDNS plus eigentlicher TCP/UDP-Flow |
Policy und Netzwerk trennen: Ein Block kann aus WxLAN, Firewall, Routing, DNS oder Zielsystem stammen. Der erste fehlende beziehungsweise verworfene Frame entscheidet den nächsten Prüfschritt.
18. Design- und Abnahmecheckliste
Vor Aktivierung
- Rollen- und Ressourcenmatrix freigegeben
- Label-Scope und Owner dokumentiert
- Template-/Site-Priorität geprüft
- Regelreihenfolge begründet
- Allow-/Deny-Restwirkung dokumentiert
- IPv4, IPv6 und Layer 2 berücksichtigt
- VLANs Ende-zu-Ende vorhanden
Abnahme
- AAA-Attribute nachgewiesen
- erste passende Regel bestätigt
- erlaubte Flows erfolgreich
- verbotene Flows nachweislich blockiert
- VLAN-Override und DHCP geprüft
- Roaming/Reauth und CoA getestet
- Rollback und Monitoring vorhanden
Häufige Fehlannahmen
| Behauptung | Bewertung | Fachliche Einordnung |
|---|---|---|
| „Template- und Site-Regeln werden addiert.“ | Falsch | Eine passende Template-Regel hat Vorrang; Site wird nur ohne Template-Match geprüft. |
| „Alle passenden User-Regeln werden kombiniert.“ | Falsch | Die erste Regel, deren User-Labels vollständig passen, entscheidet. |
| „Allow ERP erlaubt ERP und lässt den Rest offen.“ | Falsch | Bei einer reinen Allow-Regel wird der Rest gesperrt. |
| „Block Streaming sperrt danach alles.“ | Falsch | Bei einer reinen Deny-Regel bleibt der Rest erlaubt. |
| „RADIUS-VLAN gewinnt immer.“ | Falsch | Ein WxLAN-VLAN-Override überstimmt andere Client-VLAN-Zuweisungen. |
| „0.0.0.0/0 umfasst IPv6.“ | Falsch | IPv6 benötigt eigene Ressourcen und Tests. |
Merksätze
- WxLAN verbindet User-Labels mit Resource-Labels und einer Zugriffswirkung.
- Template-Policy wird vor Site-Policy geprüft.
- Top-down und First Match bestimmen die wirksame User-Regel.
- Mehrere User-Labels innerhalb einer Regel wirken als UND.
- Allow-only sperrt den Rest; Deny-only erlaubt den Rest.
- Gemischte Regeln benötigen eine ausdrückliche Restbehandlung.
- WxLAN-VLAN kann RADIUS- und mPSK-VLAN überstimmen.
- IPv4-Policy ist keine IPv6-Policy.
- Discovery und Datenzugriff sind getrennt nachzuweisen.
- Gespeicherte Konfiguration ist noch kein Funktionsbeweis.
Offizielle Grundlagen
- WxLAN Access Policies
- Using Labels in a WxLAN Policy
- Create a WxLAN Policy to Override Client VLANs
- WLANs and WLAN Templates
- MAC Address Authentication by RADIUS Lookup
- RADIUS Configuration
- Configure a Bonjour Gateway
- Wireless Clients and Client Details
- Wireless Troubleshooting
Stand der fachlichen Prüfung: August 2026. Policyoptionen, Labeltypen, Firmwareanforderungen und Benutzeroberfläche können sich ändern; für produktive Konfiguration gelten die aktuelle Juniper-Dokumentation, die wirksame AP-Firmware und die konkrete Mist-Region.