NAC Troubleshooting: 802.1X, MAB, RADIUS und VLAN Assignment

NAC Troubleshooting (Network Access Control) ist in Enterprise-Netzen eine der anspruchsvollsten Betriebsaufgaben, weil hier mehrere Disziplinen gleichzeitig zusammenkommen: Layer-2/Layer-3-Konnektivität am Switchport, 802.1X/EAP zwischen Supplicant und Authenticator, RADIUS zwischen Switch und AAA-Server, Zertifikats- und Identitätslogik im Backend sowie dynamische VLAN Assignment und Zugriffspolicies. Genau deshalb wirken NAC-Störungen häufig „unlogisch“: Ein Laptop authentifiziert morgens, mittags landet er plötzlich im Quarantäne-VLAN; ein Drucker bekommt mal Zugriff per MAB, mal gar nichts; ein IP-Telefon funktioniert nur, wenn der PC abgezogen ist; oder ein gesamter Standort verliert nach einem RADIUS-Update schlagartig die Netzfreigabe. Professionelles NAC Troubleshooting bedeutet, den Authentifizierungsfluss sauber zu zerlegen und mit Beweisen zu arbeiten: Kommt der Client überhaupt bis zum EAPOL-Start? Sieht der Switch die richtigen Frames? Wird RADIUS erreicht? Welche EAP-Methode wird verhandelt? Welche RADIUS-Attribute werden zurückgegeben? Und wie interpretiert der Switch diese Attribute in Bezug auf VLAN Assignment, dACLs und Session-State? Dieser Artikel erklärt die häufigsten Fehlerbilder bei 802.1X, MAB, RADIUS und dynamischer VLAN-Zuweisung und zeigt eine praxistaugliche Methodik, mit der Sie Störungen in Minuten eingrenzen – ohne Ratespiel und ohne „NAC erstmal aus“ als reflexartige Dauerlösung.

NAC-Bausteine verstehen: Wer spricht mit wem?

Bevor Sie debuggen, brauchen Sie ein klares Modell. In klassischen NAC-Designs gibt es vier Rollen:

• Supplicant: Endgerät (Windows/macOS/Linux, IP-Phone, IoT), das sich authentifiziert.
• Authenticator: Switchport oder WLAN-Controller, der EAPOL annimmt und als RADIUS-Client fungiert.
• AAA/RADIUS-Server: Policy Engine (oft NAC-Plattform oder RADIUS-Dienst), entscheidet „Allow/Deny“ und liefert Attribute (VLAN, dACL, Session-Timer).
• Identity Store: AD/LDAP, PKI/CA, MDM/Endpoint-Compliance, Geräte-Datenbanken (für Zertifikate, Gruppen, MAC-Listen).

Der „kleine“ Unterschied zum klassischen VLAN-Access ist: Der Switchport ist nicht nur ein L2-Port, sondern ein Policy-Enforcement-Punkt, der je Session dynamisch konfiguriert wird.

Der 802.1X-Ablauf in 60 Sekunden: EAPOL, EAP und RADIUS

802.1X auf Ethernet nutzt EAPOL (EAP over LAN) zwischen Supplicant und Switch. Der Switch kapselt EAP in RADIUS und spricht damit den AAA-Server an. Ein robuster Einstieg in die Terminologie ist RFC 3748 (EAP) sowie RFC 2865 (RADIUS) für die RADIUS-Grundlagen.

• Trigger: Link Up oder EAPOL-Start vom Client.
• Identity Phase: Client sendet Identität (z. B. User, Hostname, Zertifikat-Subject).
• Authentication Phase: EAP-Methode (z. B. EAP-TLS, PEAP/MSCHAPv2) wird ausgeführt.
• Authorization: RADIUS Access-Accept/Reject + Attribute (VLAN, dACL, Session-Timer) entscheidet den Zugang.

Für Zertifikatsbasierung (EAP-TLS) ist fast immer nicht die Kryptografie das Problem, sondern die Kette aus Trust, Zertifikat-Gültigkeit und Policy-Mapping.

MAB: Wenn 802.1X nicht möglich ist

