Categories:

WLAN-Lab so konfigurieren, dass Cisco Access Points auch im default VLAN 1 zum WLAN-Controller finden (Option 43)

Veröffentlicht von empy
Lesezeit: 11 Minuten

Ich habe mein Wireless Home Lab fertiggestellt. Es besteht mittlerweile aus drei Switches. Zu den bereits vorhandenen beiden Switches gesellt sich nun ein Cisco Catalyst 2960S-24PS-L V03. Er kann Gigabit und PoE nach dem 802.3at-Standard, womit ich meine Cisco 2702 Access Points mit 3×4:3 MIMO betreiben kann.

Nachdem mein Lab aufgebaut und einsatzbereit erstkonfiguriert wurde, ist es an der Zeit, die restlichen Access Points anzuschließen und mit dem Controller zu verbinden. Wichtig ist es dabei, auf eine korrekte Konfiguration der Ports zu achten, damit die Access Points sich reibungslos mit dem Controller verbinden können und die ausgestrahlten SSIDs auch genutzt werden können. Jeder Port, an dem ein Access Point angeschlossen werden soll, wird deshalb als Trunk-Port konfiguriert. Anhand meiner Topologie im Test-Lab unterstützt der Trunk-Port die VLANs 8, 44 und 99, wobei VLAN 8 das native VLAN ist und somit ohne 802.1Q-Tags auskommt.

Ist der Port falsch konfiguriert, kann der Access Point nicht vernünftig arbeiten. Im Detail kommt es darauf an, wie und ob der AP bereits konfiguriert wurde. Beispiel FlexConnect: Das native VLAN des APs muss mit dem native VLAN am des Switch-Ports übereinstimmen. Fehlt dem Port das native VLAN 8 (oder hat er ein anderes native VLAN), dann kommt der Access Point nicht zum Controller durch. Und kennt bzw. erlaubt der Port die VLANs nicht, die für die ausgestrahlten SSIDs benötigt werden (bei mir eben VLAN 44 und 99), können Endgeräte sich mit den SSIDs zwar verbinden, bekommen aber keine IP-Adresse, da der Port alle Datenpakete mit unbekanntem VLAN verwirft. Auch beide Szenarien können eintreten, wenn ein bereits konfigurierter Access Point an einen Access Port mit falschen native VLAN angeschlossen wird. Ein noch nicht konfigurierter Access Point würde die SSIDs ohne einmalige Verbindung zum Controller gar nicht erst ausstrahlen.

Nun bilde ich mir ein, dass es von Vorteil wäre, wenn ein Access Point sich mit dem Controller verbinden würde, obwohl die Port-Konfiguration nicht perfekt ist. Der AP soll trotzdem zum Controller durchkommen, auch wenn er an einem nicht konfigurierten Port (bei Cisco ist das in der Regel ein Access-Port mit default native VLAN 1) angeschlossen wird. Ich möchte auch, dass der Access Point am Controller ankommt, wenn der Port zwar Trunk ist, aber das native VLAN noch auf Default-ID 1 steht und noch nicht auf ID 8 konfiguriert wurde. Dann kann ich am Controller erkennen, wenn neue Access Points im Netzwerk hängen und im Fehlerfall deren Portkonfiguration überprüfen und korrigieren. Angesteckte Access Points sollen sich also in jedem Fall mit dem Controller verbinden. Taucht der Access Point am Controller auf, ist es leicht, dessen Port zu identifizieren und zu konfigurieren.

Anzeichen für eine fehlerhafte AP-Port-Konfiguration

Am Beispiel eines Cisco 2702 im Modus FlexConnect mit WPA2-PSK möchte ich darstellen, wie sich eine fehlerhafte Port-Konfiguration am WLAN bemerkbar macht. Mein WLAN-Controller sitzt im native VLAN 8 (untagged). VLAN 1 ist das default native VLAN meiner Cisco Switches. Meine WLAN-SSIDs sind auf VLAN separate VLANs gemappt (44 und 99).

Bereits konfigurierter Access Point (FlexConnect)Access Point noch ganz ohne Konfiguration
Trunk-Port mit native VLAN 8,
allowed VLANs 44, 99
AP joint dem Controller

SSIDs werden ausgestrahlt
Clients erhalten IP-Adresse
AP joint dem Controller
AP erhält die Konfiguration
SSIDs werden ausgestrahlt
Clients erhalten IP-Adresse
Trunk-Port mit native VLAN 1,
allowed VLANs 44, 99
AP joint dem Controller nicht

