OPNsense - VLAN will mit nachgeschaltetem Switch nicht funktionieren
Hallochen Gemeinde,
folgende vorhandene Konstellation:
Lokales AD-Netzwerk an zwei Standorten mit OPNsense als jeweiligem Router. Die OPNsense erledigt das netzwerkweite Routing einschließlich VLAN. Für zwei Fremdrechner von Kunden ist (nunmehr) ein eigenes VLAN eingerichtet worden. Die Konfiguration der beiden OPNsensen ist insoweit identisch.
An dem einen Standort funktioniert die VLAN-Separierung von der OPNsense über einen 24er Switch und danach einem Zyxel GS1200-8 auf Anhieb und problemfrei.
An dem zweiten Standort ist der OPNsense nur ein Zyxel GS1200-8HP nachgeschaltet. Stelle ich dort die VLAN-Konfiguration auf irgendeine VLAN-ID scharf, sehe ich im Live-Kino der OPNsense zwar den vom Fremdrechner kommenden Verkehr. Aber es gibt ganz offensichtlich keinen Rückverkehr.
Realisiere ich hingegen die logische Netzwerktrennung nicht über das VLAN, sondern füge stattdessen der LAN-Schnittstelle der OPNsense den betreffenden VLAN-IP-Bereich als weiteren Netzwerkbereich hinzu (mittels virtueller IP-Adresse) und belasse auf dem Switch alles auf der VLAN-ID 1, so klappt alles hervorragend.
Es spielt übrigens keinerlei Rolle, mit welcher VLAN-ID und welchem an dem Switch angeschlossenem Gerät das Ganze versucht wird, weil sich übergreifend das Problem jederzeit identisch rekonstruieren und "beseitigen" lässt.
Woran kann diese Kuriosität am zweiten Standort liegen?
Meine Vermutung / Erklärung ist, dass der GS1200-8HP (noch die Version 1) zwar grundsätzlich ordnungsgemäß läuft, aber bei der VLAN-Konfiguration aus irgendeinem Grund nicht mitspielt. Denn ich habe verschiedene Ansätze durchgespielt und kann im Ergebnis dessen - gerade auch mit Blick auf den anderen funktionierenden Standort - sagen, dass nur der Switch als Ursache in Betracht kommen kann.
Hat jemand schon ähnliche Erfahrungen mit einem Switch gemacht? Gibt es einen Lösungsansatz, ohne den Switch physisch auszutauschen zu müssen?
Gibt es eine passende Custom Firmware für diesen Switch (ähnlich OpenWRT für Router)? Auf den ersten Blick habe ich (noch) nichts finden können.
Vielen Dank im Voraus für Euren Input und viele Grüße
HansDampf06
folgende vorhandene Konstellation:
Lokales AD-Netzwerk an zwei Standorten mit OPNsense als jeweiligem Router. Die OPNsense erledigt das netzwerkweite Routing einschließlich VLAN. Für zwei Fremdrechner von Kunden ist (nunmehr) ein eigenes VLAN eingerichtet worden. Die Konfiguration der beiden OPNsensen ist insoweit identisch.
An dem einen Standort funktioniert die VLAN-Separierung von der OPNsense über einen 24er Switch und danach einem Zyxel GS1200-8 auf Anhieb und problemfrei.
An dem zweiten Standort ist der OPNsense nur ein Zyxel GS1200-8HP nachgeschaltet. Stelle ich dort die VLAN-Konfiguration auf irgendeine VLAN-ID scharf, sehe ich im Live-Kino der OPNsense zwar den vom Fremdrechner kommenden Verkehr. Aber es gibt ganz offensichtlich keinen Rückverkehr.
Realisiere ich hingegen die logische Netzwerktrennung nicht über das VLAN, sondern füge stattdessen der LAN-Schnittstelle der OPNsense den betreffenden VLAN-IP-Bereich als weiteren Netzwerkbereich hinzu (mittels virtueller IP-Adresse) und belasse auf dem Switch alles auf der VLAN-ID 1, so klappt alles hervorragend.
Es spielt übrigens keinerlei Rolle, mit welcher VLAN-ID und welchem an dem Switch angeschlossenem Gerät das Ganze versucht wird, weil sich übergreifend das Problem jederzeit identisch rekonstruieren und "beseitigen" lässt.
Woran kann diese Kuriosität am zweiten Standort liegen?
Meine Vermutung / Erklärung ist, dass der GS1200-8HP (noch die Version 1) zwar grundsätzlich ordnungsgemäß läuft, aber bei der VLAN-Konfiguration aus irgendeinem Grund nicht mitspielt. Denn ich habe verschiedene Ansätze durchgespielt und kann im Ergebnis dessen - gerade auch mit Blick auf den anderen funktionierenden Standort - sagen, dass nur der Switch als Ursache in Betracht kommen kann.
Hat jemand schon ähnliche Erfahrungen mit einem Switch gemacht? Gibt es einen Lösungsansatz, ohne den Switch physisch auszutauschen zu müssen?
Gibt es eine passende Custom Firmware für diesen Switch (ähnlich OpenWRT für Router)? Auf den ersten Blick habe ich (noch) nichts finden können.
Vielen Dank im Voraus für Euren Input und viele Grüße
HansDampf06
Please also mark the comments that contributed to the solution of the article
Content-ID: 668514
Url: https://administrator.de/contentid/668514
Printed on: October 15, 2024 at 07:10 o'clock
19 Comments
Latest comment
Das Setup des GS-1200 Switches ist eigentlich immer identisch! HIER ist das genaue Prozedere beschrieben an der OPNsense.
Wichtig ist immer das man dort nicht benutzte Memberports ausgraut. Aktuelle Switch Firmware sollte auch drauf sein.
Der Fehler liegt ja da ganz klar im VLAN Setup. Screenshot wäre hier hilfreich gewesen!
Im Zweifel einen Werksreset mit aktueller Firmware und nochmal in Ruhe von vorne anfangen. Solche groben Fehlfunktionen liegen in der Regel nicht am Switch selber sondern am Setup.
Wichtig ist immer das man dort nicht benutzte Memberports ausgraut. Aktuelle Switch Firmware sollte auch drauf sein.
Der Fehler liegt ja da ganz klar im VLAN Setup. Screenshot wäre hier hilfreich gewesen!
Im Zweifel einen Werksreset mit aktueller Firmware und nochmal in Ruhe von vorne anfangen. Solche groben Fehlfunktionen liegen in der Regel nicht am Switch selber sondern am Setup.
Ich habe leider keinen unbenutzten VLAN-Switch herumliegen.
Was du ohne Vergleichsswitch immer machen kannst zur sicheren Kontrolle ist einen Wireshark....- einmal direkt an das OPNsense Interface klemmen wo der der Zyxel dranhängt
- und einmal direkt am Zyxel Uplink Port anschliessen der zur OPNsense geht.
Analog machst du das am Zyxel Switch Uplink Port.
So kannst du wenigstens im Wireshark sehen ob beide Seiten den betreffenden Traffic entsprechend richtig mit einem .1q VLAN Tag taggen.
Hier am Beispiel mit einem VLAN ID 14 Tag:
Das bei so einer grundlegenden Funktion wie VLANs ein managed Switch einen Fehler hat ist eher ungewöhnlich.
Als letzte Option solltest du immer einen Werksreset am Switch machen und erstmal einfach mit dem PVID und nur einem tagged VLAN anfangen. Switch VLAN Konfig Screenshot würde auch helfen.
Glückwunsch zum bilderbuchmäßigen Troubleshooting und interessantem Feedback! 👏 👍
Bleibt zum Schluß nur noch die Frage auf welchen vSwitch bzw. Hypervisor sich das bezieht?!
Bei Proxmox oder VmWare ist dem glücklicherweise nicht so. Dort entscheidet der vSwitch welcher Tag einer VM mitgegeben wird. Bei VmWare könnte man über die VLAN ID 4095 auch alles Getaggte transparent "durchreichen".
Aus Sicherheitsgründen und der Gefahr nicht abschätzen zu können wie ein vSwitch mit Promiscous Traffic umgeht ist davon aber dringenst abzuraten. Das macht niemand so.
Zu den VLAN spezifischen Setups für Proxmox und VmWare gibt es ein paar Forenthreads.
Proxmox. Desweiteren hier.
VmWare
Bleibt zum Schluß nur noch die Frage auf welchen vSwitch bzw. Hypervisor sich das bezieht?!
Bei Proxmox oder VmWare ist dem glücklicherweise nicht so. Dort entscheidet der vSwitch welcher Tag einer VM mitgegeben wird. Bei VmWare könnte man über die VLAN ID 4095 auch alles Getaggte transparent "durchreichen".
Aus Sicherheitsgründen und der Gefahr nicht abschätzen zu können wie ein vSwitch mit Promiscous Traffic umgeht ist davon aber dringenst abzuraten. Das macht niemand so.
Zu den VLAN spezifischen Setups für Proxmox und VmWare gibt es ein paar Forenthreads.
Proxmox. Desweiteren hier.
VmWare
Denn nun konnte sich plötzlich ein Gerät, dass keinem VLAN-Bereich zugeordnet ist, seine IP-Adresse nicht mehr per DHCP zuweisen lassen
Bedeutet ja dann das das PVID VLAN entweder vom vSwitch oder vom Zyxel nicht übertragen wird. Den Zyxel wird man hier sicher ausschliessen können, denn das funktioniert mit dem fehlerfrei. Natürlich sofern man das richtig konfiguriert. Ist also zu vermuten das der vSwitch entweder kein PVID VLAN supportet oder sonstwas falsch macht.Solche mehr als banale Funktionen einen 802.1q Tag an einem Ethernet Frame zu erkennen (oder eben auch keinen) kann jede billige Baumarkt VLAN Switch.
Proxmox basiert ja auch auf diesem Hypervisor und das rennt nachweislich fehlerlos hier mit einem GS1200. Wäre dann etwas unverständlich was das geheime Zusammenspiel mit OVS dann technisch bedeutet. Übrigens werkelt der GS1200 auch völlig problemlos mit einer auf Proxmox virtualisierten OPNsense und das auf einem NUC mit nur einem einzigen Ethernetport!
Geht ja letztlich nur um Tag erkennen oder nicht. Warum es mit der anderen Kiste dann klappt ist aber genauso mysteriös und wirft eher ein Schatten auf den vSwitch.
wie Proxmox den OVS jungfräulich konfiguriert.
Ich habe das bis dato nur im KlickiBunti GUI gesehen und da ist es ein einfacher Switch ohne VLAN Support. Getaggte Frames werden also geblockt.In der Grundversion hängen damit dann Management und alle VMs in einer Layer 2 Domain.
Erst wenn man dem vSwitch aktiv im Setup sagt er soll VLANs verstehen behandelt er auch Tags korrekt. Dazu muss man den Haken "VLAN aware" setzen!
Dieser Thread zeigt das am vSwitch Setup.
Man müsste also mal ergründen wie das in einer CLI Konfig aussieht.
Bei deiner Bonding Schnittstelle ist die Frage wie die agiert?? Bonding ist ja recht vielfältig und der Netzwerker versteht da primär immer einen LACP LAG mit 802.3ad. Der GS1200 ist gar nicht LAG fähig weil er das Feature gar nicht supportet!
Das muss es bei Hypervisoren aber nicht immer sein, da es hier auch andere proprietäre, non lege artis Bonding Verfahren gibt. Besonders solche die auch bei ungemanagten Switches funktionieren.
Da wird es dann wieder spannend ob ein Switch mit sowas umgehen kann. Der GS1200 kann
Ganz spannend wäre dann noch die Frage: Wie sieht es mit einem singulären Port aus ohne Bonding?? Da wären Loop Fehler die aus solchen Bonding Setups resultieren könnten per se ausgeschlossen.
Es könnte also primär etwas mit dem Bonding Verfahren zu tun haben und wie das mit einem so einfachen VLAN Switch interagiert.
bei der bond-Schnittstelle eigentlich belanglos sein, ob dort ebenfalls der Parameter "tag=1" gesetzt ist oder nicht
Richtig!Das wäre sogar grundfalsch so einen Tag zu setzen wenn das gleiche VLAN auch PVID VLAN ist. Denn ein VLAN 1 oder generell ein VLAN kann bekanntlich niemals gleichzeitg Tagged und UNtagged sein an einem Port. Keinesfalls darf man ein PVID VLAN gleichzeitig taggen. Auf Switches verbieten das in der Regel schon die Kommando Parser.
Im Vergleich hierzu einmal ein ESXi Setup auch ohne Bonding. Hier ist der vSwitch immer Tagging fähig und man löst das da über Port Groups.
Was die GS1200er Serie definitiv nicht kann, eine MAC-basierte VLAN-Zuordnung.
Das ist richtig und wäre bei der Preisrange in dem sich diese Hardware bewegt wohl sicher auch etwas zuviel verlangt. Obwohl ein einfacher 20€ Mikrotik Switch es dennoch dafür leistet. Die hiesigen Tests verrichtete ein GS1200-5 der keinerlei Versionen kennt. Auf dem Typenschild ist diesbezüglich nichts aufgedruckt.
Der Switch arbeitet mit deaktivierter Port Isolation, deaktivierer Strom Control aber aktivierter Loop Protection. Letzteres ist sowas wie das "Spanning Tree des kleinen Mannes" bei dem der Switch auf selbst gesendete Loop Protection Frames achtet an seinen Ports. Empfängt er die blockt er den Port. IGMP Snooping ist aktiv.
Auf OPNsense und Proxmox sind 3 VLANs aktiv wobei UNtagged Frames am Trunkport 5 im VLAN 1 landen.
Mit den Settings arbeitet zu mindestens dieser Switch der o.a Hardware in allen Testumgebungen absolut unauffällig.
Die Aussage von oben muss ich korrigieren: Natürlich supportet der GS1200 auch LACP LAGs. Der 5er Switch aber nur limitiert einen 2er LAG und nur auf den Ports 3 und 4. Ob der 8er da flexibler ist kann ich nicht sagen. Der LAG rennt getestet zu einer OPNsense, Cisco Catalyst 2960 und Ruckus ICX7150 völlig unauffällig. Proxmox kann ich in Ermangelung einer weiteren Ethernet Schnittstelle (NUC Server) nicht testen.
Die Kardinalsfrage ist also dann welches Bonding Verfahren? LACP LAG kein Problem aber alles andere was nicht Standard konform ist birgt ohne Loop Detection ein Risiko. Bzw. mit aktiver Loop Detection auch sollten die vom Bonding Device auf der anderen Seite (vSwitch) geforwardet werden und damit dann ein Port Blocking auslösen. Ggf. müsste an dann testweise mal die Loop Detection deaktivieren. LACP LAG bringt ein eigenes Verfahren mit.
Zusätzlich supportet der GS1200 auch ein Port Mirroring.
Bisher ist auf den Switchen nur ein statisches LAG eingerichtet.
Aber dann auch auf Basis von 802.3ad bei dem dann nur der LACP Teil fehlt, oder?So gut wie alle Hersteller supporten keine weitere Option beim Bondig. Ausnahme vielleicht noch Cisco mit seinem älteren PaGP Protokoll was aber wie ggf. andere Verfahren immer proprietär sind und niemals mit anderen Geräten zusammenarbeit.
Es ist generell niemals eine gute Idee Link Aggregation mit statischen LAGs laufen zu lassen weil dann immer die Funktionskontrolle fehlt. Auch wenn der Switch so ein statisches Feature supportet. LACP ist da immer die bessere Wahl allein auch schon wegen der protokollinternen Loop Detection.