MAB (MAC Authentication Bypass) ist typischerweise ein Fallback für Geräte ohne 802.1X-Supplicant: Drucker, Kameras, IoT, teils auch IP-Phones. Der Switch nutzt dann die MAC-Adresse als Identität und fragt per RADIUS an. Das ist operativ praktisch, aber sicherheitlich schwächer – und fehleranfällig, wenn MAC-Listen, OUI-Heuristiken oder Profiling nicht sauber gepflegt sind.

• Typisches Fehlerbild: Gerät landet in Guest/Quarantine-VLAN, weil MAC nicht bekannt ist.
• Typisches Fehlerbild: Gerät wird fälschlich als „anderer Typ“ profiliert und bekommt falsches VLAN/dACL.
• Wichtig: MAB ist nur so gut wie Ihre Datenbasis (MAC-Registrierung, Profiling, Gerätelebenszyklus).

Die 6 häufigsten NAC-Fehlerklassen

Die meisten NAC-Incidents lassen sich sehr schnell einer Fehlerklasse zuordnen. Das spart Zeit, weil Sie gezielt die richtige Ebene debuggen.

• Layer-1/2 Problem: Link flaps, Duplex/Speed, fehlerhafte Verkabelung, Port-Errdisable.
• 802.1X/EAPOL Problem: EAPOL wird nicht gesendet/empfangen, falsche Port-Rolle, Voice-VLAN/Host-Mode kollidiert.
• RADIUS Erreichbarkeit: AAA-Server nicht erreichbar, Shared Secret falsch, UDP/1812/1813 gefiltert, Source-IP unerwartet.
• EAP Methode/Zertifikate: EAP-TLS Trust-Chain, abgelaufene Zertifikate, falsche EKU, Uhrzeit/Time Sync.
• Authorization/Policy Mapping: Regel matcht anders als erwartet, Gruppen/Claims fehlen, Profiling falsch.
• VLAN Assignment/Session State: RADIUS-Attribute werden falsch interpretiert, VLAN existiert nicht, Trunk erlaubt VLAN nicht, Reauth/CoA führt zu Flip-Flops.

Troubleshooting-Workflow: Vom Switchport nach oben

Ein praxistauglicher Workflow startet immer dort, wo der Fehler „sichtbar“ wird: am Switchport. Danach arbeiten Sie sich durch EAPOL, RADIUS und Policy.

Schritt 1: Port- und Link-Status verifizieren

• Link stabil? Link Flaps oder physische Errors erzeugen Auth-Loops.
• Port Mode korrekt? Access vs. Trunk, Voice-VLAN, Host-Mode (single/multi).
• VLAN verfügbar? Das Ziel-VLAN muss existieren und – falls Uplink/Trunk – erlaubt sein.

Wenn ein VLAN „zugewiesen“ wird, aber nicht auf dem Uplink getaggt ist, wirkt es wie ein NAC-Problem, ist aber ein VLAN/Trunk-Problem.

Schritt 2: EAPOL sichtbar machen

• Sieht der Switch EAPOL? Wenn nicht, ist das Problem meist am Client (Supplicant disabled) oder am Port (falsche Config).
• Sieht der Client EAPOL-Requests? Wenn nicht, kann der Port im falschen State sein oder EAPOL wird gefiltert.
• Timing: Späte EAPOL-Starts führen zu „kurz DHCP, dann weg“ Effekten.

Schritt 3: RADIUS-Exchange prüfen

• Erreicht der Switch den AAA-Server? Routing/ACL/Firewall prüfen, insbesondere UDP 1812/1813.
• Shared Secret korrekt? Falsches Secret erzeugt „silent rejects“ oder Drops.
• Source-IP stimmt? AAA-Server erwarten oft eine bestimmte NAS-IP; bei VRFs oder mgmt-source kann das abweichen.

RADIUS ist klassisch in RFC 2865 und Accounting in RFC 2866 beschrieben; im Betrieb ist vor allem wichtig, dass NAS-IP, Secret und UDP-Erreichbarkeit stimmen.

Schritt 4: EAP-Methode und Zertifikate (wenn relevant)

• EAP-TLS: Zertifikat gültig, passende EKU, richtige CA-Chain, keine CRL/OCSP-Blackholes.
• PEAP/MSCHAPv2: Benutzerpasswort, Domain-Join, Credential Guard/Policy, und Serverzertifikat-Trust.
• Uhrzeit: Zertifikate sind zeitkritisch; NTP/Time Drift kann „plötzlich überall“ Fehler erzeugen.

