10.06.2021, aktualisiert um 09:51:21 Uhr

1834

Cisco AP 1140 Standalone - Webinterface nicht mehr erreichbar nach VLAN Konfiguration

Hi,

ich bin gerade auf der VLAN Reise und habe schon einiges erreicht. Leider trete ich dabei auch immer wieder in Fettnäpfchen, wie auch heute wieder. ;)

Ich habe einen Cisco AP 1140 im Standalone Betrieb. Ich möchte diesen nun mit VLAN betrieben, VLAN8 für IoT und VLAN9 für LAN. VLAN8 soll auf dem 2,4 GHz und VLAN9 auf dem 5 GHz Interface verfügbar sein. Bei der Konfig. der beiden VLANs bzw. WLANs habe ich nicht den Haken bei "natives" gesetzt. Die Konfiguration steht so weit, dass VLAN8 funktioniert und VLAN9 müsste noch akitviert werden.

Jedoch, ist es nun so, seit dem ich beide VLANs konfiguriert habe, erreiche ich das Webinterface nicht mehr. In meiner Firewall (pfSense) bekommt der AP auch keine IP mehr zugewiesen. Hätte ich VLAN1 dafür noch extra erstellen müssen oder bei einem der WLANs den Hake bei "natives" machen müssen? Könnte ich das im Nachinein lösen indem ich das native VLAN über die Console konfiguriere wie hier beschrieben?

Der AP hängt an Port 16 des TP-Link Switches, welcher als Trunk fungieren soll. Ich bin mir nicht sicher, aber die VLAN-Konfig. von dem Switch sollte dafür doch korrekt sein (folgende Bilder), oder habe ich hier was vergessen?

Grüße,
Patrice

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

Content-ID: 667468

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

Ausgedruckt am: 22.11.2024 um 17:11 Uhr

20 Kommentare

Neuester Kommentar

Moin,

sobald man das Thema VLANs verstanden hat, kann man sich an die Konfiguration machen.
https://networkdirection.net/articles/network-theory/taggeduntaggedandna ...
https://www.kaiherzig.eu/vlan-untagged-vs-vlan-tagged/

Gruß
C.C.

Zitat von @148656:

Moin,

sobald man das Thema VLANs verstanden hat, kann man sich an die Konfiguration machen.
https://networkdirection.net/articles/network-theory/taggeduntaggedandna ...
https://www.kaiherzig.eu/vlan-untagged-vs-vlan-tagged/

Gruß
C.C.

Ich meine grundsätzlich VLANs verstanden zu haben, aber danke für die Links. Ich werde sie mir mal anschauen. Ich habe eher Zweifel an der AP Konfiguration, also was ich dabei hätte beachten müssen. Mit Cisco kenne ich mich nämlich nicht wirklich aus und dies sind eben meine ersten Schritte in diese Richtung.

Grüße,
Patrice

Moin,

wie C.C. schon schrieb, ist das eher eine Verständnisfrage. Stell dir den AP innen wie einen VLAN-Switch vor. Die Verbindung vom TPLink-Switch zum AP (Trunk) hat dann z.B. VLAN1 untagged und VLAN8 und 9 tagged. Die WebGUI des AP kommt ins VLAN1, das VLAN8 und VLAN9 werden werden der jeweiligen SSID zugewiesen. So ist sicher gestellt, das niemand im WLAN auf die WebGUI des AP Zugriff hat.

Gruß NV

Dein Problem ist Herstellerunabhängig.
Wie ich gestern bereits erwähnte. Ein Port kann nur einmal Untagged sein.

Moin, die erste Tabelle stimmt bestimmt nicht. Der TP-Link hat da mit Sicherheit nur die Ports 1-4 und 10-14 und 16 als untagged-VLAN1. Mal prüfen. Wie von C.C. geschrieben: pro Port genau 1x untagged. Wie sollte der Swicht das eine untagged-VLAN sonst vom anderen unterscheiden können?
/pp

