07.12.2020, aktualisiert um 16:22:31 Uhr

4248

VLAN Zugang per 802.1x Radius

Hallo,

wir haben in unserem Wohnprojekt 11 Wohnungen, die über einen Cisco SG350 Switch mit einer OpnSense als Gateway verbunden sind. Jede Wohnung ist in ihram eigenen VLAN.

Wohnung 1: VLAN 101 - 10.1.101.x
.
.
.
Wohnung 11: VLAN 111 - 10.1.111.x

Jede Wohnung hat ihren eigenen WLAN-AP/Router auf dem OpenWRT läuft um ein eigenes WLAN aufzuspannen. Manche mit eigenem Subnet, manche benutzen das Subnet der OpnSense die auch als DHCP-Server dient.

Außerdem haben wir APs auf unserem Grundstück verteilt um ein gemeinsames/Gäste WLAN zu haben. Dieses ist in VLAN 10.

Ziel ist es nun, auf allen Routern die das gleiche WLAN (SSID) zu haben und per Radius-Authentifizierung die Clients in das jeweilige VLAN zu schicken, egal wo man sich aufhält. Alle nicht authentifizierten Geräte kommen in VLAN 10. Mit der Einrichtung der Dynamic VLANs beschäftige ich mich aktuell und auch die bereitet mir noch Kopfschmerzen. Meine Frage hier ist allerdings eine andere.

Um die Zuweisung zu einem VLAN von einem Router aus zu ermöglichen, muss dieser Router nach meinem Verständnis an einem Trunk-Port am SG350 hängen. Wenn das so ist könnte aber jeder in seiner Wohnung einem Gerät ein VLAN einer anderen Wohnung zuweise und wäre dann in diesem VLAN.

Gibt es eine Möglichkeit Pakete vom Switch nur passieren durch ein VLAN zu lassen wenn diese von einem für dieses VLAN authentifizierten Gerät kommen?

Viele Grüße

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 629289

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

Ausgedruckt am: 22.11.2024 um 01:11 Uhr

20 Kommentare

Neuester Kommentar

Hi,

warum nicht einfach auf den Trunks nur das VLAN 10 und das jeweilige VLAN (101-111) zulassen? Dann gibts dahingehend keine Probleme. Die 101-111 untagged, VLAN10 zusätzlich als tagged drauf, fertig. So ist man nur in seinem eigenen VLAN, und sollte jemand am VLAN101 sich die 102 am PC geben gibts halt einfach keine Konnektivität.

VG

Edit: und nicht richtig fertig gelesen...wenn alle Clients sich per Radius authentifizieren müssen und ihr dynamic VLAN bekommen kommen die ja auch nirgends anders hin. Ob sie nun das VLAN101 dynamisch bekommen und sich die 102 einstellen sollte die Firewall schon unterbinden. Dann kommt ja im Endeffekt auf einem getaggten Link (101) ein Paket mit einem weiteren Tag (102) und sollte damit verworfen werden

Hier stehen alle Grundlagen dazu:
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
Cisco SG 350x Grundkonfiguration
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch

muss dieser Router nach meinem Verständnis an einem Trunk-Port am SG350 hängen

Nein, das ist falsch bzw. nicht zwingend ! Siehe Tutorial oben. Das kann ebenso ein simpler UNtagged Endgeräte Port sein.

Danke für deinen Beitrag, ich bin mir jetzt nur nicht sicher ob ich dich nicht richtig verstehe oder du mich nicht richtig verstanden hast.

Erstmal kann ja jeder Port nur ein untagged VLAN zugewiesen bekommen. Alle Pakete die keinen Tag haben gehen durch dieses VLAN. Wenn ich möchte, dass über diesen Port auch ein Zugang zu anderen VLANs möglich ist, muss auf diesem Port das entsprechende VLAN als tagged eingetragen sein.

Beispiel:

Alle Router für das Gäste-WLAN hängen an Port 13 am Switch mit VLAN 10 untagged. Alle Geräte im Gäste-WLAN sind nicht authentifiziert und kommen ins VLAN 10.

Gleichzeitig betreiben alle Router ein WPA2-EAP-WLAN über das Clienten sich authentifizieren können und je nach User in ein entsprechendes VLAN kommen. Damit das möglich ist muss Port 13 die jeweiligen VLANs als tagged eingetragen haben da die Pakete sonst verworfen werden.

Edit: aqui schrieb gleichzeitig. Danke für den Beitrag, werde ich mir anschauen.

Nein, das ist falsch bzw. nicht zwingend ! Siehe Tutorial oben. Das kann ebenso ein simpler UNtagged Endgeräte Port sein.

Beziehst du dich hierbei auf das MAC-based VLAN-assignment? Wenn das so ist, ist das keine Lösung für mich. Einerseits ist das auch eine Sicherheitslücke durch MAC-Spoofing, andererseits ist der Verwaltungsaufwand zu groß alle Geräte nachzuhalten.

Erstmal kann ja jeder Port nur ein untagged VLAN zugewiesen bekommen.