Schritt 5: Authorization und VLAN Assignment beweisen

• Welche Policy matcht? Nicht die erwartete, sondern die mit höchster Priorität, die die Attribute liefert.
• Welche Attribute kommen zurück? VLAN-ID/Name, Filter-ID (dACL), Session-Timeout, Reauth-Intervall.
• Was macht der Switch daraus? Setzt er wirklich VLAN X? Oder bleibt er im Auth-Fail VLAN?

VLAN Assignment: Die häufigsten Fehler und wie man sie schnell findet

Dynamische VLAN Assignment ist einer der größten Produktivitätsgewinne von NAC – und gleichzeitig eine Top-Fehlerquelle. Besonders häufig sind „technisch richtige“ RADIUS-Antworten, die im L2-Design nicht funktionieren.

• VLAN existiert nicht lokal: Der Switch kann das VLAN nicht aktivieren; Ergebnis: Port bleibt im Fallback/Guest VLAN.
• VLAN nicht auf Trunks erlaubt: Client bekommt VLAN X, aber Uplink/Peer-Link transportiert es nicht; Ergebnis: DHCP/DNS nicht erreichbar.
• Native VLAN/Tagging-Falle: VLAN-Mismatch erzeugt scheinbar zufällige Connectivity.
• Voice/PC Mischbetrieb: IP-Phone im Voice-VLAN, PC dahinter mit 802.1X – falscher Host-Mode führt zu Blockaden.
• Reauth/CoA Flips: VLAN springt zwischen Quarantine und Prod, weil Posture/Profiling pendelt oder CoA falsch getriggert wird.

802.1X + MAB in der Praxis: Reihenfolge, Fallback und „False Positives“

Viele Designs kombinieren 802.1X und MAB: Erst 802.1X versuchen, dann MAB als Fallback. Das ist sinnvoll, aber erzeugt typische Nebenwirkungen, wenn die Reihenfolge oder Timers nicht passen.

• 802.1X Timeout zu kurz: Client braucht länger (Boot, Agent), Switch fällt zu schnell auf MAB → falsches VLAN.
• MAB erlaubt zu breit: Unbekannte Geräte bekommen zu viel Zugriff (Security-Risiko) oder kollidieren mit Profiling.
• Mehrere MACs am Port: IP-Phone + PC, Docking-Station, VM-Host – Host-Mode muss das unterstützen.
• Printer/IoT Randomness: Geräte schlafen, wachen auf, ändern MAC (Privacy), oder senden spät – MAB wirkt „intermittierend“.

RADIUS Troubleshooting: Wenn AAA „läuft“, aber trotzdem nichts geht

RADIUS-Probleme sind oft nicht „Server down“, sondern subtile Mismatches: falsche NAS-IP, falsches Shared Secret, falsche VRF, oder Paketverlust/Fragmentierung auf dem Weg. RADIUS läuft über UDP; Drops wirken daher „stumm“.

• Erreichbarkeit: UDP 1812/1813 muss in beide Richtungen funktionieren; NAT kann Ports umschreiben.
• MTU/Fragmentierung: Große RADIUS-Antworten (viele Attribute) können fragmentieren; manche Firewalls droppen Fragmente. Das wirkt wie „Policy kommt nicht an“.
• Accounting-Backpressure: Wenn Accounting hängt, reagieren manche Systeme mit Verzögerungen oder Session-Problemen.
• Redundanz: Mehrere RADIUS-Server? Prüfen, ob Failover korrekt arbeitet und ob beide identische Policies haben.

CoA und Reauth: Warum Sessions „plötzlich“ umspringen

Viele NAC-Plattformen nutzen Change of Authorization (CoA), um während einer Session Rechte zu ändern: z. B. von Quarantine auf Prod nach erfolgreicher Posture-Prüfung. Das ist leistungsfähig, erzeugt aber Fehlerbilder, wenn CoA-Signale verloren gehen oder wenn Posture-Zustände pendeln.

