802.1X und dynamische VLANs im WLAN mit Ubiquiti Unifi

Hier kommt nun endlich mein Folge-Artikel zu dem doch recht erfolgreichen Beitrag über dynamische VLANs in Verbindung mit 802.1X mit Ubiquiti Unifi-Hardware: Einrichtung von 802.1X und Dynamic VLANs mit Ubiquiti USG Pro. Dieser Artikel beschreibt die Einrichtung und Nutzung von Unifi Access Points in Verbindung mit 802.1X und dynamischen VLANs basierend auf der MAC-Adresse.

Eine kurze Übersicht

Grundsätzlich gehe ich in diesem Artikel wieder davon aus, dass das Thema VLANs bekannt ist und ein grundlegendes Verständnis über diese tolle Technik vorhanden ist 🙂

Ziel der Aufgabe soll es sein, dass wie eine WLAN-SSID ausstrahlen und uns mit unseren Geräten dort anmelden können. Je nach Gerät bzw. Adresse soll dann dynamisch das korrekte Netzwerk für das Gerät ausgewählt und zugewiesen werden. In meinem Netzwerk gibt es mehrere VLANs, die für unterschiedliche Zwecke genutzt werden:

  • Private Geräte
  • Das Büro/Firmen-Netzwerk
  • Das “Internet of shitty things” Netzwerk für all die hochsicheren Geräte wie Fernseher, Sonos usw…

Die Anzahl der Netze könnte auch noch deutlich höher sein, belassen wir es in diesem Fall bei diesen drei Netzwerken.

Trennung per VLAN

Jedes dieser Netze wird mittels VLAN voneinander getrennt und isoliert. Früher liefen die Netze alle auf einem Ubiquiti USG Router auf, das Gerät ist mittlerweile einer Fortigate 60F gewichen. Die Fortigate-Router können nahezu alles was man sich vorstellen kann, und da ich die Geräte mittlerweile auch bei einigen Kunden im Einsatz habe, habe ich mir ein Gerät ebenfalls für mein Netzwerk zugelegt. Grundsätzlich sind die Netzwerke untereinander nicht verbunden, dies wäre aber bei Bedarf auch möglich (z.B. Notebook im Privat-Netz muss auf einem Drucker im Firmennetz drucken, …).

Internet oder nicht?

Ich habe den Zugriff nach außen zusätzlich noch gefiltert, so dass nur die Geräte eine Verbindung aufbauen dürfen, denen ich das auch erlaube. Dazu existieren pro Netz/VLAN Gruppen in der Firewall, die bei Bedarf erweitert oder entfernt werden können. Somit kann genau gesteuert bzw. überwacht werden, wer wohin kommunizieren darf und wer nicht.

Der genutzte RADIUS-Server

Da ich in meinem Fall ja eine Fortigate als primären Router nutze, entfällt bei mir die Möglichkeit, den USG-internen RADIUS-Server zu nutzen. Wer dies nicht möchte, kann natürlich gerne weiterhin den integrierten Dienst aktivieren und nutzen. Die Konfiguration ist identisch wie in meinem vorherigen Beitrag: https://www.zueschen.eu/einrichtung-von-802-1x-und-dynamic-vlans-mit-ubiquiti-usg-pro/ => Der interne RADIUS-Server

Installation von Freeradius

Zur Authentifizierung meiner Clients nutze ich ein virtuelles Debian-System in der gerade aktuellen Version 10.6.0. Die Installation geschieht nach Standard-Einstellungen, ich installiere keinen Desktop, dafür aber einen SSH-Server zum Zugriff per Netzwerk. Nach der Grundinstallation kann der Freeradius-Server installiert werden.

Die Konfigurationsdateien liegen nach der Installation unter

Interessant sind für uns die folgenden beiden Dateien:

clients.conf

In dieser Datei werden die Geräte eingetragen, die eine Verbindung zu unserem RADIUS-Server aufbauen dürfen. Hier können entweder einzelne IP-Adressen eingetragen werden oder alternativ ein IP-Bereich bzw. Subnetz. Da ich ein eigenes Management-Netzwerk für meine Geräte habe, habe ich hier das komplette Subnetz eingetragen:

Nach diesen Anpassungen kann die Datei gespeichert und geschlossen werden.

users

Diese zweite Datei enthält die MAC-Adressen der Geräte, die wir zuweisen möchten. Um den Server generell zu testen, kann ganz oben in der Datei der folgende Eintrag gemacht werden:

Nun können wir die Datei speichern und müssen den RADIUS-Service einmal stoppen.