Nein, das ist falsch bzw. stimmt bei rein statischer Zuweisung aber nicht für dynamische.
Wenn dein Switch Mac Bypass supportet (was die meisten tun) machst du ja eine Klassifizierung am Port indem du die Mac Adressen aller User erfasst und der Switch dann pro erkannter Mac und vom Radius Server zugewiesenem VLAN diesen immer in sein dynamisch zugewiesenes VLAN forwardet. Die meisten Switches supporten das mit max. 128 Mac Adressen pro Port. Billigere Switches oft nur mit 32 Macs was ja auch tolerabel ist wenn man damit leben kann. Das entspricht genau dem was der gemeine Netzwerker unter dem Stichwort Mac based VLANs versteht.

Alle Pakete die keinen Tag haben gehen durch dieses VLAN

Nein, nicht ganz. Bei Mac Bypass rein nur Pakete die aufgrund ihrer Mac an diesem Port authentisiert wurden.

muss auf diesem Port das entsprechende VLAN als tagged eingetragen sein.

Nein das wäre ja Blödsinn, denn bei dynamischen VLANs pro Port darf der Port doch niemals einem statischen VLAN fest zugewiesen sein. Das macht kein Hersteller der Welt denn Statik hebelt immer die Dynamik aus.

Die VLAN Information des Users kommt ja vom Radius und eben nicht vom Switch. Da hast du wohl was missverstanden.

Dein Beispiel hinkt auch schon deshalb in seiner Authentisierungs Logik.
Alle Clients die NICHT vom Radius authentisiert sind verpasst der Radius automatisch die dynamische VLAN Info 10 so das der Switch diese ins VLAN 10 packt wo sie dann an einem Captive Portal usw. enden.
Siehe Tutorial HIER. Das Beispiel dort (und die weiterführenden Links) entspricht genau deiner Anforderung.

Das hier steht in dem Tutorial und beschreibt genau mein Problem:

Wichtig:
Alle Uplink Ports auf einen oder mehrere Switches und/oder Access Points müssen immer Tagged gesetzt sein. Klar, denn der AP tagged ja jeden WLAN User gemäß seiner Zugehörigkeit mit einem VLAN Tag und das muss der empfangende Switch Port ja entsprechend lesen können ! (Siehe Bild 1 oben !)

Wie gesagt kommt für mich eine MAC-based-authentication nicht in Frage. Dafür bräuchte ich auch keinen Radius-Server, dass kann der SG350 nativ.

Wenn das so ist, ist das keine Lösung für mich.

Gut, wenn du das ausschliesst geht das bei rein Dot1x so nicht, das ist richtig. Damit sind keine "User based" VLANs möglich.
Allerdings lügst du dir auch bischen in die eigene Tasche denn ein simples .1x Username/Passwort ist ja nun noch 10mal einfacher zu manipulieren und vor allem den Kumpels weiterzugeben als eine Mac Adresse zu frisieren. Letzteres erfordert schon etwas mehr KnowHow. Pflege erfordern die Nutzernamen auch wenn mal jemand auszieht usw. Wenn du wirklich sicher sein willst musst du auf Zertifikate umstellen was aber mit einer CA dann erheblich mehr Aufwand ist. Die Mac Lösung ist da einfacher und flexibler...aber nundenn. Du bist ja der Admin und entscheidest.

Da musst du dann in der Tat am WLAN Accesspoint oder Port klassifizieren und der User bekommt dann einen VLAN Tag an seinem Traffic mit. Alle Accesspoint Ports am Switch müssen dann statisch in alle Nutzer/Wohnungs VLANs konfiguriert werden.
Da muss die Authentisierung dann immer im Access passieren.
Dennoch kannst du aber auch unauthorisierte User immer über den Radius mit einem Gast VLAN Tag versehen. Jedenfalls das ist unabhängig von Mac Bypass.

Zitat von @SamiAAA:

Nein, das ist falsch bzw. nicht zwingend ! Siehe Tutorial oben. Das kann ebenso ein simpler UNtagged Endgeräte Port sein.

Für sowas kann man ja auch ein NAC (zb. Packetfence) einsetzen, welches die MAC auch mit Username/Passwort und/oder Zertifikat kombiniert.
Alle neuen Geräte landen dann automatisch in einem Isolationsnetz

welches die MAC auch mit Username/Passwort

Viele Swotches erlauben es auch dem Radius Request dann ein individuelles Passwort mitzugeben anstatt im Default das Passwort gleich der Mac zu setzen. Damit würde man es auch wasserdicht hinbekommen.
Es gibt eben viele Wege nach Rom...

Wie gesagt ist das größte Problem bei MAC-based-authentication das Nachhalten aller Gerätedaten. Genau das will ich ja mit einem User/Passwort Login vermeiden. Tatsächlich soll die Authentifizierung später per bereits vorhandenem LDAP Server passieren. Aber wie im Eingangs-Beitrag ja geschrieben war meine Frage vor allem wie man verhindern kann, dass Jemand einfach seinen Paketen einen VLAN-Tag verpasst und damit in andere VLANs kommt. Und in dem Tutorial ist ja genauso beschrieben, dass alle Ports an denen APs hängen tagged (also Trunk-Ports) sein müssen.

