ben0505
Goto Top

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

Content-ID: 93152101949

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

Printed on: October 6, 2024 at 19:10 o'clock

Headcrach
Headcrach May 23, 2024 at 04:45:35 (UTC)
Goto Top
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ß
em-pie
em-pie May 23, 2024 at 05:03:41 (UTC)
Goto Top
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.
ThePinky777
ThePinky777 May 23, 2024 at 06:18:59 (UTC)
Goto Top
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.
Visucius
Visucius May 23, 2024 at 07:39:38 (UTC)
Goto Top
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
Reinartz
Reinartz May 23, 2024 at 08:55:50 (UTC)
Goto Top
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
aqui
aqui May 23, 2024 updated at 09:19:23 (UTC)
Goto Top
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. face-sad (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.
ben0505
ben0505 May 23, 2024 at 09:29:58 (UTC)
Goto Top
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?
aqui
aqui May 23, 2024 updated at 09:51:11 (UTC)
Goto Top
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.
mgmt
(172.20.30.1 ist hier "geraten" die IP Adresse der OPNsense im Management VLAN 30)

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
Headcrach
Headcrach May 23, 2024 at 09:45:32 (UTC)
Goto Top
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

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ß
DerMaddin
DerMaddin May 23, 2024 at 11:10:36 (UTC)
Goto Top
@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.
Ueba3ba
Ueba3ba May 23, 2024 at 13:09:44 (UTC)
Goto Top
Zitat von @DerMaddin:

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?
aqui
aqui May 23, 2024 updated at 19:26:05 (UTC)
Goto Top
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.
ben0505
ben0505 May 23, 2024 updated at 22:15:43 (UTC)
Goto Top
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.

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.
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.
configuration per gui

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-air
in der Gui sieht das darauf hin m.M. so aus:
config ap2702 11r configuration

Beim prüfen der SSID Einstellungen ist mir aufgefallen, dass man dot11r auch im Key Management konfigurieren kann. Siehe "WPAv2 dot11r"
config ssid ap2702
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
Headcrach
Headcrach May 24, 2024 at 09:25:31 (UTC)
Goto Top
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.

vlan membership

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ß
DerMaddin
DerMaddin May 24, 2024 at 10:09:45 (UTC)
Goto Top
@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.
Headcrach
Headcrach May 24, 2024 at 11:44:59 (UTC)
Goto Top
@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ß
ben0505
ben0505 May 24, 2024 at 12:28:15 (UTC)
Goto Top
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.
aqui
aqui May 24, 2024 updated at 12:38:24 (UTC)
Goto Top
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.

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. face-wink 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...
DerMaddin
DerMaddin May 27, 2024 at 05:46:47 (UTC)
Goto Top
@aqui bitte Links zu dem "Local Breakout" Thema hier posten, ich bekomme nur "Local Breakout Internet" wenn ich danach suche
aqui
aqui May 27, 2024 at 08:46:38 (UTC)
Goto Top
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.
ben0505
ben0505 Jun 01, 2024 at 11:41:13 (UTC)
Goto Top
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?
config instance

config peer

Im Wireguard Protokoll wird auch folgender Fehler ausgegeben:
wireguard fehler meldung

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...
aqui
Solution aqui Jun 01, 2024 updated at 13:40:16 (UTC)
Goto Top
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. face-sad
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. face-sad
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. 😉
ben0505
ben0505 Jun 06, 2024 updated at 21:06:42 (UTC)
Goto Top
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 face-smile

Mittlerweile habe ich es auch geschafft den Aufbau zu Dokumentieren.
Fehler bzw. Verbesserungsvorschläge gerne äußern.
netzwerkaufbau


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?

confic accesspoint
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
aqui
aqui Jun 07, 2024 updated at 13:33:55 (UTC)
Goto Top
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.
aqui
aqui Jun 14, 2024 at 13:08:08 (UTC)
Goto Top
Wenn es das denn nun war bitte deinen Thread dann hier auch als erledigt schliessen!
How can I mark a post as solved?