• Symptom: VLAN wechselt nach Minuten, Sessions reißen, DHCP erneuert sich, Nutzer sieht „kurz offline“.
• Ursache: Posture nicht stabil, EDR-Heartbeat fehlt, oder CoA wird vom Switch nicht akzeptiert (ACL/Key/Source).
• Nachweis: CoA-Events im NAC-Log plus gleichzeitige Port-State-Änderungen am Switch.

Typische Spezialfälle im Betrieb

IP-Telefon + PC am gleichen Port

• Problem: Telefon nutzt LLDP/CDP + Voice-VLAN, PC nutzt 802.1X. Falscher Host-Mode oder falsche Reihenfolge führt zu Block.
• Nachweis: Telefon bekommt Voice-VLAN, PC fällt in Guest; oder umgekehrt PC ok, Telefon nicht.
• Fix-Richtung: Voice-Domäne klar definieren, Multi-Auth/Host-Mode korrekt, MAB-Policy für Phones sauber.

Drucker/IoT mit wechselndem Verhalten

• Problem: Sleep/Wake, seltene EAPOL/MAB-Triggers, DHCP-Zeitfenster, Profiling instabil.
• Nachweis: Logs zeigen wechselnde Profilklasse, wechselnde VLAN-Zuweisung.
• Fix-Richtung: Stabile Identität (z. B. Zertifikat oder feste MAC-Registrierung), klare Profiling-Regeln, passende Timers.

„Nur an einem Switch“ klappt es nicht

• Problem: Config Drift, fehlendes VLAN, anderer RADIUS-Server-Eintrag, anderer VRF-Source, oder unterschiedliche Software-Version.
• Nachweis: Vergleich der Port- und AAA-Config, sowie der VLAN/Trunk-Listen.
• Fix-Richtung: Baselines und automatisierte Config-Checks, bevor Änderungen ausgerollt werden.

Beweisführung mit Captures: Wann es sich lohnt

In vielen NAC-Fällen reichen Switch- und RADIUS-Logs. Captures sind jedoch sehr effektiv, wenn Sie EAPOL-Handshake-Fehler, EAP-Methodenverhandlungen oder RADIUS-Fragmentierungsprobleme beweisen müssen. Besonders hilfreich ist ein Capture am Switchport (Mirror/SPAN) oder direkt am AAA-Server (wenn möglich).

• Was Sie im Capture suchen: EAPOL-Start, EAP-Identity, EAP-TLS Handshake, RADIUS Access-Request/Accept/Reject, Attribute-Listen.
• Warum Captures helfen: Sie zeigen, ob der Fehler „vor dem Server“ (Client/Switch) oder „im Server“ (Policy/Identity Store) entsteht.
• Tools: Wireshark Dokumentation und tcpdump Manpage.

Runbook-Baustein: NAC Troubleshooting in 15 Minuten

• Minute 0–3: Symptomklasse bestimmen: Auth Fail, VLAN falsch, intermittierend, nur Gerätetyp X, nur Switch Y. Zeitfenster festlegen.
• Minute 3–6: Switchport prüfen: Link stabil, Port-Mode/Host-Mode korrekt, VLAN existiert und ist auf Uplinks erlaubt, keine Errors/Discards.
• Minute 6–9: 802.1X/MAB Flow prüfen: EAPOL sichtbar? Fallback zu MAB? RADIUS Requests gehen raus und kommen Antworten zurück?
• Minute 9–12: Policy/Identity/Posture prüfen: Welche Regel matcht? Welche Attribute werden geliefert (VLAN/dACL/Timers)? Stimmen Gruppen/Profiling/MAB-Einträge?
• Minute 12–15: VLAN Assignment verifizieren: Switch hat VLAN tatsächlich gesetzt, DHCP/DNS erreichbar, Trunks korrekt. Bei Bedarf gezielter PCAP oder CoA/Timeout-Analyse. Danach Fix mit minimalem Scope umsetzen und sofort testen.

Weiterführende Quellen

• RFC 3748 für EAP-Grundlagen (EAP-Methoden, Message Flow)
• RFC 2865 und RFC 2866 für RADIUS Authentication und Accounting
• IEEE 802.1X als Referenz für Port-Based Network Access Control auf Layer 2
• Wireshark Dokumentation und tcpdump Manpage für EAPOL/RADIUS Captures und Beweisführung

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.