Zitat von @SamiAAA:

Wie gesagt ist das größte Problem bei MAC-based-authentication das Nachhalten aller Gerätedaten.

Wie gesagt... zb ein NAC.... dort landen automatisch alle Geräte

Genau das will ich ja mit einem User/Passwort Login vermeiden. Tatsächlich soll die Authentifizierung später per bereits vorhandenem LDAP Server passieren.

Auch mit dem NAC möglich

Aber wie im Eingangs-Beitrag ja geschrieben war meine Frage vor allem wie man verhindern kann, dass Jemand einfach seinen Paketen einen VLAN-Tag verpasst und damit in andere VLANs kommt.

Eben mit dynamischen VLAN.

Genau das will ich ja mit einem User/Passwort Login vermeiden.

Na ja diese Klardaten geben die Bewohner dann einfach an Freunde und Besuch weiter und nach einer Woche weiss es die gesamte Nachbarschaft. Nach einem Monat dann die ganze Stadt. Bringt ja auch nicht wirklich viel...

Ob das nun aus einer LDAP Datenbank kommt oder im Klartext irgendwo steht macht es auch nicht sicherer.

dass Jemand einfach seinen Paketen einen VLAN-Tag verpasst und damit in andere VLANs kommt.

Das ist sehr einfach lösbar und geht in so einer Dot1x Konfiguration wie bei dir dann nur indem du die WLAN Daten vom AP zentral über einen Tunnel an den Controller sendest.
Der Controller fieselt dann die User je nach Authentisierung raus und forwardet sie dann lokal in ihr VLAN zum Switch.
Würdest du dich dann heimlich an so einen AP Port am Switch anstöpseln landest du isoliert im Controller Tunnelnetz und kannst da nichts machen. Der Tunnel ist AES verschlüsselt. Idealerweise blockiert man zusätzlich dort statisch am Port alle fremden Macs und lässt nur die Mac des APs am Port durch.
Preiswerte Mikrotik WLAN Accesspoints supporten sowas problemlos mit ihrer zentralen CapsMan AP Management Lösung. Cisco, Ruckus und die anderen üblichen Verdächtigen auch. Dort kannst du über die Konfig immer frei wählen ob Tunnel oder local Forwarding.

Das WPA2-EAP-Netz werden nur IT-Affine Bewohner nutzen die gleichzeitig auch sehr sicherheitsbewusst sind. Allen anderen wird es reichen in allen Gemeinschaftlichen Bereichen per Gäste-WLAN Internet zu haben. Den Bedarf von jedem Ort in seinem Privaten Netzwerk zu sein haben nur die ITler..

Das ist sehr einfach lösbar und geht in so einer Dot1x Konfiguration wie bei dir dann nur indem du die WLAN Daten vom AP zentral über einen Tunnel an den Controller sendest.

Werde ich mir mal genauer anschauen.

nur IT-Affine Bewohner nutzen die gleichzeitig auch sehr sicherheitsbewusst sind.

So so...aber das sagen sie später alle.

Einen Mikrotik zum AP/Router zum Spielen und Testen gibts schon für 20 Euronen...

https://www.varia-store.com/de/produkt/97209-mikrotik-routerboard-rb941- ...
Ein Bild sagt mehr als 1000 (Foren)Worte...

So so...aber das sagen sie später alle.

Das kann mir ja egal sein. Am Ende kommen die mit dem Passwort nur ins Netzwerk desjenigen der nicht auf seine Credentials aufgepasst hat. Das ist dann ja sein Problem und das hat jeder der Freunden seinen Zugang zum WLAN gibt. Das Ziel ist es ja mit diesem Setup dafür zu sorgen, dass niemand mehr sein WLAN Passwort weiter geben muss, weil jeder Gast einfach das Gäste-WLAN nutzen kann, egal ob er in einer der Wohnungen ist oder im gemeinschaftlichen Bereich.

Das ist dann ja sein Problem

Oha...das siehst du aber juristisch falsch. Das ist dann ein Problem desjenigen der den Provider Anschluss betreibt. Der haftet grundsätzlich für alle Straftaten.
Das Gute ist aber das du mit der .1x Authentisierung immer den Verursacher identifizieren kannst um so den Inhaber zu entlasten. Man tut also gut daran das so zu betreiben.

Mir geht es dabei garnicht um die Störerhaftung und illegale Downloads. Erstmal geht es nur um den Schutz der Privaten Netzwerke. So oder so ist die Hürde Nutzername, Passwort und Certifikat weiter zu gebn auf jeden Fall deutlich größer als nur einen WLAN key. Zumal die meisten warscheinlich nicht mal wüssten woher sie das Zertifikat bekommen oder wie sie es installieren sollen.