Nachdem der Dienst aus ist, können wir ihn interaktiv wieder starten. Dies hat den Vorteil, dass wir direkt sehen, ob der Dienst korrekt arbeitet oder nicht. Dies geschieht durch den Aufruf der Applikation mit dem Schalter “-X”.

Manueller Test

Um den Server zu testen, kann in einer zweiten SSH-Sitzung der folgende Befehl abgesetzt werden:

Wie es nicht aussehen sollte

Wenn der Eintrag nicht korrekt ist bzw. nicht gesetzt wurde, sieht die Ausgabe wie folgt aus:

Man erkennt sehr gut, dass das Kennwort nicht gefunden wurde und das der Zugriff mit “Access-Reject” verweigert wurde.

Wenn alles klappt

Ist der Eintrag erfolgreich gesetzt worden, muss die Ausgabe wie folgt aussehen:

RADIUS-Server im Unifi Controller eintragen

Ist der Server nun betriebsbereit, können wir im Unifi Controller in den Einstellungen unter Profiles => RADIUS unseren Server eintragen.

Wir benötigen einen Namen, die IP-Adresse von unserer freeradius-VM und das Kennwort, welches in der client.conf von uns konfiguriert wurde. Nun können wir die Einstellungen speichern, mehr müssen wir hier nicht einstellen.

Falls ein USG als RADIUS-Server genutzt wird

Kommt ein USG zum Einsatz, muss dies unter Services => RADIUS => Server aktiviert werden.

Die Benutzer (bzw. MAC-Adressen), die wir später im freeradius-Server konfigurieren, müssen in eurem Fall dann hier unter User konfiguriert werden. Was genau eingestellt werden muss, steht im ersten Artikel 🙂

Geräte eintragen und zuweisen

Welches Gerät in welches Netzwerk fällt, müssen wir nun auf dem freeradius-Server in der Datei users konfigurieren. In meinem Fall sieht die Datei wie folgt aus:

Zum testen habe ich mal die MAC-Adressen von meinem Thinkpad eingetragen. Einmal WLAN, einmal LAN.

  • Der Tunnel-Type muss immer auf 13 stehen, dies sind die gleichen Einstellungen wie im USG.
  • Tunnel-Medium-Type muss auf 6 stehen, dies ist ebenfalls die gleichen Einstellung wie im USG bzw. dem Unifi-Controller.
  • Das gewünschte VLAN, in das der Client zugewiesen werden soll, muss in der freeradius-Konfiguration als Tunnel-Private-Group-ID konfiguriert werden.

Die entsprechenden Einstellungen im Controller mit USG sehen wie folgt aus:

Der letzte Block in der Config-Datei, beginnend mit DEFAULT, führt eine Standard-Konfiguration durch. Dies passiert immer dann, wenn keine der darüber liegenden Regeln greift. Ich führe in meinem Fall eine Zuweisung in ein Fallback-VLAN durch, ohne die Fallback-Konfiguration seitens Ubiquiti zu nutzen. Diese hat den Nachteil, dass sie erst nach 60 Sekunden greift und in dieser Zeit mancher Client schon auf die 169.254-APIPA Adresse geschaltet hat, weil er davon ausgeht, dass kein DHCP zur Verfügung steht. Dies ist hier nicht der Fall, in meiner Fallback-Option mittels RADIUS geht es deutlich schneller (ein paar Sekunden laut freeradius-Logfile).

Man könnte hier theoretisch auf kein VLAN zuweisen, dann würde das Gerät in das Default-LAN fallen, was kein VLAN zugewiesen hat. Das möchte ich aber nicht, ich möchte das Gerät in ein definiertes Fallback-VLAN einsperren.

Vorsicht mit Windows 10 und WLAN und dynamischen MAC-Adressen

Microsoft hat, genau wie Apple in seinem letzten iOS-Update, in Windows 10 eine Funktion eingebaut, die dynamisch MAC-Adressen bei WLAN-Verbindungen nutzt. Ist diese Funktion aktiv, generiert der Client bei jedem WLAN-Netzwerk eine neue MAC-Adresse und nutzt diese für die Verbindung. Dies ist natürlich bei einer Filterung auf MAC-Basis nicht wirklich vorteilhaft. Zu finden ist die Option in den Einstellungen unter Wi-Fi

Die Konfiguration eines WLANs

Damit unser Access Point nun dynamische VLANs und die dazugehörigen IP-Adressen verteilt, müssen/können die Einstellungen wie folgt aussehen:

Ich habe in meinem Fall ein “normales” WPA2 Personal WLAN erstellt. Heißt, ich muss mich mit einem Pre-Shared-Key anmelden und authentifizieren. Dies könnte theoretisch auch ein WPA Enterprise sein, ganz nach Bedarf und Möglichkeiten. Man könnte hier z.B. eine Anmeldung an die Active Directory koppeln, damit jeder Benutzer sich mit seinen persönlichen Credentials anmelden kann.

In den Advanced Options sieht man, dass unter VLAN die Option RADIUS assigned VLAN fest hinterlegt und ausgegraut ist. Dies ist korrekt so und kann auch nicht geändert werden. Alle weiteren Einstellungen können nach Bedarf angepasst und gesetzt werden. Dies wäre z.B. das zeitgesteuerte Ausschalten vom WLAN und noch vieles mehr.

Ganz unten unter RADIUS MAC AUTHENTICATION muss die Option aktiviert werden, weiterhin müssen wir unser vorab angelegtes freeradius-Profil auswählen. Das Format der MAC-Adresse nutze ich komplett in GROSSEN BUCHSTABEN. Dies könnte bei Bedarf auch angepasst werden, dies ist aber der Standard bei Ubiquiti, daher belasse ich es so und trage meine MAC-Adressen alle wie folgt ein.

Das WLAN können wir nun so speichern und mit unseren Geräten testen. Sollte euer freeradius-Service noch mit dem Parameter -X gestartet sein, könnt ihr bei der Verbindung von einem WLAN-Client sehr gut sehen, welches VLAN / Netzwerk dem Client zugeordnet wird.

Ich habe mein Notebook verbunden, hier wird nun im Log direkt angezeigt, dass die Adresse bekannt ist und dem entsprechenden VLAN zugeordnet wird:

Verbinde ich mein Handy, ist dies aktuell noch unbekannt und wird in das Fallback-VLAN / Netz geschmissen. Trage ich die MAC von meinem Handy nun im freeradius ein und starte den Dienst einmal neu, landet das Gerät danach ebenfalls im gewünschten Netzwerk.

Fazit

Der Artikel ist ein bisschen länger geworden als geplant, aber ich hoffe ich habe alle relevanten Optionen und Einstellungen abgedeckt. Ich habe initial mit einem Windows Server RADIUS begonnen, bin aber relativ schnell auf den freeradius umgeschwenkt. Dies hat mehrere Gründe und Vorteile:

  • freeradius läuft in vielen Linux-Distributionen und ist somit frei verfügbar
  • Der Dienst läuft auch auf NAS-Geräten oder Raspberry Pis ziemlich gut
  • freeradius hat direkt funktioniert und bietet ein gutes Logging, das war bei dem Windows Server nicht direkt der Fall.

Die hier genutzte Konfiguration ist die Basis für den Aufbau von meinem Netzwerk. Ich brauche nur noch eine einzige SSID ausstrahlen und kann im Hintergrund trotzdem alle Geräte auftrennen, isolieren und vom Internet isolieren, wenn gewünscht. Mit einer steigenden Anzahl an Geräten macht sich dies schon gut bemerkbar 🙂

Wenn euch der Artikel gefallen hat oder ihr Fragen habt hinterlasst mir doch einen kleinen Kommentar.


Sie benötigten persönliche Unterstützung oder haben nicht die richtige Lösung für Ihr Problem gefunden?

Dieser Blog wird von mir, Jan Kappen, in seiner Freizeit betrieben, hier beschreibe ich Lösungen für Probleme aller Art oder technische Anleitungen mit Lösungsansätzen.

Die berufliche Unabhängigkeit

Ich bin seit Januar 2020 vollständig selbstständig und habe meine eigene Firma gegründet, die Building Networks mit Sitz in Winterberg im schönen Sauerland. Hier stehe ich als Dienstleister gerne für Anfragen, Support oder Projekte zur Verfügung.

Die Firma Building Networks bietet Ihnen:

  • Hilfe und Support per Telefon, Fernwartung oder persönlich vor Ort
  • Projekt-Unterstützung
  • Ausgezeichnete Kompetenz zu den Themen
    • Microsoft Hyper-V
    • Microsoft Failover Clustering & HA
    • Storage Spaces Direct (S2D) & Azure Stack HCI
    • Veeam Backup & Recovery
    • Microsoft Exchange
    • Microsoft Exchange Hybrid Infrastruktur
    • Microsoft Active Directory
    • Microsoft Office 365
    • Ubiquiti
    • 3CX VoIP PBX
    • Fortinet Network Security
    • Baramundi Software
    • ...