SSIDs werden ausgestrahlt
Clients erhalten IP-Adresse
AP joint dem Controller nicht
AP erhält keine Konfiguration
SSIDs werden nicht ausgestrahlt
Clients erhalten keine IP-Adresse
Access-Port mit VLAN 8AP joint dem Controller

SSIDs werden ausgestrahlt
Clients erhalten keine IP-Adresse
AP joint dem Controller
AP erhält die Konfiguration
SSIDs werden ausgestrahlt
Clients erhalten keine IP-Adresse
Access-Port mit VLAN 1AP joint dem Controller nicht

SSIDs werden ausgestrahlt
Clients erhalten keine IP-Adresse
AP joint dem Controller nicht
AP erhält keine Konfiguration
SSIDs werden nicht ausgestrahlt
Clients erhalten keine IP-Adresse
Anzeichen für fehlerhafte Port-Konfiguration am Switch. In Rot habe ich diejenigen Fälle markiert, welche ich durch meine neue Konfiguration mit VLAN 1 lösen werde.

Obiges Beispiel zeigt eine sehr einfache Konfiguration mittels WPA2-PSK. Für eine SSID sind natürlich auch komplexere Konfigurationen möglich. Wie sich FlexConnect in allen oberen Zuständen zum Beispiel mit Radius verhält, könnt ihr durch dieses Dokument ableiten. Es kommt dabei auch darauf an, wo genau euer Radius-Server im Netzwerk verortet ist.

Neue Netzwerktopologie mit VLAN 1

Eine zentrale Ursache für das Problem, dass der Access Point dem Controller nicht beitritt, liegt an fehlenden Diensten in VLAN 1. Grundproblem: Mein Mikrotik-Router kennt VLAN 1 überhaupt nicht und verwirft deshalb alle Datenpakete mit VLAN-ID 1. Ich muss also ein VLAN-Interface für VLAN 1 anlegen.

Doch nicht nur der Router kennt VLAN 1 noch nicht. Gemäß meiner Konfiguration der Trunk-Ports auf den Switches sind nur VLANs 8,44 und 99 erlaubt. Das muss ich ändern, damit die Trunk-Ports auch VLAN 1 erlauben. Und zwar für alle Trunk-Ports, die die Switches und den Router miteinander verbinden (Uplinks). Den Trunk zum VMware ESXi brauche ich übrigens nicht anzupassen.

Switche und Router kennen nun VLAN 1. Doch noch etwas sollte ich in meinem Netzwerk verbessern: Die Access Points erhalten an Ports, deren native VLAN auf ID 1 festgelegt wurde, keine IP-Adresse. Zwar könnte ich dies durch die Vergabe statischer IP-Adresse lösen, aber ich hatte ja eingangs erwähnt, dass mir viel daran liegt, automatisch alle Access Points am WLAN-Controller auftauchen zu lassen, um auf diese Weise fehlerhaft konfigurierte Ports zu erkennen. Wenn ich immer erst manuell IP-Adressen festlegen müsste, müsste ich die Erstkonfiguration neuer APs auf anderem Wege organisieren. Und dieses Vorgehen ist im Grunde nicht skalierbar. Deshalb benötige ich einen DHCP-Server im VLAN 1, der den Access Points dynamische IP-Adressen zuweist, obwohl sie eben in VLAN 1 sind.

Mein WLAN-Controller ist im Management-VLAN-8. Cisco WLAN-Access-Points suchen ihren WLAN-Controller immer im lokalen Subnetz mit Hilfe eines Broadcast. Wenn das nicht zum Erfolg führt, nutzen Sie einen komplizierten Mechanismus, um den WLAN-Controller zu identifizieren. Wenn ich Access Points und WLAN-Controller in verschiedenen Subnetzen betreibe (Controller im native VLAN 8, Access Point jedoch im VLAN 1), dann ist es notwendig, den Access Points exakte IP-Adresse des WLAN-Controllers mitzuteilen. Dafür nutze ich eine Erweiterung von DHCP, die sogenannte Option 43. Die Option 43 werde ich am DHCP-Server für VLAN 1 festlegen. Im native VLAN 8 wird die Option übrigens nicht benötigt: Da sich WLAN-Controller und Access Points im gleichen Subnetz befinden, finden sich beide Komponenten zuverlässig ohne weitere Eingriffe.