von dem Switch sollte dafür doch korrekt sein

Das ist richtig. Die Switchkonfig ist korrekt so. UNtagged im native VLAN 1 und Tagged in den VLANs 8 und 9, was korrekt so ist.
Der AP sollte so in jedem Fall immer eine DHCP IP (Management) aus dem VLAN 1 bekommen sofern der Port im DHCP Client Mode ist. (Check DHCP Leases)
In dieses Management VLAN solltest du natürlich keinesfalls eine SSID auf dem AP legen, denn dein Management VLAN willst du ja ganz sicher NICHT als WLAN irgendwo rausblasen, oder ?!

Sehr hilfreich wäre hier auch deine Cisco AP Konfig ! (show run)
Wie diese in einem VLAN Umfeld auszusehen hat kannst du hier sehen:
Standalone-Einrichtung Cisco Air LAP 1142N
bzw. auch hier in der Thread Kommunikation zum Cisco AP Tutorial:
Cisco WLAN Access Points 1142N, 2702, 3702 für den Heimgebrauch umrüsten

Mein Problem ist jetzt gelöst. Meine Switch-Konfig war doch nicht 100% richitg. Ich habe dem Trunk an Port 16 noch VLAN1 hinzugefügt, also nun sind VLAN 1,8 und 9 tagged auf Port 16. Nach dieser Änderung konnte ich on Probleme wieder auf den AP zugreifen.

Danke an alle Beitragenden!

Grüße,
Patrice

P.S.:

Zitat von @148656:

Dein Problem ist Herstellerunabhängig.
Wie ich gestern bereits erwähnte. Ein Port kann nur einmal Untagged sein.

Zitat von @PeterPanter:

Moin, die erste Tabelle stimmt bestimmt nicht. Der TP-Link hat da mit Sicherheit nur die Ports 1-4 und 10-14 und 16 als untagged-VLAN1. Mal prüfen. Wie von C.C. geschrieben: pro Port genau 1x untagged. Wie sollte der Swicht das eine untagged-VLAN sonst vom anderen unterscheiden können?

Diesem Problem werde ich noch nach gehen und VLAN1 ausdünnen.

also nun sind VLAN 1,8 und 9 tagged auf Port 16.

Sorry aber mit Verlaub ist das ziemlicher Blödsinn, wenigstens was VLAN 1 anbetrifft.
VLAN 1 liegt da ja schon UNtagged an wenn da PVID 1 am Port gesetzt ist. Dadrauf dann nochmals VLAN 1 zu taggen ist ziemlicher Quatsch. Doppelt gemoppelt und ein Konfig Fehler. Zudem erzeugt es dann auch noch einen gefährlichen Loop... Aber egal...
Case closed...

Zitat von @aqui:

also nun sind VLAN 1,8 und 9 tagged auf Port 16.

Warum soll das Blödsinn sein? Erst lag da VLAN 1 untagged an. Nach dem das nicht ging, habe ich nun aus untagged, tagged gemacht und es läuft. Der Cisco AP außerdem sagt, wie im unteren Bild zu sehen ist, dass das Management VLAN, VLAN 1 ist.

Für mich klingt das logisch, weil der management Traffic nicht untagged, sondern auch tagged ist, sonst würde das ja im AP nicht stehen, oder?

Grüße,
Patrice

Nach dem das nicht ging,

Was ja aber klar zeigt das du einen Konfig Fehler auf dem Switch und/oder AP Port gemacht hast, das ist doch klar !
Es ist doch sinnfrei das native VLAN zu taggen ! Aber egal...

sonst würde das ja im AP nicht stehen, oder?

Dann lies doch aber bitte mal was da genau steht !! Native VLAN ! Was das ist steht hier:
https://learningnetwork.cisco.com/s/question/0D53i00000Kt6faCAB/native-v ...
Zitat: native vlan means that device will never put/insert tag VLAN ID on Ethernet frame when it leaves port
Siehe auch
Native VLAN Verständnisproblem

