25
Accesspoint bekommt keine IP Adresse hinter Cisco CBS 350
Guten Abend,
Ich habe Accesspoints (cisco 2702) welche nach Tutorial konfiguriert sind erhalten hinter dem zweiten Cisco switch keine IP-Adresse mehr vom DHCP Server.
Ich habe eine Opnsense auf welcher mehrere vlans konfiguriert sind. Auf der Sense läuft ein dhcp server welcher die Ip-adressen der vlans verwaltet.
An die Opnsense ist ein cisco CBS 350 switch (Switch 01) angeschlossen an welchem wiederum ein weiterer CBS 350 (Switch 02) hängt.
alle Ports der switche sind als vlan-Trunks eingerichtet.
vlan30 soll das Verwaltungsnetzwerk sein in welchem später die Switche und Accesspoints ihre IP-Adressen erhalten.
Wenn die Access Points an Switch 01 angeschlossen werden erhalten diese eine IP-Adresse und alles funktioniert wie es soll. Wenn die Access Points allerdings an Switch 02 angeschlossen werden beziehen diese keine IP-Adresse. Die SSID wird jedoch ausgestrahlt und die Clients im zugehörigen WLAN erhalten eine IP.
Ein Notebook per Kabel läuft problemfrei an beiden Switchen 01 & 02 und erhält auch eine IP.
Hat jemand eine Idee weshalb der Adressenbezug hinter switch 02 für die AP's nicht funktioniert?
liebe Grüße
Ben
Ich habe Accesspoints (cisco 2702) welche nach Tutorial konfiguriert sind erhalten hinter dem zweiten Cisco switch keine IP-Adresse mehr vom DHCP Server.
Ich habe eine Opnsense auf welcher mehrere vlans konfiguriert sind. Auf der Sense läuft ein dhcp server welcher die Ip-adressen der vlans verwaltet.
An die Opnsense ist ein cisco CBS 350 switch (Switch 01) angeschlossen an welchem wiederum ein weiterer CBS 350 (Switch 02) hängt.
alle Ports der switche sind als vlan-Trunks eingerichtet.
vlan30 soll das Verwaltungsnetzwerk sein in welchem später die Switche und Accesspoints ihre IP-Adressen erhalten.
Wenn die Access Points an Switch 01 angeschlossen werden erhalten diese eine IP-Adresse und alles funktioniert wie es soll. Wenn die Access Points allerdings an Switch 02 angeschlossen werden beziehen diese keine IP-Adresse. Die SSID wird jedoch ausgestrahlt und die Clients im zugehörigen WLAN erhalten eine IP.
Ein Notebook per Kabel läuft problemfrei an beiden Switchen 01 & 02 und erhält auch eine IP.
Hat jemand eine Idee weshalb der Adressenbezug hinter switch 02 für die AP's nicht funktioniert?
liebe Grüße
Ben
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: 93152101949
Url: https://administrator.de/contentid/93152101949
Printed on: June 20, 2024 at 11:06 o'clock
25 Comments
Latest comment
Moin,
hast Du auch die gleichen VLAN im zweiten Switch mit eingetragen? Und mal geschaut ob der DHCP-Server im zweiten Switch abgeschaltet?
Das wäre jetzt so meine Idee.
Gruß
hast Du auch die gleichen VLAN im zweiten Switch mit eingetragen? Und mal geschaut ob der DHCP-Server im zweiten Switch abgeschaltet?
Das wäre jetzt so meine Idee.
Gruß
Moin,
Hast du die (richtigen) VLANs an allen Uplinks richtig gesetzt? Als auch korrekt auf tagged/ untagged gesetzt?
Insbesondere zwischen den Switchen.
Mach auch bitte mal eine Zeichnung, damit wir wissen, was wie zusammengesteckt wurde.
Hast du die (richtigen) VLANs an allen Uplinks richtig gesetzt? Als auch korrekt auf tagged/ untagged gesetzt?
Insbesondere zwischen den Switchen.
Mach auch bitte mal eine Zeichnung, damit wir wissen, was wie zusammengesteckt wurde.
Gibt bei Cisco auch so einen Protect moden den man pro Port an und aus machen kann, heisst glaub BDGuard, der muss wenn ein switch am port hängt deaktiviert sein.
1
Läuft Dein Mgmt-vLAN tagged oder untagged auf dem Switch und dem AP? Nicht, dass der AP das tagged erwartet, Du es aber untagged auf den Switch laufen hast
Was sagt denn das logging ? Vielleicht findet sich hier ein Hinweis
Wenn es an Switch 1 geht und an Switch 2 nicht wo liegen denn die Unterschiede in der Konfig ?
Ansonsten mach gerne mal eine Zeichnung deines Aufbaus das hilft uns es zu verstehen
Wenn es an Switch 1 geht und an Switch 2 nicht wo liegen denn die Unterschiede in der Konfig ?
Ansonsten mach gerne mal eine Zeichnung deines Aufbaus das hilft uns es zu verstehen
Häufiger Fehler ist das nicht bedacht wird das die DHCP Requests des APs immer im Native bzw. PVID VLAN (also UNtagged) gesendet werden was am Switchport anliegt an das der AP angeschlossen ist!
Kollege @Visucius hat es oben schon richtig bemerkt.
Daher gilt es sicherzustellen das im Native bzw. PVID VLAN was ja in der Regel das Management VLAN des oder der APs sind ein DHCP Server sich befindet oder ein DHCP Relay konfiguriert ist. Vermutlich ist das beim TO nicht der Fall oder das PVID VLAN ist nicht gesetzt.
Leider ist die Beschreibung des TOs hier sehr oberflächlich, denn er macht keinerlei hilfreiche Angaben weder zur AP Switchport Konfiguration des 350ers noch dazu in welchem Mode der Accesspoint betrieben wird.
(Singuläre SSID oder MSSID Setup oder dynmaische VLANs etc.)
Damit ist eine zielführende Antwort schwierig wenn man nicht ins Kristallkugeln abdriften will. Etwas mehr Detailinfos würden, wie immer, für ein Troubleshooting hier sehr helfen...
Mit Spanning Tree oder BPDU Modes hat das Fehlerbild nichts zu tun.
Kollege @Visucius hat es oben schon richtig bemerkt.
Daher gilt es sicherzustellen das im Native bzw. PVID VLAN was ja in der Regel das Management VLAN des oder der APs sind ein DHCP Server sich befindet oder ein DHCP Relay konfiguriert ist. Vermutlich ist das beim TO nicht der Fall oder das PVID VLAN ist nicht gesetzt.
Leider ist die Beschreibung des TOs hier sehr oberflächlich, denn er macht keinerlei hilfreiche Angaben weder zur AP Switchport Konfiguration des 350ers noch dazu in welchem Mode der Accesspoint betrieben wird.
(Singuläre SSID oder MSSID Setup oder dynmaische VLANs etc.)Damit ist eine zielführende Antwort schwierig wenn man nicht ins Kristallkugeln abdriften will. Etwas mehr Detailinfos würden, wie immer, für ein Troubleshooting hier sehr helfen...
Mit Spanning Tree oder BPDU Modes hat das Fehlerbild nichts zu tun.
Hi,
danke für die vielen Rückmeldungen.
Als ich die Konfiguration des Ports hier fürs Forum dokumentieren wollte ist mir aufgefallen, dass bei Switch 02 nicht alle Ports des Accesspoints sauber auf konfiguriert waren. Bei manchen war noch das Default native vlan 01 eingestellt. Als ich es dann auf vlan 30 geändert habe hat's direkt funktioniert.
Ich hätte noch eine weitere Frage.
Für Wartungszwecke ist die opnsense mit einem Wireguard Tunnel verbunden. Die Accesspoints sind über das Tunnelnetzwerk erreichbar und erhalten die IP per DHCP 172.20.30.1xx/24.
Die IP's von den switchen sind statisch festgelegt und im Bereich 172.20.30.x/24
Ein Zugriff über den Tunnel auf die AP's funktioniert. Bei den Cisco switchen wird's offenbar geblockt. Kein Ping o.ä. ist möglich. Gibt es da einen Häkchen (o.ä.) das in der Oberfläche der Switche gesetzt werden muss, damit ein Zugriff von außen erlaubt wird?
danke für die vielen Rückmeldungen.
Als ich die Konfiguration des Ports hier fürs Forum dokumentieren wollte ist mir aufgefallen, dass bei Switch 02 nicht alle Ports des Accesspoints sauber auf konfiguriert waren. Bei manchen war noch das Default native vlan 01 eingestellt. Als ich es dann auf vlan 30 geändert habe hat's direkt funktioniert.
Ich hätte noch eine weitere Frage.
Für Wartungszwecke ist die opnsense mit einem Wireguard Tunnel verbunden. Die Accesspoints sind über das Tunnelnetzwerk erreichbar und erhalten die IP per DHCP 172.20.30.1xx/24.
Die IP's von den switchen sind statisch festgelegt und im Bereich 172.20.30.x/24
Ein Zugriff über den Tunnel auf die AP's funktioniert. Bei den Cisco switchen wird's offenbar geblockt. Kein Ping o.ä. ist möglich. Gibt es da einen Häkchen (o.ä.) das in der Oberfläche der Switche gesetzt werden muss, damit ein Zugriff von außen erlaubt wird?
Bei den Cisco switchen wird's offenbar geblockt.
Nein, da wird normal natürlich nie etwas "geblockt" wenn man nicht explizit ACLs dort definiert.Sehr wahrscheinlich hast du vergessen auf dem CBS350 eine Default Route: 0.0.0.0/0 => Default Gateway zu konfigurieren?!
Ohne diese Default Route kennt der L3 Switch kein Default Gateway und scheitert damit dann an der Rückroute des Tunneltraffics.
Klassischer Anfängerfehler und ein Traceroute hätte dir das auch gezeigt. 😉 Guckst du dazu auch HIER.
Nebenbei würde dir ein IKEv2 VPN auf der OPNsense die überflüssige Frickelei mit externer VPN Clientsoftware ersparen:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Moin,
Ich selber nutze nur ein CBS350 als Core Switch und CBS250 als Uplink Switch. Wichtig ist, wenn ich ich nicht irre, der Uplink vom CBS350 1 zum CBS350 2
Und am CBS350 2 sollte der Port wo der AP angesteckt werden so aussehen
Gruß
Ich selber nutze nur ein CBS350 als Core Switch und CBS250 als Uplink Switch. Wichtig ist, wenn ich ich nicht irre, der Uplink vom CBS350 1 zum CBS350 2
interface GigabitEthernet XX
description "Uplink "
switchport mode trunk
switchport general allowed vlan add 1,10,20,30,40,50,60 tagged Und am CBS350 2 sollte der Port wo der AP angesteckt werden so aussehen
interface GigabitEthernet XX
negotiation 100f
description "WLAN Flur OG"
switchport mode trunk
switchport general allowed vlan add 10,20,40,50 tagged
switchport general allowed vlan add 1 untagged Gruß
1
@headcrash warum ist der AP-Port als Trunk konfiguriert? In der Regel ist die Kommunikation über ein untagged VLAN zum WLC/Firewall/Router verschlüsselt (DTLS), von daher ist Trunk nicht notwendig. Die VLAN Taggs werden dann direkt der SSID zugewiesen.
Und aus diesem Grund muss der Port an dem der AP angeschlossen ist, ein Trunk Port sein mit Management als nativ Vlan. Wie sonst sollen die VLan's über der Port gehen?
warum ist der AP-Port als Trunk konfiguriert?
Weil der Kollege mit einem MSSID (Multiple SSID) Setup arbeitet. Sprich der AP spannt mehrere WLAN Netze bzw. SSIDs auf die dann auf dedizierte VLANs gemappt sind.Klassisches Allerwelts MSSID Setup.... (Siehe zu der Thematik auch HIER)
Abgesehen davon verwendet der TO (vermutlich) keinen Controller sondern betreibt die Cisco Accesspoints sehr wahrscheinlich nicht im Lightweight sondern im Standalone Mode?!
Das was du da Controller bezogen beschreibst ist zudem tiefstes WLAN Neandertal mit einem zentralen CAPWAP Tunneling der APs auf den Controller der dann die MSSIDs auskoppelt.
Sowas hat man in Urzeiten einmal gemacht aber bei heutigen WLAN Raten ist sowas nicht skalierbar und damit sinnvoll nutzbar.
Man bräuchte mehrere 40G oder 100G Interfaces am Controller um heutige WLAN Bandbreiten so garantieren zu können. Solche Designs sind deshalb lange tot und man macht sowas heute mit Local Termination oder auch Local Breakout oder Flexconnect genannt und terminiert die APs dann direkt an der Switch Backbone Infrastruktur mit dem entsprechenden MSSID zu VLAN Tagging am Port.
Super, es lag an der default route im Switch!
Danke!
Ja, die AP's sind im standalone mode. Da ich keinen Controller habe und die cisco AP's reihenweise aus den Industrieunternehmen raus fliegen.
Ziel ist es einen abseits gelegenen Bauernhof(meiner Eltern), der kein Handyempfang hat mit wlan abzudecken.
Der Aufbau ist etwa so:
|starlink-Modem| ->|opnsense| -> |CBS350| ->|CBS350|
wobei an den beiden Layer 3 Switchen (CBS350) wahrscheinlich noch Layer 2 Switche und ~10-15 Access Points hängen werden.
Die Access Points strahlen dann später 3 SSID's (privat + Mitarbeiter + Gäste) aus.
Der Tunnel läuft über einen gemieteten vlan server für 1,5€/Monat mit fester IPv4 Adresse. Da wir etwas außerhalb über Starlink surfen würde ich mich dem Thema erst wieder anfassen, wenn ich eine gute Lösung mit IPv6 gefunden habe. :D
In der GUI der Switche sind die VLANS definiert, dann alle Ports auf Trunk gestellt und im Reiter "Port VLAN Membership" native VLAN auf 30 und alle untagged vlans durchgeschleift.
Ist für mich vorerst eine einfache Lösung da ich mit dem Notebook per Kabel connecten kann und auch die Accesspoints angeschlossen werden können um die vlans auszustrahlen.
Ich hätte noch eine Frage zur Konfiguration des IEEE 802.11r Standards bei den Access Points.
(Falls in einen neuen Betrag soll einfach kurz schreiben dann verschiebe ich es und würde diesen Beitrag als gelöst markieren.)
Ursprünglich wollte ich .11r per Konsole in die config der Accesspoints mit diesen Befehlen implementieren:
in der Gui sieht das darauf hin m.M. so aus:
Beim prüfen der SSID Einstellungen ist mir aufgefallen, dass man dot11r auch im Key Management konfigurieren kann. Siehe "WPAv2 dot11r"
Wenn ich dieses jedoch verwende kann kein client mehr dem WLAN beitreten, angeblich falsches Passwort. Wird zurück zu WPAv2 gewechselt funktioniert es wieder.
Kann mir jemand sagen woran das liegt bzw. welche Einstellung Sinnvoller ist (sofern dot11r funktioniert)?
liebe Grüße
Ben
Danke!
Ja, die AP's sind im standalone mode. Da ich keinen Controller habe und die cisco AP's reihenweise aus den Industrieunternehmen raus fliegen.
Ziel ist es einen abseits gelegenen Bauernhof(meiner Eltern), der kein Handyempfang hat mit wlan abzudecken.
Der Aufbau ist etwa so:
|starlink-Modem| ->|opnsense| -> |CBS350| ->|CBS350|
wobei an den beiden Layer 3 Switchen (CBS350) wahrscheinlich noch Layer 2 Switche und ~10-15 Access Points hängen werden.
Die Access Points strahlen dann später 3 SSID's (privat + Mitarbeiter + Gäste) aus.
Nebenbei würde dir ein IKEv2 VPN auf der OPNsense die überflüssige Frickelei mit externer VPN Clientsoftware ersparen:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Ja, wir hatten IPsec früher auch im Büro. Ich habe allerdings den Eindruck, dass Wireguard deutlich performanter ist.IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Der Tunnel läuft über einen gemieteten vlan server für 1,5€/Monat mit fester IPv4 Adresse. Da wir etwas außerhalb über Starlink surfen würde ich mich dem Thema erst wieder anfassen, wenn ich eine gute Lösung mit IPv6 gefunden habe. :D
In der GUI der Switche sind die VLANS definiert, dann alle Ports auf Trunk gestellt und im Reiter "Port VLAN Membership" native VLAN auf 30 und alle untagged vlans durchgeschleift.
Ist für mich vorerst eine einfache Lösung da ich mit dem Notebook per Kabel connecten kann und auch die Accesspoints angeschlossen werden können um die vlans auszustrahlen.
Ich hätte noch eine Frage zur Konfiguration des IEEE 802.11r Standards bei den Access Points.
(Falls in einen neuen Betrag soll einfach kurz schreiben dann verschiebe ich es und würde diesen Beitrag als gelöst markieren.)
Ursprünglich wollte ich .11r per Konsole in die config der Accesspoints mit diesen Befehlen implementieren:
dot11 dot11r reassociation-time value 30
dot11 dot11r pre-authentication over-airBeim prüfen der SSID Einstellungen ist mir aufgefallen, dass man dot11r auch im Key Management konfigurieren kann. Siehe "WPAv2 dot11r"
Kann mir jemand sagen woran das liegt bzw. welche Einstellung Sinnvoller ist (sofern dot11r funktioniert)?
liebe Grüße
Ben
Moin,
also ich weiß nicht ob das ein Fehler ist, aber ich habe bei meinen Ports
die Einstellung
Access VLAN ID: Native VLAN ID: General PVID alle gleich.
Zudem würde ich Dir empfehlen die AP´s nicht mit der GUI zu programmieren. Per Konsole war das für mich als Anfänger leichter.
Gruß
also ich weiß nicht ob das ein Fehler ist, aber ich habe bei meinen Ports
die Einstellung
Access VLAN ID: Native VLAN ID: General PVID alle gleich.
Zudem würde ich Dir empfehlen die AP´s nicht mit der GUI zu programmieren. Per Konsole war das für mich als Anfänger leichter.
Gruß
@headcrash in deinem Screenshot ist der Port Access, weiter oben aber auf Trunk. Das widerspricht sich etwas.
@aqui mir ist das Thema WLAN "local termination" nicht bekannt und auch die anderen Begriffe ergeben keine passenden Suchergebnisse bis auf den letzten. "FlexConnect" scheint hier auch ein Produkt von Cisco zu sein. Btw habe ich dazu das hier gefunden...
When configuring a wireless access point to function in FlexConnect mode, it can be connected to a switch using either an access port or a trunk port.
Wenn das alles nur in der Cisco-Welt funktioniert, dann ist das irrelevant und das "Neandertal" weiterhin passend. Es sei denn, die anderen Hersteller haben das unter einem anderen Namen implementiert.
Abgesehen davon deine Aussage mit 40/100G am WLC ist ziemlich vage/übertrieben. Selbst wenn die APs mit 10GbE am Netz hängen, verteilt sich die Bandbreite auf 2.4, 5 und 6 GHz und Anzahl der Clients. Also mehr als 10Gbps werden nicht möglich sein.
@aqui mir ist das Thema WLAN "local termination" nicht bekannt und auch die anderen Begriffe ergeben keine passenden Suchergebnisse bis auf den letzten. "FlexConnect" scheint hier auch ein Produkt von Cisco zu sein. Btw habe ich dazu das hier gefunden...
When configuring a wireless access point to function in FlexConnect mode, it can be connected to a switch using either an access port or a trunk port.
Wenn das alles nur in der Cisco-Welt funktioniert, dann ist das irrelevant und das "Neandertal" weiterhin passend. Es sei denn, die anderen Hersteller haben das unter einem anderen Namen implementiert.
Abgesehen davon deine Aussage mit 40/100G am WLC ist ziemlich vage/übertrieben. Selbst wenn die APs mit 10GbE am Netz hängen, verteilt sich die Bandbreite auf 2.4, 5 und 6 GHz und Anzahl der Clients. Also mehr als 10Gbps werden nicht möglich sein.
@DerMaddin
Das liegt vielleicht daran das der TO kein Firmware Update gemacht hat.
Aber beim TO sind Access VLAN ID und General PVID dem VLAN 20 zugewiesen und Native VLAN ID ist dem VLAN 30 zugewiesen.
Da bin ich mir nicht sicher ob das so in Ordnung ist.
Gruß
Das liegt vielleicht daran das der TO kein Firmware Update gemacht hat.
Aber beim TO sind Access VLAN ID und General PVID dem VLAN 20 zugewiesen und Native VLAN ID ist dem VLAN 30 zugewiesen.
Da bin ich mir nicht sicher ob das so in Ordnung ist.
Gruß
Hi,
@Headcrach ich denke der grundlegende Unterschied ist, das dein Interface im currend vlan mode Access unterwegs ist und ich bin im Trunk modus.
Die unteren Teile bei welchen in meinem Bildschirmfoto noch vlan20 steht werden m.M. im Trunk Mode nicht angesprochen weshalb die Einstellung dort egal sein dürfte.
Die Grundkonfiguration habe ich auch per Konsole gemacht, danach allerdings im GUI rumgespielt und dieses WPAv2 dot11r bei enable WPA gefunden.
@Headcrach ich denke der grundlegende Unterschied ist, das dein Interface im currend vlan mode Access unterwegs ist und ich bin im Trunk modus.
Die unteren Teile bei welchen in meinem Bildschirmfoto noch vlan20 steht werden m.M. im Trunk Mode nicht angesprochen weshalb die Einstellung dort egal sein dürfte.
Die Grundkonfiguration habe ich auch per Konsole gemacht, danach allerdings im GUI rumgespielt und dieses WPAv2 dot11r bei enable WPA gefunden.
In einem MSSID WLAN Setup muss der AP Anschlussport am Switch zwangsweise als Trunk gesetzt sein. Wie sollte man sonst die auf die VLANs getaggten SSIDs übertragen können.
Generell sollte man die APs so betreiben damit das Management Interface bzw. VLAN ohne ein zugewiesenes WLAN arbeitet. Wer will in seinem gesicherten Management VLAN ein VLAN betreiben? Aus Sicherheitsgründen ist das ein NoGo.
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
https://www.cisco.com/c/de_de/support/docs/wireless-mobility/wireless-la ...
Fakt ist das auch deine Clients .11r supporten müssen ansonsten scheitert eine Assoziation mit einem .11r aktiviertem WLAN.
@DerMaddin
Dennoch sind dies schon seit Jahren bekannte Begriffe im WiFi Umfeld bzw. beim Design performanter WLAN Netze.
"Local Breakout" gilt für alle WLAN Hersteller und ist nicht herstellerspezifisch. Sucht man nach den Begriffen im Englischen Kontext gibt es zig Treffer. Es ist also definitiv NICHT herstellerbezogen! Weiss man aber auch wenn man sich die Konzepte aller führenden WLAN Hersteller ansieht die ja diesbezüglich alle gleich sind.
Würde man dieses in einem Unternehmensnetz mit 20-50 und mehr APs alle zentral auf einen Controller tunneln muss man nicht im Detail erklären was passiert. Skalierbarkeit sieht anders aus. Da reichen auch nur 2-3 Clients pro AP um dann so ein Netz in die Knie zu zwingen.
Die Bandbreite verteilt sich keineswegs, wie auch, sondern kumuliert zentral am Controller da dort die Tunnel terminieren und der dann der zentrale Flaschenhals ist.
Bei zugünftig weiter steigenden WLAN Datenraten wäre es also ziemlicher Unsinn solche veralteten Tunnel Konzepte weiter zu verfolgen deshalb sind solche Tunneling Designs heutzutage praktisch tot und das bei allen Herstellern.
Weitere Nachteile wie den Single Point of Failure so eines Tunnel Konzeptes jetzt mal gar nicht beachtet.
Es bleibt dabei: Ein Konzept aus dem WLAN Neandertal...
Generell sollte man die APs so betreiben damit das Management Interface bzw. VLAN ohne ein zugewiesenes WLAN arbeitet. Wer will in seinem gesicherten Management VLAN ein VLAN betreiben? Aus Sicherheitsgründen ist das ein NoGo.
den Eindruck, dass Wireguard deutlich performanter ist.
Nein, das ist ein Trugschluss, denn die IPsec Durchsatzraten sind quasi identisch zu WG. IPsec IKEv2 und auch L2TP haben den großen Vorteil das man auf jeglichen Endgeräten die onboard VPN Clients benutzen kann die deutlich besser ins OS integriert sind als externe Software.Der Tunnel läuft über einen gemieteten vlan server
Auch das rennt mit IKEv2 und den onboard Clients problemlos und ist im Handumdrehen aufgesetzt:IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
noch eine Frage zur Konfiguration des IEEE 802.11r Standards
Cisco erklärt das Verfahren hier im Detail. Die Reass. Time solltest du deutlich höher wählen.https://www.cisco.com/c/de_de/support/docs/wireless-mobility/wireless-la ...
Fakt ist das auch deine Clients .11r supporten müssen ansonsten scheitert eine Assoziation mit einem .11r aktiviertem WLAN.
@DerMaddin
mir ist das Thema WLAN "local termination" nicht bekannt
Das mag sein und kann bei einem Server Administrator auch mal vorkommen. Server Profis müssen ja auch nicht unbedingt alle Netzwerk Feinheiten kennen. Dennoch sind dies schon seit Jahren bekannte Begriffe im WiFi Umfeld bzw. beim Design performanter WLAN Netze."Local Breakout" gilt für alle WLAN Hersteller und ist nicht herstellerspezifisch. Sucht man nach den Begriffen im Englischen Kontext gibt es zig Treffer. Es ist also definitiv NICHT herstellerbezogen! Weiss man aber auch wenn man sich die Konzepte aller führenden WLAN Hersteller ansieht die ja diesbezüglich alle gleich sind.
Also mehr als 10Gbps werden nicht möglich sein.
Das ist so pauschal gesagt natürlich nicht richtig. WiFi7 APs haben in der Regel durchgehend N-Base T Anschlüsse mit min. 2,5G und höher, da aktuelle WiFi Datenraten deutlich über 1G liegen und man anderweitig Bandbreite verschenken würde. Mit 2 oder 3 Radios landet man also auch deutlich über 2Gig pro AP.Würde man dieses in einem Unternehmensnetz mit 20-50 und mehr APs alle zentral auf einen Controller tunneln muss man nicht im Detail erklären was passiert. Skalierbarkeit sieht anders aus. Da reichen auch nur 2-3 Clients pro AP um dann so ein Netz in die Knie zu zwingen.
Die Bandbreite verteilt sich keineswegs, wie auch, sondern kumuliert zentral am Controller da dort die Tunnel terminieren und der dann der zentrale Flaschenhals ist.
Bei zugünftig weiter steigenden WLAN Datenraten wäre es also ziemlicher Unsinn solche veralteten Tunnel Konzepte weiter zu verfolgen deshalb sind solche Tunneling Designs heutzutage praktisch tot und das bei allen Herstellern.
Weitere Nachteile wie den Single Point of Failure so eines Tunnel Konzeptes jetzt mal gar nicht beachtet.
Es bleibt dabei: Ein Konzept aus dem WLAN Neandertal...
@aqui bitte Links zu dem "Local Breakout" Thema hier posten, ich bekomme nur "Local Breakout Internet" wenn ich danach suche
Das grundlegende Prinzip ist hier erklärt:
https://www.cisco.com/c/de_de/support/docs/wireless/catalyst-9800-series ...
Wie bereits mehrfach gesagt: Es ist nicht herstellerspezifisch sondern heisst bei anderen Herstellern nur schlicht unbd einfach anders wie z.B. local Termination bei Ruckus usw.
https://www.cisco.com/c/de_de/support/docs/wireless/catalyst-9800-series ...
Wie bereits mehrfach gesagt: Es ist nicht herstellerspezifisch sondern heisst bei anderen Herstellern nur schlicht unbd einfach anders wie z.B. local Termination bei Ruckus usw.
Moin,
nachdem ich durch das Hinzufügen der default route im Switch ein kurzzeitiges Erfolgserlebnis hatte und alles lief, ging‘s kurz darauf auch wieder nicht mehr. ☹
Die beiden vlan30 und 45 mit den Adressbereichen 172.20.30.xxx und 172.20.45.xxx erreichen die Opnsense auf der 172.20.30.1 bzw. 172.20.45.1 nicht und umgekehrt auch nicht. Jedoch funktionieren die restlichen vlans 20-55 gut. Weshalb die Acces Points ein funktionstüchtiges WLAN ausstrahlen, allerdings selbst per DHCP im vlan30 keine IP Adresse erhalten.
Die beiden vlan 30 und 45 haben als Gemeinsamkeit, dass diese über den Wireguard Tunnel erreichbar sein sollen. Deshalb vermute ich, dass hier irgendetwas nicht passt.
Die Firewall selbst ist über den VPN-Tunnel unter der 172.20.30.1 und 45.1 von außen erreichbar. Der Adressbereich des Tunnels ist im 192.168.5.xxx Netz. Wobei der externe Server auf der 5.1 und die Sense auf 5.13 liegen.
Hier die Einstellungen des Wireguard setups:
Hier müsste vermutlich die Tunneladresse auf 192.1681.5.13/32 oder 192.1681.5.1/32 geändert werden, oder?
Im Wireguard Protokoll wird auch folgender Fehler ausgegeben:
Die Firewall Regeln sind wie folgt definiert:
Bei den Firewall Regeln ist in der WireGuard (Gruppe) keine Regel manuell definiert worden.
Im WAN Port ist der Verkehr von der Public IP des Wireguard Servers über Port 58120 Richtung WAN Adresse zugelassen.
In der angelegten Schnittstelle [wg0] wird der Verkehr von 192.168.5.1/32 durchgelassen.
Im vlan30 als auch vlan45 wird der gesamte Verkehr aus dem jeweiligen Netzwerk nach außen erlaubt (any-any)
Etwas erschwert wird das ganze leider dadurch, dass ich erst nächstes Wochenende wieder physischen Zugang zum System habe...
nachdem ich durch das Hinzufügen der default route im Switch ein kurzzeitiges Erfolgserlebnis hatte und alles lief, ging‘s kurz darauf auch wieder nicht mehr. ☹
Die beiden vlan30 und 45 mit den Adressbereichen 172.20.30.xxx und 172.20.45.xxx erreichen die Opnsense auf der 172.20.30.1 bzw. 172.20.45.1 nicht und umgekehrt auch nicht. Jedoch funktionieren die restlichen vlans 20-55 gut. Weshalb die Acces Points ein funktionstüchtiges WLAN ausstrahlen, allerdings selbst per DHCP im vlan30 keine IP Adresse erhalten.
Die beiden vlan 30 und 45 haben als Gemeinsamkeit, dass diese über den Wireguard Tunnel erreichbar sein sollen. Deshalb vermute ich, dass hier irgendetwas nicht passt.
Die Firewall selbst ist über den VPN-Tunnel unter der 172.20.30.1 und 45.1 von außen erreichbar. Der Adressbereich des Tunnels ist im 192.168.5.xxx Netz. Wobei der externe Server auf der 5.1 und die Sense auf 5.13 liegen.
Hier die Einstellungen des Wireguard setups:
Hier müsste vermutlich die Tunneladresse auf 192.1681.5.13/32 oder 192.1681.5.1/32 geändert werden, oder?
Im Wireguard Protokoll wird auch folgender Fehler ausgegeben:
Die Firewall Regeln sind wie folgt definiert:
Bei den Firewall Regeln ist in der WireGuard (Gruppe) keine Regel manuell definiert worden.
Im WAN Port ist der Verkehr von der Public IP des Wireguard Servers über Port 58120 Richtung WAN Adresse zugelassen.
In der angelegten Schnittstelle [wg0] wird der Verkehr von 192.168.5.1/32 durchgelassen.
Im vlan30 als auch vlan45 wird der gesamte Verkehr aus dem jeweiligen Netzwerk nach außen erlaubt (any-any)
Etwas erschwert wird das ganze leider dadurch, dass ich erst nächstes Wochenende wieder physischen Zugang zum System habe...
erreichen die Opnsense auf der 172.20.30.1 bzw. 172.20.45.1 nicht und umgekehrt auch nicht.
Bedeutet dann das du zu 99,9% ein Layer 2 Connectivity Problem hast, also das dann dein Tagging entweder auf OPNsense Seite oder Switch Seite nicht übereinstimmt bzw. falsch konfiguriert wurde. Weshalb die Acces Points ein funktionstüchtiges WLAN ausstrahlen, allerdings selbst per DHCP im vlan30 keine IP Adresse erhalten.
Hier begehst du vermutlich einen fatalen Denkfehler?!Die APs selber bekommen niemals in einem getaggten MSSID VLAN eine IP. Sie bekommen immer nur eine einzige Management IP und das immer im Native VLAN bzw. PVID VLAN.
Es ist also essentiell wichtig auf welches PVID VLAN dein physisches AP Interface gemappt ist. Nur da bekommt der AP eine IP was auch logisch ist, da DHCP Requests natürlich immer UNtagged gesendet werden. Wenn du kein oder das falsche PVID VLAN AP konfiguriert hast bekommt der AP logischerweise auch keinerlei Management IP.
Deshalb vermute ich, dass hier irgendetwas nicht passt.
So ist es!Du solltest also strategisch vorgehen und...
- dir am CBS Switch einen UNtagged Testport jeweils für das VLAN 30 und 45 erstellen, dort einen Testclient anschliessen und checken ob der korrekt in beiden VLANs eine passende IP, Gateway und DNS vom DHCP bekommt. Pingcheck auf jeweilige Firewall IP und Internet. Das verifiziert dann wasserdicht das dein VLAN Setup zw. OPNsense und CBS Switch sauber funktioniert!
- Gleiches machst du für die PVID VLAN ID die am AP Anschlussport anliegt! Damit stellst du sicher das auch die IP Adressvergabe im ungetaggten PVID VLAN am Accesspoint Port sauber funktioniert und korrekt ist.
- Dann checkst du ob der AP Port als "Trunk" Port (nicht General) definiert ist, das korrekte PVID, Native VLAN definiert ist und 30 und 45 dort tagged konfiguriert sind.
- Ist das der Fall bekommt auch der AP im PVID VLAN eine Management IP und mapped die beiden VLAN IDs 30 und 45 auf die entsprechenden MSSID WLANs. Logischerweise mapped man aus Sicherheitsgründen keine WLAN SSID auf das Management PVID Netz um das Management nicht in einem WLAN zu exponieren und nur via Kupfer erreichbar zu haben.
Irgendwo hast du also in dem ganzen Konstrukt einen Fehler zu mindestens für das PVID VLAN und die VLAN IDs 30 und 45 begangen. Man kann hier aber nur frei kristallkugeln weil die entsprechenden Setup Screenshots fehlen um das für dich einmal auf Korrektheit zu kontrollieren.
Hilfreiche Dokus dazu findest du, wie immer, HIER (OPNsense VLAN Tagging) und HIER (Cisco MSSID Setup).
Alles Wissenswerte zu einem korrekten OPNsense Wireguard Setup findest du HIER (Wireguard Responder (Server) Setup).
HIER ist das Setup einer OPNsense im Wireguard Initiator Mode (Client) zu sehen.
Wenn du dich an all diese Setup Vorgaben genau hältst kommt das alles auch sofort zum Fliegen!
dass ich erst nächstes Wochenende wieder physischen Zugang zum System habe...
Was bekanntlich allein DEIN Problem ist! Bei der Problematik kann dir, wie du sicher selber weisst, auch das allerbeste Forum nicht helfen.Pfiffige Netzwerker würden allerdings auf der OPNsense immer ein Client VPN einrichten damit man von überall Zugriff hat. 😉
Danke für die Unterstützung!
Ich habe die beiden Fehler bei vlan30 und 45 gefunden.
Bei VLAN45 lag es an einem Schreibfehler im Adressbereich des DHCP Servers.
Bei VLAN30 hatte ich am Switch den entsprechenden Port vlan30 als native angegeben, es wurde von der Opnsense jedoch als tagged gesendet...
Jetzt scheint es zu funktionieren
Mittlerweile habe ich es auch geschafft den Aufbau zu Dokumentieren.
Fehler bzw. Verbesserungsvorschläge gerne äußern.
Die Accesspoints bekommen über den Trunkport beim Switch eine IP aus vlan30.
Es funktioniert also prinzipiell wie es soll.
Aber in der gui wird angezeigt, das Current Native VLAN = Management VLAN1 ist.
Wenn ich versuche beim AP ein VLAN30 zu erstellen und dieses lediglich als Native VLAN zu definieren, erhalte ich die Fehlermeldung das einem VLAN auch ein Radio zugeordnet werden müsse. Genau das möchte ich allerdings nicht. XD
Stellt es ein Problem dar, wenn ich bei den Accespoints VLAN1 als native belasse? Oder hat jemand einen Konsolenbefehl der das Umsetzen würde?
liebe Grüße Ben
Ich habe die beiden Fehler bei vlan30 und 45 gefunden.
Bei VLAN45 lag es an einem Schreibfehler im Adressbereich des DHCP Servers.
Bei VLAN30 hatte ich am Switch den entsprechenden Port vlan30 als native angegeben, es wurde von der Opnsense jedoch als tagged gesendet...
Jetzt scheint es zu funktionieren
Mittlerweile habe ich es auch geschafft den Aufbau zu Dokumentieren.
Fehler bzw. Verbesserungsvorschläge gerne äußern.
Ist das der Fall bekommt auch der AP im PVID VLAN eine Management IP und mapped die beiden VLAN IDs 30 und 45 auf die entsprechenden MSSID WLANs. Logischerweise mapped man aus Sicherheitsgründen keine WLAN SSID auf das Management PVID Netz um das Management nicht in einem WLAN zu exponieren und nur via Kupfer erreichbar zu haben.
Die Accesspoints bekommen über den Trunkport beim Switch eine IP aus vlan30.
Es funktioniert also prinzipiell wie es soll.
Aber in der gui wird angezeigt, das Current Native VLAN = Management VLAN1 ist.
Wenn ich versuche beim AP ein VLAN30 zu erstellen und dieses lediglich als Native VLAN zu definieren, erhalte ich die Fehlermeldung das einem VLAN auch ein Radio zugeordnet werden müsse. Genau das möchte ich allerdings nicht. XD
Stellt es ein Problem dar, wenn ich bei den Accespoints VLAN1 als native belasse? Oder hat jemand einen Konsolenbefehl der das Umsetzen würde?
Die Reass. Time solltest du deutlich höher wählen.
Ich habe im Netz leider keine sinnvollen Anhaltswerte gefunden. Spricht etwas dagegen den Maximalwert von 1200ms zu verwenden?liebe Grüße Ben
Jetzt scheint es zu funktionieren
👍habe ich es auch geschafft den Aufbau zu Dokumentieren.
Alles richtig gemacht!👍
Die Accesspoints bekommen über den Trunkport beim Switch eine IP aus vlan30.
Ist korrekt, wenn das dein Management VLAN ist. Auf dem Mamnagement sollte tunlichst kein aktives WLAN (MSSID) liegen! (Security!)Aber in der gui wird angezeigt, das Current Native VLAN = Management VLAN1 ist.
Ja, das ist ja mehr oder minder normal. Das native VLAN was in der Regel im Default VLAN 1 liegt sendet ja (da es ja native bzw. PVID VLAN ist) keinerlei VLAN Informationen. Die VLAN ID dort gibt ja lediglich an in welches VLAN UNgetaggter Traffic ohne jegliche VLAN Information geforwarted wird.Wenn du nun also am AP Switchport PVID 30 gesetzt hast landet das auf der anderen Seite im VLAN 1 weil dort das Management Interface hingemappt ist. Die Endgeräte merken von diesem kleinen und kosmetischen Widerspruch nichts da diese Traffic ja keinerlei VLAN Information im Paket trägt wie es z.B. mit dem 802.1q Header bei tagged Frames der Fall ist. (Siehe auch hier in der VLAN Schnellschulung)
Wenn du also mit diesem kleinen kosmetischen "Fehler" leben kannst lass es so. Man könnte es auch auf AP Seite umbauen so das es wieder "passt" was aber deine Konfig unnötig aufblähen würde und außer der Kosmetik keinerlei Vorteile hätte.
Also klare Antwort auf deine Frage:
Nein. Es stellt natürlich kein Problem dar, wenn du bei den Accespoints VLAN1 als native belässt!
Ich habe im Netz leider keine sinnvollen Anhaltswerte gefunden.
Doch die gibt es aber in einem sehr weit gefassten Bereich. Ideal sind mittlere Wert in der vorgegebenen Spanne. Die 300 ist schon ok, kann aber auch 600 sein. Die harten minimal oder maximal Werte sollte man besser meiden.
Wenn es das denn nun war bitte deinen Thread dann hier auch als erledigt schliessen!
How can I mark a post as solved?
How can I mark a post as solved?