Mein Cisco Wireless Home Lab hat eine Firewall konfiguriert, welche das Routing zwischen den VLANs verbietet. Damit meine Access Points in VLAN 1 mit dem WLAN-Controller kommunizieren können, werde ich meine Firewall-Regeln so ergänzen müssen, dass VLAN 1 und WLAN-Controller Daten austauschen dürfen. Tue ich das nicht, wissen die Access Points zwar, wo sich der WLAN-Controller befindet, können mit ihm aber nicht kommunizieren und ihm daher nicht beitreten.

Die angepasste Netzwerktopologie mit VLAN 1

Schritt 1: VLAN am Mikrotik-Router anlegen

Los geht es also mit den Anpassungen an meinem Cisco Wireless Home Lab, damit auch Access Points an default-Ports der Cisco Switches mit VLAN 1 dem Controller joinen. Dazu erstelle ich im Mikrotik Router zunächst ein VLAN-1-Interface. Ich nutze den Menüpunkt „Interface“ und wechsle im folgenden Menü auf „VLAN“. Dort lege ich über das Plus-Icon ein neues Interface mit VLAN-ID 1 an. (Die Uplinks haben native VLAN 8, daher kommt VLAN 1 mit 802.1Q-Tags an).

Anschließend füge ich das neu angelegte VLAN einer sogenannten Interface-Liste hinzu. Das geschieht im Reiter „Interface List“. Die Interface-Liste gruppiert unterschiedliche Interfaces, was mir später die Konfiguration der Firewall vereinfacht und Gruppenregeln auf VLAN 1 direkt anwendet. Mein VLAN-1-Interface füge ich derselben LAN-Liste hinzu, die bereits die anderen VLANs mit beinhaltet.

Damit das VLAN vom Mikrotik-Router auch geroutet wird, benötigt das Interface eine IP-Adresse. Durch die Zuweisung dieser IP-Adresse wird das VLAN-1-Interface zu einem sogenannten Layer-3-Interface. Die Erstellung einer IP-Adresse für das Interface erfolgt im Menü „IP -> Addresses“. Dort erstelle ich dann eine neue IP-Adresse für das Interface VLAN 1: Ich lege sie auf die folgende Adresse fest. 192.168.1.1/24.

Schritt 2: VLAN 1 zu den erlaubten VLANs an Uplink-Trunk-Port hinzufügen

Der Router kennt nun VLAN 1 und hat eine entsprechende IP-Adresse erhalten. Was noch fehlt: VLAN 1 muss auf allen Trunk-Port erlaubt werden, die die Switche und den Router miteinander verbinden (Uplinks). Per Konfiguration sind in meinem Cisco WLAN Home Lab an den Uplinks nur VLANs mit ID 8, 44 oder 99 erlaubt. In der aktuellen Konfiguration würden die Uplink-Ports alle Pakete verwerfen, die mit VLAN-ID 1 am Switch ankommen.

Um dies zu ändern, muss ich VLAN 1 der Liste erlaubter VLANs am Trunk-Port hinzufügen. Dann leitet der Switch die Pakete weiter. Daher ändere ich die Konfiguration für alle Uplink-Ports auf allen Switches wie folgt ab. Zuerst wechsle ich in den Privileged EXEC mode, dann in den Konfigurations-Modus, dann zum entsprechenden Port:

ena
conf t
int f0/1
switchport trunk allowed vlan 1,8,44,99
exit
write memory

Ich überschreibe nur die Konfiguration für die erlaubten VLANs am Trunk-Port. Die restlichen Port-Einstellungen, z.B. die Port-Encapsulation (sofern vorhanden) bleiben davon unberührt. Ich wiederhole den Vorgang für alle Uplink-Ports an allen Switchen und speichere die Konfiguration im Anschluss ab.

Alle Uplink-Trunk-Ports zwischen den Switches und Router werden so konfiguriert, dass sie auch VLAN 1 zulassen.

Übrigens: VLAN 1 muss an den Cisco Switches nicht angelegt werden. Es ist immer das default-VLAN und kann nicht gelöscht werden. VLAN 1 existiert daher immer und kann wie eben gezeigt direkt der Liste erlaubter VLANs am Trunk-Port hinzugefügt werden.

Schritt 3: DHCP-Server in VLAN 1 anlegen