VLAN 1 ist also Native VLAN und deshalb immer untagged am Cisco AP !
Würdest du mal ein show run machen (Telnet mit PuTTY auf den AP) und dir die AP Konfig einmal genau ansehen siehst du das auch sofort.

Zitat von @aqui:

Nach dem das nicht ging,

Was ja aber klar zeigt das du einen Konfig Fehler auf dem Switch und/oder AP Port gemacht hast, das ist doch klar !
Es ist doch sinnfrei das native VLAN zu taggen ! Aber egal...

sonst würde das ja im AP nicht stehen, oder?

Ich verstehe was du meinst, aber ich habe das gerade noch mal ausprobiert. Ich will das verstehen warum es so geht und nicht wie vermutet. Sobald ich im Switch VLAN 1 an Port 16 auf untagged umstellen, habe ich keinen Zugriff mehr auf das Webinterface des AP und auch auf das des Switches. Das bedeutet doch im Umkehrschluss, dass der AP VLAN 1 als tagged behandelt wie auch die anderen beiden VLANs. Somit arbeitet der AP nicht mit dem native VLAN.

Ich habe mir mal die AP-Konfig über das Webinterface gezogen und hoffe das ist das Gleiche wie die Konsolenausgabe mit "show run". Kannst du mir daran sagen wie es sich nun genau verhält?

!
! Last configuration change at 23:30:33 +0100 Wed May 19 2021
version 15.3
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname ap1
!
!
logging rate-limit console 9
enable secret XXXXXXXXXXXX
!
no aaa new-model
clock timezone +0100 1 0
no ip source-route
no ip cef
!
!
!
!
dot11 pause-time 100
dot11 syslog
!
dot11 ssid XXXXXXXXXXXXXXXX
   vlan 9
   authentication open 
   authentication key-management wpa version 2
   guest-mode
   wpa-psk ascii XXXXXXXXXXXX
!
dot11 ssid XXXXXXXXXXXXXX
   vlan 8
   authentication open 
   authentication key-management wpa version 2
   guest-mode
   wpa-psk ascii XXXXXXXXXXXXXXX
!
!
!
no ipv6 cef
!
crypto pki trustpoint XXXXXXXXXXXXXXXXXX
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-1440720061
 revocation-check none
 rsakeypair XXXXXXXXXXXXXXX
!
!
crypto pki certificate chain XXXXXXXXXXXXXX
 certificate self-signed 01 nvram:IOS-Self-Sig#1.cer
username XXXXXXXXXXX password XXXXXXXXXXXXXXX
!
!
bridge irb
!
!
!
interface Dot11Radio0
 no ip address
 !
 encryption mode ciphers aes-ccm 
 !
 encryption vlan 8 mode ciphers aes-ccm 
 !
 ssid BND Spionage LKW
 !
 antenna gain 0
 speed  basic-1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15.
 station-role root
 bridge-group 1
 bridge-group 1 subscriber-loop-control
 bridge-group 1 spanning-disabled
 bridge-group 1 block-unknown-source
 no bridge-group 1 source-learning
 no bridge-group 1 unicast-flooding
!
interface Dot11Radio0.8
 encapsulation dot1Q 8
 bridge-group 8
 bridge-group 8 subscriber-loop-control
 bridge-group 8 spanning-disabled
 bridge-group 8 block-unknown-source
 no bridge-group 8 source-learning
 no bridge-group 8 unicast-flooding
!
interface Dot11Radio1
 no ip address
 !
 encryption mode ciphers aes-ccm 
 !
 encryption vlan 9 mode ciphers aes-ccm 
 !
 ssid XXXXXXXXXXXXXXXXXXXX
 !
 antenna gain 0
 peakdetect
 no dfs band block
 speed  basic-6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15.
 channel dfs
 station-role root
 bridge-group 1
 bridge-group 1 subscriber-loop-control
 bridge-group 1 spanning-disabled
 bridge-group 1 block-unknown-source
 no bridge-group 1 source-learning
 no bridge-group 1 unicast-flooding
