9
Cisco SRW2024, VLAN, DHCP
Hi,
vorneweg, ich bin leider kein Cisco-Freak, Experte oder was auch immer, sondern mehr Anwender im Sinne von einstecken und wenn's läuft ist's prima
Trotzdem bin ich jetzt auf ein Problem gestoßen, das ich selbst nicht lösen kann. Und zwar hängt an einem Cisco SRW2024 Switch eine Firewall (IPFire) die an einem physikalischen Ethernetport ein sog. blaues Netzwerk, also für WLAN-Clients und zwar ausschließlich, zur Verfügung stellt.
Dieser blaue Port verbindet sich (per Patchkabel) mit dem Switch-Port 21 dem ich die VLAN ID 100 zugewiesen habe. Auf der besagten Firewall wurde keine VLAN ID vergeben.
Am Port 10 des Switch hänge ich dann für einen ersten Test ein Laptop dem ich ebenfalls die VLAN ID 100 zugeteilt habe. In der Annahme, dass durch diese Konstellation dem Laptop eine IP-Adresse des DHCP-Server vergeben wird.
Weit gefehlt!
Laut auf der Firewall erhalte ich zwar DHCP-Anfragen und offensichtlich wird auch eine Rückantwort gegeben, nur die IP-Adresse kommt nicht am Laptop an.
Dies ist die vereinfachte Variante, die ich aktuell zum Testen der IP-Vergabe verwendet habe.
Am Port 10 des Switch soll später eigentlich ein Access Point betrieben werden, ein TP-Link WE1043ND mit OpenWRT als Firmware. Diese Firmware ist VLAN fähig und ich beabsichtige ein Gäste WLAN mittels der VLAN ID 100 aufzuziehen. Aber das ist für später geplant.
Somit ergibt sich momentan die folgende "Verkabelung": Laptop (VLAN 100) -> Cisco Port 10 -> Cisco Port 21 -> Firewall (DHCP-Server). Wie oben bereits geschrieben wird aus dem Range des DHCP-Server zwar eine Adresse gezogen, nur das Laptop erhält diese nicht.
Ein paar Bilder von der eigentlichen Konfiguration am Cisco:
Port 10:
"Keine Einstellung" wie im Bild unten, ist leider nicht ganz richtig, ich habe den Port 10 zum VLAN 100, tagged hinzugefügt, VLAN1 ist wie im Bild zu sehen untagged.
Port 21:
Ich benötige VLAN 1 weiterhin, da in der Endausbaustufe, wenn der Access Point mit dem Cisco verbunden ist, über dieses Kabel auch der normale, private Netzverkehr laufen soll, also kurzum die Admin-Oberfläche auch weiterhin aus dem Nicht-Gäste-WLAN erreicht werden soll.
Habe ich in der Konfiguration des Cisco irgendetwas übersehen?
Vielen Dank für Eure Hilfe!
Michael
vorneweg, ich bin leider kein Cisco-Freak, Experte oder was auch immer, sondern mehr Anwender im Sinne von einstecken und wenn's läuft ist's prima
Trotzdem bin ich jetzt auf ein Problem gestoßen, das ich selbst nicht lösen kann. Und zwar hängt an einem Cisco SRW2024 Switch eine Firewall (IPFire) die an einem physikalischen Ethernetport ein sog. blaues Netzwerk, also für WLAN-Clients und zwar ausschließlich, zur Verfügung stellt.
Dieser blaue Port verbindet sich (per Patchkabel) mit dem Switch-Port 21 dem ich die VLAN ID 100 zugewiesen habe. Auf der besagten Firewall wurde keine VLAN ID vergeben.
Am Port 10 des Switch hänge ich dann für einen ersten Test ein Laptop dem ich ebenfalls die VLAN ID 100 zugeteilt habe. In der Annahme, dass durch diese Konstellation dem Laptop eine IP-Adresse des DHCP-Server vergeben wird.
Weit gefehlt!
Laut
tcpdump -ne -i blue0 -xx not port 2216:35:51.007375 06:0a:34:c2:4b:de > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 100, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 06:0a:34:c2:4b:de, length 300
16:35:51.007968 00:0d:b9:47:66:ea > 06:0a:34:c2:4b:de, ethertype IPv4 (0x0800), length 342: 172.168.0.1.67 > 172.168.0.101.68: BOOTP/DHCP, Reply, length 300Dies ist die vereinfachte Variante, die ich aktuell zum Testen der IP-Vergabe verwendet habe.
Am Port 10 des Switch soll später eigentlich ein Access Point betrieben werden, ein TP-Link WE1043ND mit OpenWRT als Firmware. Diese Firmware ist VLAN fähig und ich beabsichtige ein Gäste WLAN mittels der VLAN ID 100 aufzuziehen. Aber das ist für später geplant.
Somit ergibt sich momentan die folgende "Verkabelung": Laptop (VLAN 100) -> Cisco Port 10 -> Cisco Port 21 -> Firewall (DHCP-Server). Wie oben bereits geschrieben wird aus dem Range des DHCP-Server zwar eine Adresse gezogen, nur das Laptop erhält diese nicht.
Ein paar Bilder von der eigentlichen Konfiguration am Cisco:
Port 10:
Port 21:
Ich benötige VLAN 1 weiterhin, da in der Endausbaustufe, wenn der Access Point mit dem Cisco verbunden ist, über dieses Kabel auch der normale, private Netzverkehr laufen soll, also kurzum die Admin-Oberfläche auch weiterhin aus dem Nicht-Gäste-WLAN erreicht werden soll.
Habe ich in der Konfiguration des Cisco irgendetwas übersehen?
Vielen Dank für Eure Hilfe!
Michael
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 353812
Url: https://administrator.de/contentid/353812
Printed on: April 16, 2024 at 18:04 o'clock
9 Comments
Latest comment
Also wenn ich das richtig deute dann haben die Pakete deiner Firewall an Port 21 kein VLAN-Tag. Damit diese Pakete ins VLAN gelangen müsste am Switch auf Port 21 unter VLAN 100 "UnTagged" aktiviert sein.
Dein Client hingegen tagged seine Pakete selbst, daher ist auf Port 10 "Tagged" unter VLAN 100 die richtige Einstellung.
Sollte so sein, ich bin auch immer wieder aufs neue verwirrt aber habe selbst drei SRW20xx.
Dein Client hingegen tagged seine Pakete selbst, daher ist auf Port 10 "Tagged" unter VLAN 100 die richtige Einstellung.
Sollte so sein, ich bin auch immer wieder aufs neue verwirrt aber habe selbst drei SRW20xx.
Servus und Danke für deine prompte Antwort!
Kann dies aber erst später heute Abend testen.
Nur für mich aber noch zum Verständnis: die Firewall bzw. dessen Ethernetport hat aber selbst keine VLAN ID zugewiesen bekommen, die hängt native sozusagen am besagten Port 21.
Ich dachte in diesem Zusammenhang daran, dass 100 tagged bedeutet, dass alles was an diesem Port reinkommt, also auch von der Firewall, mit der ID 100 versehen wird.
Grüße,
Michael
Kann dies aber erst später heute Abend testen.
Nur für mich aber noch zum Verständnis: die Firewall bzw. dessen Ethernetport hat aber selbst keine VLAN ID zugewiesen bekommen, die hängt native sozusagen am besagten Port 21.
Ich dachte in diesem Zusammenhang daran, dass 100 tagged bedeutet, dass alles was an diesem Port reinkommt, also auch von der Firewall, mit der ID 100 versehen wird.
Grüße,
Michael
Dein Client hingegen tagged seine Pakete selbst, daher ist auf Port 10 "Tagged" unter VLAN 100 die richtige Einstellung.
Das ist natürlich völliger Quatsch. Vergiss diesen Unsinn bitte ganz schnell. Normale Clients also Endgeräte wie PCs, Laptops, Drucker usw. senden generell IMMER alle Pakete untagged !!!Deshalb musst du dem Switch auch an der entsprechenden Portkonfig wo dieser Client angeschlossen ist ja explizit sagen das diese Daten dort zwangsweise ins VLAN 100 sollen !
Deine beiden Ports, also Firewall UND auch Client, MÜSSEN somit zwingend an den Portkonfigs untagged ins VLAN 100 konfiguriert werden !
mit dem Switch-Port 21 dem ich die VLAN ID 100 zugewiesen habe
Hoffentlich dann eben untagged ?! Und wie gesagt: BEIDE Ports.Weit gefehlt!
Zeigt dann das dieser Port NICHT im VLAN 100 liegt und du ihn vermutlich Tagged oder irgendwie anderes falsch konfiguriert hast.Es sollte klar sein das der Laptop Port UND auf der Firewall Port Untagged in VLAN 100 liegen müssen.
Um ganz sicher zu gehen das die FW auch IP Adressen per DHCP vergibt solltest du den PC einmal auch direkt per Kabel mit der FW verbinden un den Switch als Fehler komplett ausschliessen so.
Hast du denn überhaupt irgendeine IP per DHCP bekommen dort ? Oder ist der ausgetimed mit eine 169.254.x.y APIPA IP ?
Letzteres zeigt dann das dort keinereli DHCP Server "gesehen" wird vom Endgerät, sprich es keinerlei Connectivity im VLAN 100 gibt zw. diesen beiden Ports.
auf der Firewall erhalte ich zwar DHCP-Anfragen
Kommen diese Anfragen denn von dem besagten Laptop ??Das kannst du an der Absender Mac Adresse sehen ! Ist 06:0a:34:c2:4b:de der Laptop ??
dass alles was an diesem Port reinkommt, also auch von der Firewall, mit der ID 100 versehen wird.
So ist das auch aber dann können einfache Endgeräte die keine 802.1q getaggte Pakete verstehen diese Ethernet Pakete nicht mehr lesen.Ein kleine VLAN Kurzschulung hilft hoffentlich beim verstehen und richtigen umsetzen:
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
Die beiden Ports solltest du auch NICHT als "General" Port konfigurieren sondern immer als "Access" Ports und dann fest untagged ins VLAN 100.
"Admit Tagged only" ist natürlich auch Blödsinn. Wenn man auch nur mit banalem Schulenglisch das übersetzt besagt es das dieser Port hier nur getaggte Pakete annimmt. Das ist auch der Kardinalsfehler !
Wo sollen diese denn herkommen ?? Du sagst ja selber das weder die Firewall tagged und das das Endgerät nicht tagged weiß auch jeder.
Logisch also das es mit so einer unsinnigen Konfig nicht funktionieren kann, das weiß auch ein Switch Laie.
Fazit: Beide Ports als Access Ports, Join VLAN und untagged in 100 fertig ist der Lack. Logisch nachdenken hilft
Dann klappt das auch sofort !
Das ist natürlich völliger Quatsch. Vergiss diesen Unsinn bitte ganz schnell. Normale Clients also Endgeräte wie PCs, Laptops, Drucker usw. senden generell IMMER alle Pakete untagged !!!
Wieso kann ich dann bei Clients, zum bspw. Windows 10 Laptop eine VLAN ID einstellen?, wenn diese nicht verwendet wird? Das ist mir noch nicht ganz klar. Wie geschrieben, ich habe dem Laptop im Treiber der Netzwerkkarte explizit ID 100 mitgegeben, damit dieser am richtigen Port 21 "rauskommt". Angesteckt war das Laptop jedoch an Port 10. Da ich im Dump auch die Anfrage des Laptops gesehen und zwar ausschließlich die des Laptops und sonst von keinem andren Netzwerk-Client, gehe ich davon aus, dass der Weg vom Laptop zum DHCP-Server funktioniert hat. Im Umkehrschluss habe ich dann nämlich noch die ID wieder entfernt und konnte keinerlei Anfragen beobachten.Deshalb musst du dem Switch auch an der entsprechenden Portkonfig wo dieser Client angeschlossen ist ja explizit sagen das diese Daten dort zwangsweise ins VLAN 100 sollen !
Das wäre bei mir Port 10 und dort liegt 1U und 100T an.Hast du denn überhaupt irgendeine IP per DHCP bekommen dort ? Oder ist der ausgetimed mit eine 169.254.x.y APIPA IP ?
Ja, genauso ist es ich habe eine 169er IP-Adresse erhalten, aber wohl nicht vom DHCP sondern als Fallback..Letzteres zeigt dann das dort keinereli DHCP Server "gesehen" wird vom Endgerät, sprich es keinerlei Connectivity im VLAN 100 gibt zw. diesen beiden Ports.
Kommen diese Anfragen denn von dem besagten Laptop ??
Das kannst du an der Absender Mac Adresse sehen ! Ist 06:0a:34:c2:4b:de der Laptop ??
Ja, die MAC-Adresse ist die des Laptops.Das kannst du an der Absender Mac Adresse sehen ! Ist 06:0a:34:c2:4b:de der Laptop ??
Die beiden Ports solltest du auch NICHT als "General" Port konfigurieren sondern immer als "Access" Ports und dann fest untagged ins VLAN 100.
"Admit Tagged only" ist natürlich auch Blödsinn. Wenn man auch nur mit banalem Schulenglisch das übersetzt besagt es das dieser Port hier nur getaggte Pakete annimmt. Das ist auch der Kardinalsfehler !
Wo sollen diese denn herkommen ?? Du sagst ja selber das weder die Firewall tagged und das das Endgerät nicht tagged weiß auch jeder.
Logisch also das es mit so einer unsinnigen Konfig nicht funktionieren kann, das weiß auch ein Switch Laie.
Fazit: Beide Ports als Access Ports, Join VLAN und untagged in 100 fertig ist der Lack. Logisch nachdenken hilft
Dann klappt das auch sofort !
Das werde ich heute Abend dann gleich Mal umsetzen."Admit Tagged only" ist natürlich auch Blödsinn. Wenn man auch nur mit banalem Schulenglisch das übersetzt besagt es das dieser Port hier nur getaggte Pakete annimmt. Das ist auch der Kardinalsfehler !
Wo sollen diese denn herkommen ?? Du sagst ja selber das weder die Firewall tagged und das das Endgerät nicht tagged weiß auch jeder.
Logisch also das es mit so einer unsinnigen Konfig nicht funktionieren kann, das weiß auch ein Switch Laie.
Fazit: Beide Ports als Access Ports, Join VLAN und untagged in 100 fertig ist der Lack. Logisch nachdenken hilft
Dann klappt das auch sofort !
Ich glaube allerdings, dass wenn mein Access Point dann ins Spiel kommt um das Gäste-WLAN aufzuziehen, dann wird dies wieder nicht so ganz funktionieren, das sagt mir zumindest mein Bauchgefühl, vor allem wenn ich mir deine Erläuterung näher betrachte.
Der Access Point ist über Port 1 mit eben diesem Switch-Port 10 verbunden. Und zwar ist dies die einzige physikalische Verbindung mit dem Switch. Bisher ist dort 1U eingestellt und 100T.
1U ist ja der Default und damit kann ich die Web-Oberfläche des AP erreichen. 100T soll meiner Auslegung nach dafür sorgen, dass das Gäste-WLAN über die ID 100 sich letztendlich mit der Firewall und dort über den sog. blauen Port eine IP-Adresse vom DHCP-Server besorgt. Also analog wie mein Vorabtest mit dem Laptop.
Aufgrund des geplanten Gäste-WLANs gibt es auch am Cisco-Port 10 noch die VLAN ID 1 und nicht ausschließlich 100.
Aber wie gesagt, ich werde die oben von dir angegebenen Einstellungen Mal testen und sehen was passiert.
Bis dann schon Mal Danke dir!
Michael
Wieso kann ich dann bei Clients, zum bspw. Windows 10 Laptop eine VLAN ID einstellen?
OK, erwischt.Ja, das kann man natürlich machen, aber was sollte der tiefere Sinn sein bei einem Client Endgerät. Speziell bei einem Laptop den man an wechselnde Lokationen mitnimmt.
Das würde dann bedeuten das man den permanent umstellen muss. 100 Lokationen 100 unterschiedliche Tags. Das ist Unsinn, und deshalb wird es bei Endgeräten nie gemacht. Siehst du vermutlich auch ein ?!
Klar, bei Servern, NAS, Routern, Firewall usw. kann das sinnvoll sein wenn sie in MEHREREN VLANs angeschlossen werden müssen. Siehe dazu auch hier:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
oder auch hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Bei reinen Endgeräten in der Regel nie, da ein singuläres Tag aus den o.a. Gründen wenig Sinn macht.
Das wäre bei mir Port 10 und dort liegt 1U und 100T an.
Und genau DAS ist dein Kardinalsfehler ! Du siehst es mittlerweile wohl selber. Pakete des VLAN 100 kommen dort Tagged an (T=Tagged), U=Untagged) und werden Tagged gesendet. Können also weder deine Firewall lesen noch dein Test Laptop und verwerfen die Pakete. Logisch also das dann nix geht !Ja, genauso ist es ich habe eine 169er IP-Adresse erhalten
War dann aus dem obigen Grund ja auch zu erwarten. Verstehst du nun ja auch nun selber...hoffentlich ?! Ich glaube allerdings, dass wenn mein Access Point dann ins Spiel kommt um das Gäste-WLAN aufzuziehen, dann wird dies wieder nicht so ganz funktionieren
Das ist richtig geglaubt !Dein Access Point mappt ja seine vielfachen WLAN SSIDs auf entsprechende VLAN Tags (siehe VLAN Tutorial Praxisbeispiel). Also die Gast SSID dann auf das VLAN 100 und das sendet der AP dann mit einem VLAN Tag aus.
Folglich muss hier der Switch also auch einen Tagged Port (T) im VLAN 100 haben damit er den Tag lesen und auswerten kann. (siehe VLAN Schnellschulung oben)
Bitte lese zusätzlich dieses Foren Tutorial durch.
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Dort ist im Abschnitt Praxisbeispiel alles zu dem Thema erklärt was du zu MSSID fähigen Accesspoints und VLAN Switches wissen musst !
Bisher ist dort 1U eingestellt und 100T.
Das wäre auch richtig am AP Switchport wenn die SSID die auf VLAN 100 gemappt ist am blauen Interface der Firewall ankommen soll.Alles zum Einrichten von Gäste VLANs findest du in diesem Foren Tutorial:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
bzw.
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
1U ist ja der Default und damit kann ich die Web-Oberfläche des AP erreichen.
Richtig !Auf Tagged Interfaces wird das native VLAN immer mit untagged übertragen. Das Native oder Default VLÖAN ist das VLAN Segment in das der Switch untagged Pakete forwardet die er an diesen Switchports empfängt.
Bei VLAN fähigen Endgeräten wie z.B. deinem MSSID fähigen AP liegt dort immer das Management Interface an.
Folglich legt man das also niemals ins Gastnetz damit die Gäste da nicht rumfummeln können
Generell gehört auf da gar keine SSID drauf gemappt, damit man das AP Management Interface gar nicht per WLAN erreichen kann. (Security !)
Also analog wie mein Vorabtest mit dem Laptop.
Das war auch sehr sinnvoll gedacht. Allerdings ist der Laptop anders als der AP.Um das mit dem Laptop am AP Port zu testen müsstest du den Laptop also mit einem Tag versehen um das zu simulieren das der in VLAN 1 und VLAN 100 arbeiten kann.
Hier ist erklärt wie das geht:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Das Routing kannst du dir wegdenken !
Arbeitest du nur mit einem "normal" konfigurierten Laptop muss dessen Switchport natürlich nur untagged ins VLAN 100 wie oben beschrieben.
Das werde ich heute Abend dann gleich Mal umsetzen.
Wir sind gespannt... 
So, zu Hause meine Konfiguration verglichen mit dem was hier und auch in den verlinkten Artikeln geschrieben wurde.
Die Artikel sind natürlich sehr informativ und zum Teil für einen Laien wie mich mit zuviel Informationen gespickt und zudem noch mit Beispielen, die sehr viel weiter gehen als ich für meinen Zweck eigentlich benötige. Irgendwann Mal verliert man sich dann auch in Details die einem so nicht weiterhelfen.
Alles in allem habe ich persönlich quasi zwei unterschiedliche Ausgangspunkte: einmal Laptop und einmal AP wobei für jeden der beiden Geräte eine andere Konfiguration im Switch notwendig ist. Das Laptop vergessen wir jetzt Mal, weil dies letztendlich nur ein Versuch war die ebenfalls nicht funktionierende Konfiguration WLAN-Clients -> AP -> Switch - Firwall (DHCP, blau) zu testen.
Wobei meine weiter oben bebilderte Konfiguration dem Zustand entspricht, den ich jetzt und schon zuvor auch für den AP eingestellt habe. Diese Konfiguration zeigt aber dennoch das gleiche Verhalten wie das Laptop, wenn ein WLAN-Client eine IP-Adresse von der Firewall anfordert, wird keine IP-Adresse zurückgegeben. Den Dump den ich oben gepostet habe ist analog.
Nochmals zurück zu den VLAN IDs. Wie bereits berichtet, ist der AP wie unten jetzt bebildert konfiguriert. Die WLAN-Clients können sich authentifizieren und die Anfrage kommt am DHCP der Firewall offensichtlich auch an, nur eben nicht retour.
Der Switch im AP ist wie folgt eingestellt:
Und ich gehe jetzt davon aus, dass die Konfiguration der Ports am Cisco auch soweit korrekt ist, wenn nicht, dann bitte korrigieren was falsch ist:
Access Point (Port 1, 1U, 100T) -> Switch (Port 10, 1U, 100T, Port 21 100T) -> Firewall blau (DHCP)
Ich möchte auch gar nicht ausschließen, dass die Firewall im AP mir einen Strich durch die Rechnung macht und quasi keinen Verkehr aus dem Netzwerk durchlässt.
Allerdings muss ich auch erwähnen, dass ich am gleichen AP bereits ein Gast-WLAN betreibe, jedoch ohne VLAN und das mit bestimmten eingerichteten FW-Regeln bereits einwandfrei funktioniert. Der Unterschied ist dabei, dass sich ein im AP integrierten DHCP-Server um die Vergabe der Gast-IP Adressen kümmert.
Im Falle des neu aufzusetzenden VLAN-Gast-WLAN möchte ich dies jedoch der Firewall überlassen, damit dort noch ein Captive-Portal zum Einsatz kommen kann.
Wenn ich dann noch die bestehenden FW-Regeln des aktuellen Gast-WLAN nun 1:1 auch für das VLAN-Gast-WLAN verwende, bessert sich mein Ergebnis nicht. Aus diesem Grund gehe ich jetzt Mal davon aus, dass es nicht an der FW des AP liegt.
Edit: die FW des Access Point habe ich nun ebenfalls ausgeschlossen in dem ich diese komplett gestoppt habe. Auch hier keine IP-Vergabe an den WLAN-Client.
Grüße,
Michael
Die Artikel sind natürlich sehr informativ und zum Teil für einen Laien wie mich mit zuviel Informationen gespickt und zudem noch mit Beispielen, die sehr viel weiter gehen als ich für meinen Zweck eigentlich benötige. Irgendwann Mal verliert man sich dann auch in Details die einem so nicht weiterhelfen.
Alles in allem habe ich persönlich quasi zwei unterschiedliche Ausgangspunkte: einmal Laptop und einmal AP wobei für jeden der beiden Geräte eine andere Konfiguration im Switch notwendig ist. Das Laptop vergessen wir jetzt Mal, weil dies letztendlich nur ein Versuch war die ebenfalls nicht funktionierende Konfiguration WLAN-Clients -> AP -> Switch - Firwall (DHCP, blau) zu testen.
Wobei meine weiter oben bebilderte Konfiguration dem Zustand entspricht, den ich jetzt und schon zuvor auch für den AP eingestellt habe. Diese Konfiguration zeigt aber dennoch das gleiche Verhalten wie das Laptop, wenn ein WLAN-Client eine IP-Adresse von der Firewall anfordert, wird keine IP-Adresse zurückgegeben. Den Dump den ich oben gepostet habe ist analog.
Nochmals zurück zu den VLAN IDs. Wie bereits berichtet, ist der AP wie unten jetzt bebildert konfiguriert. Die WLAN-Clients können sich authentifizieren und die Anfrage kommt am DHCP der Firewall offensichtlich auch an, nur eben nicht retour.
Der Switch im AP ist wie folgt eingestellt:
Und ich gehe jetzt davon aus, dass die Konfiguration der Ports am Cisco auch soweit korrekt ist, wenn nicht, dann bitte korrigieren was falsch ist:
Access Point (Port 1, 1U, 100T) -> Switch (Port 10, 1U, 100T, Port 21 100T) -> Firewall blau (DHCP)
Ich möchte auch gar nicht ausschließen, dass die Firewall im AP mir einen Strich durch die Rechnung macht und quasi keinen Verkehr aus dem Netzwerk durchlässt.
Allerdings muss ich auch erwähnen, dass ich am gleichen AP bereits ein Gast-WLAN betreibe, jedoch ohne VLAN und das mit bestimmten eingerichteten FW-Regeln bereits einwandfrei funktioniert. Der Unterschied ist dabei, dass sich ein im AP integrierten DHCP-Server um die Vergabe der Gast-IP Adressen kümmert.
Im Falle des neu aufzusetzenden VLAN-Gast-WLAN möchte ich dies jedoch der Firewall überlassen, damit dort noch ein Captive-Portal zum Einsatz kommen kann.
Wenn ich dann noch die bestehenden FW-Regeln des aktuellen Gast-WLAN nun 1:1 auch für das VLAN-Gast-WLAN verwende, bessert sich mein Ergebnis nicht. Aus diesem Grund gehe ich jetzt Mal davon aus, dass es nicht an der FW des AP liegt.
Edit: die FW des Access Point habe ich nun ebenfalls ausgeschlossen in dem ich diese komplett gestoppt habe. Auch hier keine IP-Vergabe an den WLAN-Client.
Grüße,
Michael
Also aqui hat natürlich Recht wenn er sagt der Client sollte seine Pakete nicht selber taggen, macht (für einen gewöhnlichen Client) wenig Sinn auch wenn es geht. Am besten stellst du das um und setzt beide Ports am Switch auf VLAN 100 "UnTagged", kein "Admit Tagged only" (es tagged ja nur der Switch) und in den anderen VLANs trägst du für den Port am Switch "Exclude" ein.
Du fokusierst dich bei deinen Tests sehr stark auf das DHCP, ich würde es erstmal mit einer statischen IP und einem schnöden Ping machen. Die beiden IPs auf den VLAN-Ports sollten sich gegenseitig Pingen können mit Rückweg, sie sollten aber keine IP im selben Segment an einem nicht VLAN Port pingen können. Wenn das geht kannst du dein DHCP testen.
Ich habe auch ein seperates DHCP im VLAN allerdings tagged schon mein Router und hat daher an seinem Switchport entsprechend "Tagged" stehen.
Du fokusierst dich bei deinen Tests sehr stark auf das DHCP, ich würde es erstmal mit einer statischen IP und einem schnöden Ping machen. Die beiden IPs auf den VLAN-Ports sollten sich gegenseitig Pingen können mit Rückweg, sie sollten aber keine IP im selben Segment an einem nicht VLAN Port pingen können. Wenn das geht kannst du dein DHCP testen.
Ich habe auch ein seperates DHCP im VLAN allerdings tagged schon mein Router und hat daher an seinem Switchport entsprechend "Tagged" stehen.
Zitat von @ukulele-7:
Ich habe auch ein seperates DHCP im VLAN allerdings tagged schon mein Router und hat daher an seinem Switchport entsprechend "Tagged" stehen.
Ich habe auch ein seperates DHCP im VLAN allerdings tagged schon mein Router und hat daher an seinem Switchport entsprechend "Tagged" stehen.
Das ist ja dann eigentlich genau das gleiche was ich jetzt mit meinem AP eingestellt habe (Mal abgesehen von meinem Test mit dem Laptop).
Auch mein WLAN-Router sollte bereits mit ID 100 taggen, und es kommt ja offensichtlich auch am richtigen DHCP-Server, also am Port 21 (100T) des Cisco-Switch was an. Nur eben ist's eine Einbahnstraße.
Grüße,
Michael
Und ich gehe jetzt davon aus, dass die Konfiguration der Ports am Cisco auch soweit korrekt ist,
Das sieht alles sehr gut aus und sollte auch so klappen !dass die Firewall im AP mir einen Strich durch die Rechnung macht
Das kannst du ja wasserdicht ausprobieren vorher !Dein Ansatz zum Testen war ja genau richtig. Firewall und Testport mit einem Laptop Untagged als Access Port ins VLAN 100 und fertig !
Der Laptop sollte da von der Firewall dann eine entsprechende IP bekommen und das machen dürfen was die Firewall ihn an diesem Port erlaubt.
Damit hast du dann sichere Gewissheit das dein VLAN 100 sauber an der Firewall funktiuoniert.
Klappt das denn wenigstens bei dir ?
Wenn ja hast du nur noch den Anschlussport für den AP zu meistern....
Der Unterschied ist dabei, dass sich ein im AP integrierten DHCP-Server um die Vergabe der Gast-IP Adressen kümmert.
Da musst du natürlich ganz genau aufpassen. Dieser DHCP Server darf niemals auch IP Adressen in der SSID verteilen die du auf die VLAN 100 ID gemappt hast, denn sonst bekämpfen die DHCP Server in der Firewall für VLAN 100 und dieser sich gegenseitig und nix geht mehr !Alte Regel: "Es kann nur einen geben !" (DHCP Server)
Du solltest also mal strategisch vorgehen:
- 1.) Firewall Port und Laptop Port untagged als Access Port definieren und anschliessen.
- 2.) Jetzt MUSS eine Verbindung bestehen zwischen Test Laptop und Firewall Port. IP Adresse per DHCP, Firewall muss pingbar seinn wenn dort ICMP (Ping) erlaubt ist in den FW Regeln !
- Vergiss bis hier erstmal den AP. Bis hier her musst du zwingend kommen. Wenn das nicht klappt, dann hast du noch einen grundsätzlichen Konfig Fehler. Den musst du VORHER lösen sonst suchst du dir einen Wolf wer den Fehler verursacht. Fazit: Schrittweise getestet vorgehen !!!
Klappt das obige ist dein VLAN 100 ja sauber aufgesetzt und funktionsfähig. Du musst dann nur noch bestimmen wie die Pakete dann an den AP gelangen.
Auch das kannst du jetuzt strategisch testen:
- Du konfigurierst zu den 2 obigen Ports noch den 3ten mit 1U und 100T, also 1 Untagged und 100 Tagged
- Jetzt hast du 2 Optionen das zu verifizieren:
- 1.) Du nimmst einen Wireshark Sniffer und siehst dir an ob an diesem Port Pakete mit VLAN 100 Tag ankommen und...ob dort auch VLAN 1 Pakete untagged ankommen. Der Wireshark zeigt dir diese Tags an !
- 2.) Du definierst den Laptop mal um mit einem Tagged Port wie hier_in_diesem_Turorial beschrieben ist.
Vom Laptop erreichst du dann sowohl Ziele im VLAN 1 als auch VLAN 100.
Du simulierst quasi damit den AP mit genau dem Verhalten.
Auch das muss klappen... Mit dem Wireshark messen ist natürlich am einfachsten
Im Grunde ist das doch ne Lachnummer so ein banales Setup zum Fliegen zu bekommen. Das sollte in 10 Minuten erledigt sein ! Die Tips vom Kollegen Ukulele helfen auch. Obwohl DHCP IP Adressvergabe immer ein sicheres Indiz dafür ist das in dem VLAN auch Verbindung da ist. Kommen keine DHCP Broadcasts an ist das immer ein sicheres Indiz das mit der VLAN 2 Layer 2 Konfig was faul ist !
Auch mein WLAN-Router sollte bereits mit ID 100 taggen
Sollte, könnte, müsste....ein bischen zuviel Konjunktiv ! 
Messen mit dem Wireshark wäre hier erheblich sinnvoller !!