VLAN 1 ist nun definiert. Im nächsten Schritt lege ich daher einen DHCP-Server für VLAN 1 an. Das mache ich bequem über den dafür vorgesehenen Assistenten, der bei Mikrotik RouterOS unter „IP -> DHCP Server“ zu erreichen ist. Er wird mit Druck auf den Knopf „DHCP Setup“ gestartet. Der Assistent füllt alle relevanten Informationen selbst aus. Ich habe lediglich die IP-Range angepasst.

Nachdem der DHCP-Server angelegt ist, nun im Reiter „Networks“ das in Schritt 1 angelegte Netzwerk 192.168.1.1/24 auswählen und einen DNS-Server ergänzen. Dazu trage ich in das entsprechende Feld die IP-Adresse 192.168.1.1 ein, denn ich möchte, dass mein Router die Funktion des DNS-Servers direkt mit übernimmt.

Eintrag des DNS-Servers.

Wenn ich jetzt einen Access Point am Switch anschließe, dann erhält er eine IP-Adresse aus dem 192.168.1.0/24 Netz im VLAN 1. Das lässt sich auch am Router im Reiter „Leases“ des DHCP-Servers erkennen.

Schritt 4: Option 43 am DHCP-Server hinterlegen

Es folgt der wahrscheinlich wichtigste Teil, ohne den die Access Points den WLAN-Controller nie erreichen würden: DHCP-Option 43. Immerhin ist in VLAN 1 kein WLAN-Controller auffindbar. Damit der Access Point den Controller in einem anderen Subnetz erkennt, muss er in der Vergangenheit bereits mit dem Controller verbunden gewesen sein. Ansonsten benötigt er etwas Hilfestellung. Und die gebe ich ihm jetzt.

Zum einen besteht die Möglichkeit, den Controller statisch direkt am Access Point zu hinterlegen. Diese Methode ist sehr aufwändig und muss für jeden neuen Access Point durchgeführt werden. Sie ist daher nicht massentauglich. Besser sind die Möglichkeiten, dem Access Point den Controller automatisch mitzuteilen. Dazu stehen zwei Varianten zur Verfügung: Mitteilen der Controller-IP per DNS-Eintrag oder per DHCP. Ich wähle die letztere Variante und weise dem Access Point die IP-Adresse des WLAN-Controllers per DHCP Option 43 zu.

Dazu lege ich in RouterOS von Mikrotik zunächst eine DHCP-Option mit Code „43“ an. Dies geschieht direkt am DHCP-Server im Reiter „Options“. Der Name ist dabei frei wählbar. Unter Code muss der Wert „43“ eingetragen werden. Lediglich beim Value wird es etwas komplizierter, denn die IP-Adresse des WLAN-Controllers muss in einem speziellen Format bereitgestellt werden, damit die Cisco Access Points den Wert korrekt verarbeiten können.

Der Value setzt sich aus vier Bestandteilen zusammen: „0x“, „00f1“, „04“ sowie in meinem Beispiel „c0a8085a“. Für meine WLAN-Controller-IP-Adresse lautet der Wert also „0x00F104c0a8085a“. Ich möchte das etwas genauer erläutern.

DHCP Option 43 braucht hexadezimale Werte. Mit „0x“ sagen wir Mikrotik, dass es sich bei den folgenden Eingaben um hexadezimale Werte handelt. Reine Codierungssache also. Option 43 selbst setzt sich dann aus den Bestandteilen Typ, Länge und Wert zusammen. Beginnen wir mit dem Typ „00f1“, welcher immer gleichbleibt. Es folgt die Länge, d.h. wie viele Bytes mit dem eigentlichen Inhalt folgen. Ich möchte nur eine Controller-IP hinterlegen, deshalb wähle ich bei Länge „04“, da die IP-Adresse aus vier Oktetts bzw. Bytes besteht. Würde ich zwei WLAN-Controller hinterlegen wollen, würde ich bei Länge „08“ angeben. Nun folgt die IP-Adresse des WLAN-Controllers, diese muss in einen hexadezimalen Wert umgerechnet werden. Entweder von Hand oder per Tool. Ich empfehle folgenden Rechner, um die IP-Adresse hexadezimal umzurechnen. Aus meiner WLAN-Controller-IP 192.168.8.90 wird dann „c0a8085a“.

Setze ich nun alle Bestandteile von Option 43 zusammen, ergibt das „0x00F104c0a8085a“. Diesen Wert trage ich bei Value direkt im Mikrotik-Menü ein (siehe Bild) und bestätige mit OK. Dann ist die Option 43 einsatzbereit.