!
interface Dot11Radio1.9
 encapsulation dot1Q 9
 bridge-group 9
 bridge-group 9 subscriber-loop-control
 bridge-group 9 spanning-disabled
 bridge-group 9 block-unknown-source
 no bridge-group 9 source-learning
 no bridge-group 9 unicast-flooding
!
interface GigabitEthernet0
 no ip address
 duplex auto
 speed auto
 bridge-group 1
 bridge-group 1 spanning-disabled
 no bridge-group 1 source-learning
!
interface GigabitEthernet0.8
 encapsulation dot1Q 8
 bridge-group 8
 bridge-group 8 spanning-disabled
 no bridge-group 8 source-learning
!
interface GigabitEthernet0.9
 encapsulation dot1Q 9
 bridge-group 9
 bridge-group 9 spanning-disabled
 no bridge-group 9 source-learning
!
interface BVI1
 mac-address XXXXXXXXXXXXXXXXXXX
 ip address dhcp client-id GigabitEthernet0
 ipv6 address dhcp
 ipv6 address autoconfig
 ipv6 enable
!
ip forward-protocol nd
no ip http server
ip http secure-server
ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
!
!
bridge 1 route ip
!
!
!
line con 0
line vty 0 4
 login local
 transport input all
!
sntp server pfsense
sntp broadcast client
end

Grüße,
Patrice

Zitat von @148656:

Dein Problem ist Herstellerunabhängig.
Wie ich gestern bereits erwähnte. Ein Port kann nur einmal Untagged sein.

Habe ich jetzt angepasst, danke!

Sobald ich im Switch VLAN 1 an Port 16 auf untagged umstellen, habe ich keinen Zugriff mehr auf das Webinterface des AP

Sorry, aber das ist Quatsch !
Wenn du mit deinem Setup PC an einen anderen VLAN 1 Port des Switches hängst kannst du doch niemals die Management Verbindung auf den Switch verlieren, das ist doch Unsinn.
Wenn du natürlich am WLAN hängst muss man sich nicht wundern. Logisch da sman sich dann den Ast absägt auf dem man sitzt. Der Cisco STP Prozess geht dann für 40 Sek. in den Blocking Mode bevor er das Interface wieder ins Forwarding bringt.

Auch wenn du den AP an einen simplen UNtagged VLAN 1 Port steckst sollte dieser sofort Management Zugang im VLAN 1 haben. Logisch, denn der Cisco AP steckt im Default IMMER mit seiner Management IP im Default/Native VLAN was ja 1 ist.

Man kann dann nur die Schlussfolgerung zeihen das du deinen Cisco AP komplett falsch konfiguriert hast. Ob das so ist können wir ja nicht checken weil die Konfig bis dato von dir fehlt.

Wenn du dir aber die dir oben geposteten Links mit den Beispielkonfigs ansiehst und auch umsetzt, dann klappt das sofort !
Das Management Interface von APs ist generell IMMER UNtagged im Default !! Egal welcher Hersteller.

Ich versuche auch mal mein Glück, vielleicht helfen ja Bilder. @Siegfried36: Was @aqui dir zu erklären versucht, ist 100% richtig.

Hier siehst du am Port 1 die Verbindung, die von einem Cisco 250 kommt. VLAN1 ist untagged und alle anderen tagged.

Am Port 23 hängt ein Mitarbeiter-WLAN-AP (Cisco WAP-150). Das WebGUI des AP hängt im VLAN1. Es liegen an der Verbindung zum AP zwar alle anderen VLANs auch an. Aber das interessiert den AP nicht, da er auf der SSID dieses WLANs nur die VLAN-ID 60 konfiguriert hat. Hier ist VLAN1 untagged und alle anderen VLANs tagged.