Ich freue mich über Ihren Kontakt, weitere Informationen finden Sie auf der Webseite meiner Firma unter Building-Networks.de

Jan

Jan Kappen arbeitet seit 2005 in der IT. Er hat seine Ausbildung 2008 abgeschlossen und war bis 2018 als IT-Consultant im Bereich Hyper-V, Failover Clustering und Software Defined Storage unterwegs. Seit 2015 wurde er jährlich von Microsoft als Most Valuable Professional (MVP) im Bereich "Cloud & Datacenter Management" ausgezeichnet für seine Kenntnisse und die Weitergabe seines Wissens. Jan ist häufig auf Konferenzen als Sprecher zu finden, weiterhin bloggt er viel. Von September 2018 bis Dezember 2019 war Jan als Senior Network- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland angestellt. Im Januar 2020 hat er den Sprung in die Selbstständigkeit gewagt und ist seitdem Geschäftsführer der Firma Building Networks in Winterberg. In seiner Freizeit kümmert er sich um das Freifunk-Netzwerk in Winterberg und Umgebung.

19 Kommentare:

  1. Pingback:Einrichtung von 802.1X und Dynamic VLANs mit Ubiquiti USG Pro - Jans Blog

  2. Hallo,

    in der aktuellen Controller Version gibt es kein Radius assigned VLAN beim WLAN mehr?
    Und nun?

    • Stimmt, gerade nachgeschaut, die Option ist verschwunden. Allerdings kann weiterhin unten in den erweiterten Einstellungen ein RADIUS-Server aktiviert und konfiguriert werden. Hast du das schon ausprobiert, ob die Option oben quasi “automatisch” aktiviert wird, wenn man unten die RADIUS-Option aktiviert?
      Gruß, Jan

      • Hi, unten die Einstellung betrifft ja nur Mac Authentification.

        Ich würde gerne Dyn Vlans anhand von Radius Usern mit AD nutzen.

        Grüße

        • Das VLAN wird ja im User mit angegeben. Daher die Überlegung, ob dieser Eintrag alleine reicht, um das korrekte VLAN zu übermitteln und zuzuweisen.
          Gruß, Jan

          • Ich stehe gerade an gleicher Stelle – das VLAN aus dem Radius User übersteuert leider nicht das VLAN des im Wifi hinterlegten Netzwerk. Auch ist im aktuellen Controller (6.2.26) bei Nutzung des integrierten Radius dann nur noch ein Zugriff mit vorhandenem Radius User möglich? Mein Ziel wäre nur gezielte Clients in ein spezielles VLAN zu schleusen, während per Default das im Netzwerk hinterlegte VLAN zieht.

            Konntet ihr das schon lösen?

  3. Hi, ich habe aktuell ein Problem sobald ich das Radius Profil aktiviere gibt er nicht mehr das eingestelle Netz über die AP´s an die clients.

    Konfig abriss:
    Dreammaschine Pro mit Ipsec tunnel zum Radius
    Netzwerk für AP´s Switche im VLAN 10
    Client Netz soll VLAN 68 werden.
    Sow wie ich die Radius Authentifizierung Aktiviere bekomme ich eine IP aus VALN 10. Lasse ich dies Aus gibt der AP eine IP aus VLAN 68.

    Eine Idee was ich falsch mache ?

    Danke Gruß
    Matthias aus dem schönen Saarland

    • Hallo Matthias,
      verwendest du auch freeradius oder den integrierten RADIUS server von dem UDMP? Wenn freeradius, schau dir mal das Logfile an, ob du hier erkennen kannst warum das “falsche” Netz zugewiesen wird.
      Gruß, Jan

  4. hi ich verwende einen Clearpass Server^^ (Windows Radius)

  5. Pingback:Freeradius mit MySQL, daloRADIUS und dynamische VLANs mit Ubiquiti Unifi - Jans Blog

  6. Alois Eimannsberger

    Hallo,

    ich verwende de RADIUS Server des USG’s für die Trennung der VLAN’s. Das funktioniert soweit. Nur wenn sich ein Gerät am WLAN anmeldet, dass anhand der MAC Adresse noch keine Zuordnung zu einer VLAN ID hat, kann sich dieses nicht zum WLAN verbinden. Mir fehlt eine Art Fallback VLAN ID beim USG. Gibt es da etwas?

  7. Zwei Dinge, die mir aufgefallen sind:
    Warum kann ich in der client.conf nur ein Gerät bzw. nur ein Netz eintragen?
    Wenn ich ein zweites Gerät im anderen Netz einfügen will, stürzt FreeRADIUS ab.

    Und: Muss der USG Radius aus sein, wenn ich einen neuen Radius im USG definiere?
    Oder kann man die parallel laufen lassen? Weil beide doch 1812 benutzen

    • Hallo Dirl,
      für mehr als einen Bereich brauchst du einen komplett neuen Eintrag in der clients.conf. In der Vorlagen-Datei bei Github sieht man, wie die Bereiche einzutragen sind: https://github.com/redBorder/freeradius/blob/master/raddb/clients.conf
      Der RADIUS auf dem USG kann ruhig an bleiben, er wird halt dann nicht mehr gefragt, sondern der externe freeradius. Da der freeradius eine eigene IP hat, gibt es da keine Komplikationen bezüglich Port. Das wäre nur der Fall, wenn der RADIUS-Dienst 2x auf dem gleichen Gerät laufen würde. Da das USG in diesem Fall als RADIUS-Client agiert, passt das.
      Schönen Gruß, Jan

      • Alles was du oben beschrieben hast, funktioniert bei mir. Alle meine Geräte gehen über das USG Radius ins richtige VLAN.
        Aber für mein Abschlussprojekt muss das mit FreeRADIUS gehen. Tut es aber nicht.
        Auf meiner Synology ein CentOS virtualisierrt, ein eigens Subnetz erstellt, eigener Switch, eigener AccesPoint, alles im extra Netz.
        Aber der Debug Modus sagt:
        Failed binding to auth address * port 1812 bound to server default: Address already in use
        /etc/raddb/sites-enabled/default(59): Error binding to port for 0.0.0.0 port 1812

        Vielen Dank für deine Hilfe
        Gruss Dirk

        • Hallo,
          das hört sich danach an, als wenn der Dienst bereits läuft. Wenn du den Debug-Modus nutzt, muss der automatisch gestartete Dienst vorher immer manuell beendet werden. Unter CentOS weiß ich es nicht, unter Debian wäre es ein “systemctl stop freeradius” bzw. mit “systemctl status freeradius” kannst du prüfen, ob der Dienst bereits läuft.
          Gruß
          Jan

          • Juhu, ich hab es geschafft…. Vielen Dank.
            Da kann die mündliche Prüfung kommen. Alles funktioniert. Tolle Seite auch hier.
            Ich muss nur zusehen, dass das nachher kein Plagiat wird.
            Aber weißte was:
            Bei der WPA Enterprise Authentifizierung muss man ja die MAC eingeben. Benutzer und Password.
            Ist das nicht etwas tau einfach, zu unsicher? Oder denke ich da falsch?
            Wenn Leute das wissen, dass sie nur ihre MAC brauchen, um zu surfen, ja dann kann ja jeder in mein Default Netz oder??
            Und nochwas: Das mit der MAC für VLAN ist OK, aber zur Authenifizierung find ich das unsicher.
            Grade weil man diese MAC generieren kann und fälschen kann.
            Oder was sagst du Jan…

          • Hi,
            eine Authentifizierung per MAC-Adresse ist nur eine von mehreren Möglichkeiten, die du bei der WPA Enterprise-Authentifizierung hast. Wenn es dir um Sicherheit geht, dann wirst du um eine Authentifizierung mit Zertifikaten nicht drum herum kommen. Hierbei ist dann nicht nur die MAC-Adresse ausschlaggebend, sondern auch ein Zertifikat. Hast du kein Zertifikat, kommst du nicht rein.
            Du hast bei deiner Denkweise vollkommen recht, eine MAC-Adresse ist kein ausreichender Schutz. Ist halt immer die Frage, was du damit schützen möchtest und worum es dir geht und wie sensibel die Infrastruktur ist. Diese Anleitung hier habe ich geschrieben, damit mein Netzwerk zuhause nur eine SSID ausstrahlt, aber ich trotzdem diverse Geräte voneinander trennen kann. Insbesondere ging es mir darum, dass so Geräte wie ein Amazon Fire TV oder ein TV-Gerät in einem eigenen Netz rumturnen, und nicht in meinem Privat-Netz sind. Da diese Geräte aber wiederum keine Zertifikate können, habe ich die MAC-Variante genutzt.
            Schönen Gruß
            Jan

  8. Hallo Jan,

    spricht was dagegen den Freeradius auf dem gleichen PI zu betreiben auf dem ich den Controller am laufen habe?

    Liebe Grüße
    Sascha

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.