Damit der DHCP-Server die Option 43 nun auch aussendet, muss sie am DHCP-Server noch hinterlegt werden. Mehrere DHCP-Server können so unterschiedlich konfiguriert werden. Daher öffne ich unter „IP -> DHCP Server“ im Reiter „Networks“ das Netzwerk von VLAN 1. Dort habe ich in Schritt 3 bereits der DNS-Server hinterlegt. Nun wähle ich unter „DHCP Options“ die eben erstellte Option 43 aus und bestätige meine Einstellung.

Der Access Point erkennt DHCP-Option 43 und versucht, den Controller zu erreichen.

Kurze Zeit später erkennt der Cisco 2702 Access Point die vorhandene Option 43 und versucht nun, den WLAN-Controller zu erreichen. Leider funktioniert das noch nicht, denn der Verbindungsversuch wird von der Firewall noch blockiert.

Schritt 5: Firewall für VLAN 1 zu WLAN-Controller definieren.

In einem letzten Schritt passe ich deshalb die Firewall an, indem ich zwei weitere Regeln ergänze. Um die VLANs voneinander abzutrennen, hatte ich beim Aufbau meines Cisco Wireless Home Labs entsprechende Regeln eingeführt. Nun muss ich Ausnahmen definieren, wenn aus VLAN 1 zum Controller kommuniziert werden soll. Und umgekehrt.

Daher lege ich eine weitere Firewall-Regel an, deren Datenverkehr ich erlaube, wenn die Quelle aus VLAN 1 kommt (also von einem Access Point) und das Ziel der WLAN-Controller mit der IP 192.168.8.90 ist. Ich lege noch eine weitere Regel an, die den Verkehr vom WLAN-Controller mit der IP 192.168.8.90 ins VLAN 1 erlaubt. Verkehr, welcher nicht in Verbindung mit dem WLAN-Controller steht, wird somit weiterhin unterbunden. Beide Regeln kommen ganz nach oben.

Ausnahme für an der Firewall erlauben: Von VLAN1 zum Controller (feste IP 192.168.8.90) und umgekehrt.

Kurze Zeit, nachdem die Ausnahmen in der Mikrotik-Firewall erlaubt wurden, können Access Points in VLAN 1 mit dem WLAN-Controller in native VLAN 8 miteinander kommunizieren. Kurze Zeit später tritt der Access Point dem WLAN-Controller bei.

Abschluss: Port richtig konfigurieren.

Und genau das wollte ich. Auch Access Points, welche an einem nicht konfigurierten Port angeschlossen werden, finden nun den Weg zum WLAN-Controller. Anhand meiner Topologie im Testnetzwerk sind die unkonfigurierten Ports immer im VLAN 1. Obige Anleitung lässt sich aber auch für unterschiedliche VLANs beliebig oft wiederholen, solltet ihr andere Rahmenbedingungen haben.

Doch mein Ziel habe ich endlich erreicht: Wenn ein Access Point am WLAN-Controller aufschlägt, kann ich den entsprechenden Port auf Korrektheit prüfen und gegebenenfalls anpassen. Dies sollte man für alle Access-Point-Trunk-Ports tun. Die Trunk-Konfiguration für mein WLAN-Testnetzwerk ist ja bereits bekannt:

interface f0/18
(switchport trunk encapsulation dot1q)
switchport mode trunk
switchport trunk allowed vlan 8,44,99
switchport nonegotiate
switchport trunk native vlan 8
exit

Wichtig: Sobald die Konfiguration abgesetzt wurde, ist der Port neu konfiguriert. Dennoch bleibt der Access Point mit seiner IP im Netz von VLAN 1. Daher empfehle ich einen manuellen Neustart des Ports. Dies macht den Port stromlos und startet den Access Point neu. Im Anschluss bootet der Access Point mit korrekter Konfiguration und passender IP-Adresse neu – PoE sei Dank!

Die Befehle sind recht selbsterklärend: „shutdown“ schaltet den Port ab und macht ihn stromlos (PoE). „no shutdown“ schaltet den Port wieder ein und ein angeschlossenes PoE-Gerät bootet wieder.

interface f0/18
shutdown
no shutdown
exit

Ich empfehle, die Konfiguration auf allen Switches und dem Router abzuspeichern!