Am Port 24 hängt ein Lancom LW-500 AP für das Gäste-WLAN. Dessen WebGUI liegt ebenfalls im VLAN1 und die SSID hat das VLAN70. VLAN1 ist auch hier untagged und VLAN70 tagged. Das dröselt der AP auf, weil er sich diesbezüglich wie ein Switch verhält.

Entsprechende Konfiguration vorausgesetzt, steckst du ein Gerät an einem VLAN1-Port ein und das Gerät erhält per DHCP seine Adresse aus dem Scope von VLAN1. So kommst du immer auf die GUI. Die SSID des WLAN setzt du in der Konfig des AP (!!!) in ein anderes VLAN. Dann können die WLAN-Geräte nicht auf die WebGUI des AP zugreifen.

Und hier im Portstatus sieht man das genau. Bei allen "Trunkports" wird der Tag des VLAN1 entfernt bzw. ist gar nicht erst vorhanden. Bei allen anderen Accessports, die Member anderer VLANs sind, heißt es "untag all". Logisch, weil die Endgeräte normalerweise mit dem Tag nichts anfangen.

Gruß NV

Zitat von @aqui:

Sobald ich im Switch VLAN 1 an Port 16 auf untagged umstellen, habe ich keinen Zugriff mehr auf das Webinterface des AP

Habe das noch mal von einem anderem Subnetz ausprobiert, es funktioniert auch untagged. Das ist nice. Dann habe ich die ganze Zeit wohl einen Denkfehler gemacht und befand mich im falschen Subnetz. Irgendwie unspektakulär und peinlich diese Einsicht. Danke.

Man kann dann nur die Schlussfolgerung zeihen das du deinen Cisco AP komplett falsch konfiguriert hast. Ob das so ist können wir ja nicht checken weil die Konfig bis dato von dir fehlt.

Oben, zwei Posts vorher, habe ich die Konfig doch gepostet.

Zitat von @Siegfried36:
Habe das noch mal von einem anderem Subnetz ausprobiert, es funktioniert auch untagged. Das ist nice. Dann habe ich die ganze Zeit wohl einen Denkfehler gemacht und befand mich im falschen Subnetz. Irgendwie unspektakulär und peinlich diese Einsicht. Danke.

Ich glaube, der häufigste Denkfehler ist, das man versucht, das LAN-Interface des AP's in das VLAN für die WLAN-Clients zu setzen. Das LAN-Interface bleibt in seinem VLAN (z.B. 1) und das WLAN-Interface bekommt das dafür vorgesehene VLAN (z.B. 8). Das macht man auf dem AP, nicht auf dem Switch. Der Draht (Trunk) zwischen dem Switch und dem AP befördert dann VLAN1 (untagged) und VLAN8 (tagged). Eigentlich höchst simpel.

der häufigste Denkfehler ist, das man versucht, das LAN-Interface des AP's in das VLAN für die WLAN-Clients zu setzen.

Ja, das ist leider oft der Fall obwohl einem schon der gesunde IT Verstand sagt das es keine wirklich gute Idee ist den Management Zugang in einem Produktiv WLAN raus in die Welt zu blasen.
Der Management Zugang sollte logischerweise IMMER nur per Kupfer erreichbar sein. Guter Hinweis ! 👍

Eigentlich höchst simpel.

So ist es ! Zumal auch jeder AP Hersteller das generell so macht.

Zitat von @NixVerstehen:

Das ist der Punkt an Konzepten, die man verstanden hat. Sie sind dann simpel. Bis dahin muss man, aber einiges auf sich nehmen, vor allem Fehler. Ohne Fehler geht's nicht. Wie Harald Lesch schon sagte:"Lasst uns empor irren.".

Damit möchte ich sagen: Vielen Dank an euch, die uns Interessierten/Anfängern helfen auf unserem irrenden Weg. Aber verliert bitte nicht die Geduld dabei. Denn wer, wenn nicht ihr steht uns auf unserem Weg bei.

Grüße,
Patrice