17
Miktrotik VLAN - trunk shared (Uplink Internet VLAN + Internal VLAN)
Hallo
Ich habe jedes auffindbare Turorial gelesen, komme aber nicht dahinter wie ich meinen Usecase abbilden kann.
Darunter natürlich auch das Turorial Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Mein Aufbau:
- VLAN ID 200 (INSIDE)... internes Netzwerk zurück zum Switch "A", um dort weiter genutzt zu werden. (der Switch steht in einem anderen Raum wie der Mikrotik und es gibt nur ein NW-Kabel)
Vorhaben:
Gegenwärte Konfig
Entweder habe ich
Jede Hilfe ist sehr willkommen. Entweder ich habe durch die unzähligen Konfigurationsversuche mich zu sehr verlaufen und sehe den Wald vor lauter Bäume nicht mehr, oder es gibt noch ein Geheimnis und ist mir unbekannt...
Danke &
Gruß
Ich habe jedes auffindbare Turorial gelesen, komme aber nicht dahinter wie ich meinen Usecase abbilden kann.
Darunter natürlich auch das Turorial Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Mein Aufbau:
- Fritzbox als Modem und Firewall + NAT Router ins Internet
- an der FB hängt ein Switch "A" (Switch Port 1)
- Switch Port 2 ist mit Mikrotik Eth1 verbunden. Dies ist ein Trunk mit folgenden 2 VLANs
- VLAN ID 200 (INSIDE)... internes Netzwerk zurück zum Switch "A", um dort weiter genutzt zu werden. (der Switch steht in einem anderen Raum wie der Mikrotik und es gibt nur ein NW-Kabel)
- Hinter dem Eth1 (Uplink Port des MT) ist die Firewall des MT aktiv, zusätzlich zur Frizbox Firewall. (Die äussere Firewall der Fritzbox ist bei mir für IPv6 Traffic nicht aktiv). Zudem ist da ein DHCP Client, um von der FB die IP/Route zu holen
- Mikrotik ist ein hAPac2 mit 6.46.4, Switch ist ein TP Link 105E v1
- IPv6 auf MT ist aktiviert (eigentlich wollte ich am Anfang nur das aktivieren, um einigen Geräten eine fixe IPv6 zu geben .... dann Firmware Upgrade .... )
- Am ETH4 des Switch hängt ein anderer Router. Der macht 50 Meter weiter ein lokales WLAN. Er selbst hat neben WLAN keinerlei aktivierte Funktion wie Routing, NAT oder Firewall...
Vorhaben:
- Ursprünglich hatte ich eine alte MT Firmware (master-port ...), jetzt wollte ich das richtig machen (Thema "STP") und das VLAN nicht an den Eth-ports anhängen, sondern auf der Bridge
- Habe unzählige Stunden damit verbracht, eine insgesamt sinnvolle aber auch überhaupt technisch funktionierende Lösung zu finden. Bisher mäßiger Erfolg.
Gegenwärte Konfig
Entweder habe ich
- Sichtbaren WAN (200) Traffic auf Switch Eth3 zum PC. Im Moment hängt ja auch ETH1 de MT an der Bridge (!!), aber sonst bekomme ich gar kein Traffic ins 200er zurück zum Switch
- irgendwelche Loops im Netz
- oder der PC am ETH3 des Swtich bekommt keine IP vom DHCP Mikrotik
- hänge ich den VLAN Port inside200 von der Bridge weg und direkt an ETH1, dann kann ich keinen DHCP Server auf dieses Interface hängen. Der Router an ETH4 des Switch A sollte sich die IP, GW und Route vom Mikrotik holen.
Jede Hilfe ist sehr willkommen. Entweder ich habe durch die unzähligen Konfigurationsversuche mich zu sehr verlaufen und sehe den Wald vor lauter Bäume nicht mehr, oder es gibt noch ein Geheimnis und ist mir unbekannt...
Danke &
Gruß
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: 564027
Url: https://administrator.de/contentid/564027
Printed on: April 24, 2024 at 01:04 o'clock
17 Comments
Latest comment
Bevor wir ins Eingemachte gehen ein paar Fragen die etwas unklar sind:
Was die Gateway IP der FritzBox anbetrifft solltest du dort die Mac Adresse des MT L3 Ports "vlan100" eintragen, das der MT immer eine feste IP bekommt. Ansonsten könnte es später Probleme beim Port Forwarding oder VPNs geben sofern du sowas planst.
Ansonsten wäre das Konzept so technisch problemlos umsetzbar.
Leider fehlen ein Screenshot des VLAN Switch Setups und der MT mit dem Bridge Member Ports um zu kontrollieren ob ggf. da Fehler gemacht wurden. Kannst du die ggf. noch posten ?
- 1. Was bezeichnet das VLAN ID 100 (WAN) ?? Ist das das Koppelnetz zwischen WAN Port (L3 MT Interface vlan100) und der FritzBox oder was soll das sein ?
- 2. Was genau ist das VLAN ID 200 (INSIDE) ?? Ist das das lokale LAN am Mikrotik ?
- 3. Warum gibt es am Mikrotik ein "VLAN1" Interface mit IP obwohl dieses Netz nirgendwo benutzt wird ? Was ist der Sinn dahinter ?
- 4. Warum ist die Firewall und NAT am MT L3 Port vlan100 hier aktiv ? Gilt es das lokale LAN (VLAN 200) dort abzutrennen und zu sichern vor dem Koppelnetz VLAN 100 ?
- 5. Der Router an Switchport 4 ist der als stinknormaler, dummer Layer 2 WLAN AP konfiguriert wie es HIER genau beschrieben ist ?
Was die Gateway IP der FritzBox anbetrifft solltest du dort die Mac Adresse des MT L3 Ports "vlan100" eintragen, das der MT immer eine feste IP bekommt. Ansonsten könnte es später Probleme beim Port Forwarding oder VPNs geben sofern du sowas planst.
Ansonsten wäre das Konzept so technisch problemlos umsetzbar.
Leider fehlen ein Screenshot des VLAN Switch Setups und der MT mit dem Bridge Member Ports um zu kontrollieren ob ggf. da Fehler gemacht wurden. Kannst du die ggf. noch posten ?
Hi
1)
VLAN 100 habe ich definiert, um dem MT den Internet Zugang als Uplink zur Verfügung zu stellen. Die Fritzbox verwende ich eigentlich nur als Modemzugang. Und jetzt im Moment halt auch noch als 1. Firewall, weil ich mit den VLANs noch nicht fertig bin / denen traue.
2)
Das VLAN 200 ist das interne Netz, ja.
3) Das VLAN 1 habe ich nur mal was ausprobiert. Verwende ich nicht. Das habe ich aus deiner Anleitung einfach "sicherheitshalber" nachgebaut.
4) Die Firewall des MT ist DIE Firewall in meinem Konzept. These: Traue dem Frizbox Netz nicht. IPv6 Netz wird später ohnehin durchgegeben.
Also ja, genau wie du vermutet hast.
5) Fast genau so
Ich denke, mit dem komme ich dann klar, sobald das der Port 3 am Switch richtig funktioniert.
Aber:
Dieser Router hat selbst keinen DHCP (er holt sich das Netz vom MT) und auch keine Firewall. Angeschlossen sind dort ein weiterer PC und WLAN Clients mit anderer SSID.
Bis gestern hatte ich am MT das lokale Netz 192.168.1.0/24 wobei der MT davon .1 hatte und dieser Router .2
Den Zugriff auf den DHCP Server der MT Bridge (kein VLAN) vom Switchport 3 aus habe ich aber nicht hinbekommen.
Dann hatte ich das VLAN 200 mit einem 2. eigenen DHCP Server machen müssen und da das Netz 192.168.2.0/24 hinterlegt. Per DHCP den DNS Server trotzdem auf 192.168.1.1, was auch funktioniert wie es soll. Ich musste dann aber auf dem MT eh alles ins VLAN200 holen, damit jeder Client mit jedem anderen konnte. Also ist derzeit das interne Hauptnetz 192.168.2.0/24,
Eigentlich wollte ich ursprünglch nur für das Kabel zwischen Switch und Mikrotik "zweifach" verwenden.
- WAN Traffic (alles vor dem MT wird von mir als WAN angesehen)
- Interner LAN Traffic, weil am Switch noch ein NAS und eben dieser "Sub"-Router für entfernten AP (und noch ein PC an dessen LAN Port) hängt.
Damit ich jetzt rumprobieren kann, habe ich derzeit den 2. Router einfach an der Fritzbox hängen (dort holt er sich per DHCP ne Addresse und geht direkt ins Inet. Also teste ich jetzt mit einem Test PC an Port 3 des Switches, ob mein VLAN 200 so funktioniert wie es soll. Und wenn ich dort sniffe, sehe ich eben auch WAN Traffic (weil vermutlich ETH1 des MT auch auf der Bridge hängt, was ich aber nicht ändern kann, weil sonst gar nix geht)
Sonst:
Klar, an der FB habe ich die MAC auf die IP fixiert.
Fehlende Screenshots:
Switch - Mapping und PVID Settings
MT mit dem Bridge Member Ports - hatte ich doch als Sreenshot (/interface bridge port print value-list) eingefügt, dort sieht man gleich alles auf einmal? Aber hier noch aus dem UI heraus:
Danke &
Gruss
1)
VLAN 100 habe ich definiert, um dem MT den Internet Zugang als Uplink zur Verfügung zu stellen. Die Fritzbox verwende ich eigentlich nur als Modemzugang. Und jetzt im Moment halt auch noch als 1. Firewall, weil ich mit den VLANs noch nicht fertig bin / denen traue.
2)
Das VLAN 200 ist das interne Netz, ja.
3) Das VLAN 1 habe ich nur mal was ausprobiert. Verwende ich nicht. Das habe ich aus deiner Anleitung einfach "sicherheitshalber" nachgebaut.
4) Die Firewall des MT ist DIE Firewall in meinem Konzept. These: Traue dem Frizbox Netz nicht. IPv6 Netz wird später ohnehin durchgegeben.
Also ja, genau wie du vermutet hast.
5) Fast genau so
Ich denke, mit dem komme ich dann klar, sobald das der Port 3 am Switch richtig funktioniert.Aber:
Dieser Router hat selbst keinen DHCP (er holt sich das Netz vom MT) und auch keine Firewall. Angeschlossen sind dort ein weiterer PC und WLAN Clients mit anderer SSID.
Bis gestern hatte ich am MT das lokale Netz 192.168.1.0/24 wobei der MT davon .1 hatte und dieser Router .2
Den Zugriff auf den DHCP Server der MT Bridge (kein VLAN) vom Switchport 3 aus habe ich aber nicht hinbekommen.
Dann hatte ich das VLAN 200 mit einem 2. eigenen DHCP Server machen müssen und da das Netz 192.168.2.0/24 hinterlegt. Per DHCP den DNS Server trotzdem auf 192.168.1.1, was auch funktioniert wie es soll. Ich musste dann aber auf dem MT eh alles ins VLAN200 holen, damit jeder Client mit jedem anderen konnte. Also ist derzeit das interne Hauptnetz 192.168.2.0/24,
Eigentlich wollte ich ursprünglch nur für das Kabel zwischen Switch und Mikrotik "zweifach" verwenden.
- WAN Traffic (alles vor dem MT wird von mir als WAN angesehen)
- Interner LAN Traffic, weil am Switch noch ein NAS und eben dieser "Sub"-Router für entfernten AP (und noch ein PC an dessen LAN Port) hängt.
Damit ich jetzt rumprobieren kann, habe ich derzeit den 2. Router einfach an der Fritzbox hängen (dort holt er sich per DHCP ne Addresse und geht direkt ins Inet. Also teste ich jetzt mit einem Test PC an Port 3 des Switches, ob mein VLAN 200 so funktioniert wie es soll. Und wenn ich dort sniffe, sehe ich eben auch WAN Traffic (weil vermutlich ETH1 des MT auch auf der Bridge hängt, was ich aber nicht ändern kann, weil sonst gar nix geht)
Sonst:
Klar, an der FB habe ich die MAC auf die IP fixiert.
Fehlende Screenshots:
Switch - Mapping und PVID Settings
MT mit dem Bridge Member Ports - hatte ich doch als Sreenshot (/interface bridge port print value-list) eingefügt, dort sieht man gleich alles auf einmal? Aber hier noch aus dem UI heraus:
Danke &
Gruss
Kurzer Laboraufbau mit deinen Settings funktioniert völlig problemos und absolut sauber ohne irgendwelche Loops usw.
Aktivieren des 802.1q VLAN Standards auf dem TP-Link und Setzen der Tagged/Untagged Ports:
Port PVIDs setzen:
Du hast übrigens vergessen das VLAN 1 auf den Ports 1,3,4 und 5 dort als not member zu setzen !
Port 5 hier als Testport für das Transfer Netz VLAN100 zur FritzBox.
eth3 Port Settings gelten analog auch für die Ports eth4-5.
IP Interfaces müssen nicht zwingend als Bridge Member Ports eingetragen sein.
Untagged Ports müssen hier nicht eingetragen werden da durch das PVID Setting von oben festgelegt.
Fertisch !
Ping Checks lokal und nach Eintragen der statischen Route für das VLAN 200 IP Netz auf der FritzBox ins Internet fehlerfrei !
Die hiesige Beispiel Konfig macht kein NAT und hat aktuelle keine Firewall aktiv auf dem vlan200 Interface.
Das ist erstmal ein Grundgerüst um die grundlegende Funktion einzurichten und zu checken das diese wasserdicht rennt. Firewalling kommt immer danach.
Hier müsstest du dann noch die Firewall aktivieren bzw. entsprechend customizen. Die Regeln dazu kannst du dir der Einfachheit halber aus der Default Konfig abschauen und übernehmen !
NAT/Masquerading solltest du nicht aktivieren, denn das schafft wieder zusätzliche Probleme und frisst unnötig Performance. Da die FB ja statische Routen supportet ist ist NAT nicht zwingend. Firewall only reicht da.
Fazit:
Works as designed !!
1.) Switch Settings TP-Link SG105E:
Aktivieren des 802.1q VLAN Standards auf dem TP-Link und Setzen der Tagged/Untagged Ports:Port 5 hier als Testport für das Transfer Netz VLAN100 zur FritzBox.
2.) Mikrotik VLAN IP Interfaces konfigurieren:
3.) Mikrotik IP Adressierung konfigurieren:
- vlan100 WAN Interface = DHCP Client ("D" Index)
- vlan200 LAN Interface = Statisch und DHCP Server Pool dazu
- DNS Proxy aktiviert
4.) Mikrotik Bridge, Member Ports und Frame Types dazu einrichten:
- ether1 = Uplink TP-Link Switch
- ether 2 = zur freien Verwendung nicht belegt, bzw. VLAN1
- ether3 bis ether5 = Untagged Endgeräte Ports lokales LAN (VLAN 200)
IP Interfaces müssen nicht zwingend als Bridge Member Ports eingetragen sein.
5.) Mikrotik Bridge, VLANs und Port Tagging einrichten:
Fertisch !
Ping Checks lokal und nach Eintragen der statischen Route für das VLAN 200 IP Netz auf der FritzBox ins Internet fehlerfrei !
Die hiesige Beispiel Konfig macht kein NAT und hat aktuelle keine Firewall aktiv auf dem vlan200 Interface.
Das ist erstmal ein Grundgerüst um die grundlegende Funktion einzurichten und zu checken das diese wasserdicht rennt. Firewalling kommt immer danach.
These: Traue dem Frizbox Netz nicht.
Ist auch richtig, besonders wenn das eine Provider FritzBox mit aktiver TR-069 Schnüffelfunktion ist !Hier müsstest du dann noch die Firewall aktivieren bzw. entsprechend customizen. Die Regeln dazu kannst du dir der Einfachheit halber aus der Default Konfig abschauen und übernehmen !
NAT/Masquerading solltest du nicht aktivieren, denn das schafft wieder zusätzliche Probleme und frisst unnötig Performance. Da die FB ja statische Routen supportet ist ist NAT nicht zwingend. Firewall only reicht da.
Fazit:
Works as designed !!
Hi
Mittlerweile weiß ich nicht mehr was ich weiß und was ich mir nur einbilde
Aber ich habe immer noch irgendwo ein Denkfehler.
Der TP Link Switch in meiner Konfig hat beim VLAN 1 alle 5 Ports auf Untagged. Die PVID des Port 2 ist auf 1, ist ja auch ein Trunk Port.
"Würde" jetzt dort ein untagged traffic vom MT in den Port 2 des Switches kommen, dann würde der Switch über VLAN 1 das auch wieder am Port 3 ausgeben. Vermute jetzt mal, dass das mein sichtbarer WAN Traffic auf Port 3 des Switches ist.
Der TP Link Switch SE105E v1 ist wohl ohnehin Schrott, bei mir kann ich das VLAN 1 überhaupt nicht verändern.
Es ist das 'Default VLAN' und nicht veränderbar ?!!! Siehe https://static.tp-link.com/Easy%20Smart%20Configuration%20Utility_User%2 ... Seite 34. Da steht: "To ensure the normal communication of the factory switch, the default VLAN of all ports is set
to be VLAN1. VLAN 1 cannot be modified or deleted."
Wie hast du das geschafft?
Testweise habe ich jetzt den PVID des Switch-Port 2 einfach auf 99 gesetzt, und dachte das Problem damit auszutricksen. Hat aber gar nix gebracht, immer noch WAN Traffic da....
Ausserdem müsste dann der MT ja auf seinem Ether1 Port untagged WAN traffic ausspucken...
Zu deiner Ausführung:
1)
2) Unterschied bei dir / bei mir. Wobei ich das am Anfang auch genau so hatte wie du.
Das VLAN200 hat bei mir Ether1 als untagged traffic drinnen. Das könnte ja was mit meinem Problem zu tun haben?
Auch das vlan100 hatte ich mal so wie du, derzeit ist es ohne Ether1, das ist wohl sicher falsch bei mir. Obwohl verbindungstechnisch bei mir ja alles läuft.
Generelle Fragen an dich:
Gruß Martin
Mittlerweile weiß ich nicht mehr was ich weiß und was ich mir nur einbilde
Aber ich habe immer noch irgendwo ein Denkfehler.
Der TP Link Switch in meiner Konfig hat beim VLAN 1 alle 5 Ports auf Untagged. Die PVID des Port 2 ist auf 1, ist ja auch ein Trunk Port.
"Würde" jetzt dort ein untagged traffic vom MT in den Port 2 des Switches kommen, dann würde der Switch über VLAN 1 das auch wieder am Port 3 ausgeben. Vermute jetzt mal, dass das mein sichtbarer WAN Traffic auf Port 3 des Switches ist.
Der TP Link Switch SE105E v1 ist wohl ohnehin Schrott, bei mir kann ich das VLAN 1 überhaupt nicht verändern.
Es ist das 'Default VLAN' und nicht veränderbar ?!!! Siehe https://static.tp-link.com/Easy%20Smart%20Configuration%20Utility_User%2 ... Seite 34. Da steht: "To ensure the normal communication of the factory switch, the default VLAN of all ports is set
to be VLAN1. VLAN 1 cannot be modified or deleted."
Wie hast du das geschafft?
Testweise habe ich jetzt den PVID des Switch-Port 2 einfach auf 99 gesetzt, und dachte das Problem damit auszutricksen. Hat aber gar nix gebracht, immer noch WAN Traffic da....
Ausserdem müsste dann der MT ja auf seinem Ether1 Port untagged WAN traffic ausspucken...
Zu deiner Ausführung:
1)
- Warum hast du den then PVID des MT Ether1 auf 1 gesetzt? Ich habe den vorsichtshalber mal auf irgendwas "44", damit ich das als Fehlerquelle ausschliessen kann (such ja immer noch irgendwelche Loops)
- Den Layer3 Port "inside200" habe ich mit PVID 200
2) Unterschied bei dir / bei mir. Wobei ich das am Anfang auch genau so hatte wie du.
Das VLAN200 hat bei mir Ether1 als untagged traffic drinnen. Das könnte ja was mit meinem Problem zu tun haben?
Auch das vlan100 hatte ich mal so wie du, derzeit ist es ohne Ether1, das ist wohl sicher falsch bei mir. Obwohl verbindungstechnisch bei mir ja alles läuft.
Generelle Fragen an dich:
- bringt es eigentlich überhaupt irgendwas, solche Bridge-VLAN ports in die MT VLAN Tabelle mitaufzunehmen? Die kann man zwar im UI konfigurieren, aber werden ja nicht gezogen.
- Wo ist technisch der Unterschied, ob ich mein VLAN-100 Interface am Ether1 oder auf die Bridge als Port lege, um darauf den DHCP Client zu legen? Ich sehe hier lediglich ne andere MAC Adr auf der Fritzbox (Ether1 oder Bridge, die sich die IP abholt), sonst noch ein Unterschied?
Gruß Martin
Ich bin mittlerweile der Auffassung, dass mein Problem durch fehlerhaftes Verhalten des TP Link Switch verursacht wird.
Werde den mal durch einen anderen MT Router als simplen Switch ersetzen und prüfen.
Jedenfalls kaufe ich kein TP Link Switch mehr, hier https://forum.netgate.com/topic/109686/tp-link-easy-smart-switch-securit ... berichten andere Anwender von ähnlichem Verhalten, dass der Traffic ungewollt von einem VLAN ins andere kommt und auch das nervige VLAN 1 nicht bearbeitbar ist, der Support bzw. R&D sich aber querstellt. Ein Reboot spendiere ich dem Teil aber noch...
Wenn jemand ne Empfehlung für einen Homeswitch hat, dann her damit.
Er solle VLANs können und möglichst wenig Energie verbrauchen. - That's it.
Werde den mal durch einen anderen MT Router als simplen Switch ersetzen und prüfen.
Jedenfalls kaufe ich kein TP Link Switch mehr, hier https://forum.netgate.com/topic/109686/tp-link-easy-smart-switch-securit ... berichten andere Anwender von ähnlichem Verhalten, dass der Traffic ungewollt von einem VLAN ins andere kommt und auch das nervige VLAN 1 nicht bearbeitbar ist, der Support bzw. R&D sich aber querstellt. Ein Reboot spendiere ich dem Teil aber noch...
Wenn jemand ne Empfehlung für einen Homeswitch hat, dann her damit.
Er solle VLANs können und möglichst wenig Energie verbrauchen. - That's it.
Der TP Link Switch in meiner Konfig hat beim VLAN 1 alle 5 Ports auf Untagged.
Grober Fehler !!Warum ? Du betreibst kein VLAN 1 also warum. Hier musst du die komplett austragen bis auf Port 2. Dort ist das 1er eh tot weil der MT rein nur tagged Frames dort sendet (Sofern du es in der Bridge richtig customized hast !)
"Würde" jetzt dort ein untagged traffic vom MT in den Port 2 des Switches kommen, dann würde der Switch über VLAN 1 das auch wieder am Port 3 ausgeben.
Ja, klar. Aber...- Wenn du alle Ports als not member deaktivierst bis auf 2 kann das nie passieren
- An Port 2 können nie untagged Frames kommen. Der MT akzeptiert hier Tagged only !
Testweise habe ich jetzt den PVID des Switch-Port 2 einfach auf 99 gesetzt
Sinnfrei... Schadet aber auch nicht.Ich habe den vorsichtshalber mal auf irgendwas "44",
Kann man machen ist aber sinnfrei. Kommt ja eh nix untagged raus und auf dem Switch sind alle Ports not member in 1 also eine Sackgasse für 1.Den Layer3 Port "inside200" habe ich mit PVID 200
Falsch !Wozu ? Kann ja niemals in 200 untagged geforwardet werden und L3 Interfaces müssen intern Tags haben !
Das VLAN200 hat bei mir Ether1 als untagged traffic drinnen.
Falsch. Genau das ist der Fehler Knackpunkt. VL200 muss zwingend Tagged sein.Halte dich einfach an die Screenshots von oben. Hier rennt das alles vollkommen fehlerlos, MIT TP-Link Switch
!Auch das vlan100 hatte ich mal so wie du, derzeit ist es ohne Ether1
Ja das ist falsch. Dort fehlt das Tagging komplett auf dem eth1 Port für vlan100 und vlan200. Das kann so nie klappen wenn der Switch diese VLANs nur getagged akzeptiert.Ich bin mittlerweile der Auffassung, dass mein Problem durch fehlerhaftes Verhalten des TP Link Switch verursacht wird.
Könnte sein aber sehr unwahrscheinlich. Hier ist ein SG105E v4 im Einsatz !Hast du ihm die aktuellste Firmware geflasht ???
https://www.tp-link.com/de/support/download/tl-sg105e/v1/#Firmware
(Achte auf die Version !)
und auch das nervige VLAN 1 nicht bearbeitbar ist
Na ja man kann wenigstens die Memeber Ports dort abschalten was man auch tun sollte.Wenn jemand ne Empfehlung für einen Homeswitch hat, dann her damit.
Cisco SG250-8https://www.cisco.com/c/en/us/support/switches/sg250-08-8-port-gigabit-s ...
Mikrotik RB260 oder CRS
oder Zyxel GS1200-5 oder -8
https://www.zyxel.com/de/de/products_services/5-Port-8-Port-Web-Managed- ...
Hi
Also, jetzt 1:1 deine Einstellungen drin, leider leider immer noch das gleiche Verhalten:
- ich sehe am Switch Port 3 den WAN Traffic (also vom vlan100).
- alles läuft technisch dennoch weiter (sprich auch jetzt hat jeder port Inet, und ich kann im VLAN200 alles was sein soll anpingen)
Auf meinem TP Link (ist ja Version 1) kann man GAR NICHTS ändern am VLAN 1.
- nichts löschen
- nichts umbenennen
- keine Ports entfernen
- keine Ports anders als untagged setzen
deswegen habe ich auch einfach seitens des MT einige "Unmögliche Fälle" versucht abzufangen, die sicher sinnlos sind aber auch nicht weh tun.
Bislang weiss ich ja nicht ob ich einem Phänomen des TP Link, des Mikrotik oder in meinem Kopf hinterher jage.
Die neueste Firmware ist auch auf meinem TP Link. Hab dort auch schon in der Zwischenzeit mit dem Easy Config und dem Pro versucht das VLAN1 zu manipulieren. Nix. Änderungen an VLAN1 kann man "speichern", sind sie aber nicht (sagt nur das UI in dem Moment, aber wenn man zwischen den Menüpunkten hin und her springt sieht man dass sie gar nicht gespeichert wurden)
Siehtst du eine Möglichkeit, dass dieses VLAN 1 bei mir das besagte Verhalten auslösen könnte? Ich eigentlich nicht mehr.
Tippe auf ein TP Link BUG...
Also, jetzt 1:1 deine Einstellungen drin, leider leider immer noch das gleiche Verhalten:
- ich sehe am Switch Port 3 den WAN Traffic (also vom vlan100).
- alles läuft technisch dennoch weiter (sprich auch jetzt hat jeder port Inet, und ich kann im VLAN200 alles was sein soll anpingen)
Auf meinem TP Link (ist ja Version 1) kann man GAR NICHTS ändern am VLAN 1.
- nichts löschen
- nichts umbenennen
- keine Ports entfernen
- keine Ports anders als untagged setzen
deswegen habe ich auch einfach seitens des MT einige "Unmögliche Fälle" versucht abzufangen, die sicher sinnlos sind aber auch nicht weh tun.
Bislang weiss ich ja nicht ob ich einem Phänomen des TP Link, des Mikrotik oder in meinem Kopf hinterher jage.
Die neueste Firmware ist auch auf meinem TP Link. Hab dort auch schon in der Zwischenzeit mit dem Easy Config und dem Pro versucht das VLAN1 zu manipulieren. Nix. Änderungen an VLAN1 kann man "speichern", sind sie aber nicht (sagt nur das UI in dem Moment, aber wenn man zwischen den Menüpunkten hin und her springt sieht man dass sie gar nicht gespeichert wurden)
Siehtst du eine Möglichkeit, dass dieses VLAN 1 bei mir das besagte Verhalten auslösen könnte? Ich eigentlich nicht mehr.
Tippe auf ein TP Link BUG...
Hi
Also ich hab nun am meinem TP Link ein VLAN50 dazugemacht und den Port 5 als einzigen Member mit untagged gesetzt.
Einen Latop dran mit Wireshare und siehe da, da ist immer noch Traffic vom MT => Fritzbox (also WAN Traffic)
Folglich gibt es nur mehr 2 Optionen:
- Entweder sendet der MT untagged traffic auf Ether1 oder
- der TP Link hat einen Hau und vermischelt die VLANs irgendwie/aufgrund von irgendwas
Also, wenn ich mir am MT den Ether1 Traffic mit MT sniffer tool anschaue, dann habe ich dort scheinbar wirklich untagged traffic von innen nach aussen. Zumindest lese ich das so aus dem Wireshark (nachdem ich den Ether1 traffic auf mein Laptop geforwared habe)
@aqui: könntest du bei dir mal im Labor ein Test machen und schauen, ob du wirklich kein Untagged traffic auf ether1 des MT hast, wenn irgendein Client im VLAN200 Internet Zugriff macht?
Was mich immer verunsichert, ist die Tatsache, dass der Ether1 ja Port Member der Bridge ist. Und wenn die Bridge von der CPU Traffic bekommt, dieser vielleicht irgendwie falsch oder zusätzlich auf Ether1 landet.
Früher hatte ich Ether1 ja gar nicht als Member auf der Bridge und habe mit beiden VLAN Interface direkt auf Ether1 gearbeitet.
Jetzt soll man die VLAN Interface anstatt dessen ja auf der Bridge definieren.
Jetzt nach gefühlten 100 Stunden aufgeben? Oder einfach wegschauen und so tun, also ob ich nicht wüsste was in meinem Netz los ist....
Mmmh. Weiß auch nicht
Also ich hab nun am meinem TP Link ein VLAN50 dazugemacht und den Port 5 als einzigen Member mit untagged gesetzt.
Einen Latop dran mit Wireshare und siehe da, da ist immer noch Traffic vom MT => Fritzbox (also WAN Traffic)
Folglich gibt es nur mehr 2 Optionen:
- Entweder sendet der MT untagged traffic auf Ether1 oder
- der TP Link hat einen Hau und vermischelt die VLANs irgendwie/aufgrund von irgendwas
Also, wenn ich mir am MT den Ether1 Traffic mit MT sniffer tool anschaue, dann habe ich dort scheinbar wirklich untagged traffic von innen nach aussen. Zumindest lese ich das so aus dem Wireshark (nachdem ich den Ether1 traffic auf mein Laptop geforwared habe)
@aqui: könntest du bei dir mal im Labor ein Test machen und schauen, ob du wirklich kein Untagged traffic auf ether1 des MT hast, wenn irgendein Client im VLAN200 Internet Zugriff macht?
Was mich immer verunsichert, ist die Tatsache, dass der Ether1 ja Port Member der Bridge ist. Und wenn die Bridge von der CPU Traffic bekommt, dieser vielleicht irgendwie falsch oder zusätzlich auf Ether1 landet.
Früher hatte ich Ether1 ja gar nicht als Member auf der Bridge und habe mit beiden VLAN Interface direkt auf Ether1 gearbeitet.
Jetzt soll man die VLAN Interface anstatt dessen ja auf der Bridge definieren.
Jetzt nach gefühlten 100 Stunden aufgeben? Oder einfach wegschauen und so tun, also ob ich nicht wüsste was in meinem Netz los ist....
Mmmh. Weiß auch nicht
Also, jetzt 1:1 deine Einstellungen drin, leider leider immer noch das gleiche Verhalten:
Sorry, aber wenn man sich den Screenshot vom Switch Setup ansieht von dir ist das ja nicht ganz richtig...Dort sind immer noch die Ports 1 bis 5 ALLE Member Ports in VLAN 1 was sie NICHT sein sollten !
In den Untagged Ports der VLANs 100 und 200 (PVID) darf doch niemals das VLAN 1 zusätzlich auch noch Member Port sein. Entferne das doch endlich mal !
Das hast du bis jetzt noch nicht umgesetzt.
Man kann aber natürlich nicht ausschliessen das der Switch einen an der Waffel hat aber wenn du das VLAN 1 als Memberport komplett vom Port 1 und vom Port 2 wegnimmst, dann kann nie und nimmer nicht an den anderen Ports dieser Traffic auftauchen.
Sollte er es dennoch machen bleibt dir nur den Switch schnell zu entsorgen, denn dann hat er ein völlig falsches und nicht Standard konformes VLAN Verhalten.
Hier ist es ein Version 4 SG105E der mit aktuellster Firmware absolut fehlerlos funktioniert.
Auf meinem TP Link (ist ja Version 1) kann man GAR NICHTS ändern am VLAN 1.
Mmmhhh, das ist dann doof ! Gibt es den Punkt Not Member dort nicht wie im GUI der Version 4 ???Wenn das der Fall sein sollte ist es dann der Switch der nicht Standard konform ist. Dann solltest du den in der Tat entsorgen oder durch einen besseren ersetzen.
Tippe auf ein TP Link BUG...
Das ist es dann auch ganz sicher. Mit einem Firmware Release aus letzter Stand 2014 muss man sich da auch sicher nicht wundern....Am besten erneuern statt weiter rumärgern. Der MT ist es de facto nicht, denn der verhält sich absolut Standard konform, das kann man hier an einem Cisco Catalyst Profi Switch mit dem Mirror Port einwandfrei verifizieren !
könntest du bei dir mal im Labor ein Test machen und schauen, ob du wirklich kein Untagged traffic auf ether1 des MT hast
Ja, mache ich für dich. Ich lass den Wireshark mitlaufen und spiegele den eth1 Uplink Port an einem Zyxel GS-1200 und an einem Cisco Catalyst 2960 um ganz sicher zu gehen !Und wenn die Bridge von der CPU Traffic bekommt, dieser vielleicht irgendwie falsch oder zusätzlich auf Ether1 landet.
Könnte theoretisch sein aber welcher interne MT Port sollte denn untagged Traffic senden ? Die L3 Ports taggen alle ausnahmslos und zudem ist der Port Mode auf eth1 ja fixed auf "Only VLAN Tagged" gesetzt. Technisch können hier also keinerle Pakete OHNE einen gültigen VLAN Tag auftauchen. Ich sniffer das aber um sicher zu gehen...Jetzt soll man die VLAN Interface anstatt dessen ja auf der Bridge definieren.
Das sind sie doch !
dass der Ether1 ja Port Member der Bridge ist.
Muss er ja zwangsläufig, denn er ist ein Switching Port und kein reiner Routing Port. Er muss als zwangsweise Member der VLAN Bridge sein !Früher hatte ich Ether1 ja gar nicht als Member auf der Bridge
Mit der alen MT Firmware vor 6.41 ! Ja das ist klar, da konnte man das auch gar nicht anders einrichten. Das ist aber seit 6.41 alles passe.Jetzt nach gefühlten 100 Stunden aufgeben?
Nope, niemals !Du bist Opfer eines billigen Chinesenswitches und das sollte dann niemals das Resultat sein !
Hier kommt der Wireshark Trace. Um es vorweg zu nehmen: Der Mikrotik verhält sich absolut Standard konform:
Messaufbau:
(Das die Mac Adressen der L3 Interfaces gleich sind ist übrigens völlig normal. Die VLAN Domains sind ja L2 seitig völlig getrennt und der Switch führt jeweils getrennte Mac Adress Datenbanken pro VLAN L2 Collision Domain !)
Der Mikrotik eth1 Port wird am Switch bidirektional auf den Spiegelport 10 gesendet so das man dort ein 1:1 Abbild des Traffics bekommt.
Der RasPi macht einen Ping auf die IP Adresse des Internet Routers (auch ein Mikrotik). Der entspricht deiner FritzBox.
Man sieht hier deutlich den RasPi ICMP Echo Request der entsprechend am Port mit einem 802.1q VLAN Tag 200 zum Mikrotik, VLAN 200 L3 Interface geht.
Das routet dann das Paket weiter über das VLAN 100 IP Interface raus mit dem entsprechenden VLAN Tag 100 zum Switchport 2 und dann untagged weiter via Switchport 1 an den Internet Router:
Entsprechend kommt dann die Rückantwort (ICMP Echo Reply) vom Internet Router untagged zum Switchport 1 dann mit einem VLAN 100 Tagging and Port 2 zum VLAN 100 IP Interface Mikrotik:
Der routet es dann wieder via VLAN 200 IP Interface und 200er Tag zum Switchport 2 und dann untagged zum RasPi raus via Port 3:
Also Bilderbuch mässiger könnte es kaum sein
Was dich und deinen mackigen Switch ggf. zu Fall gebracht haben sind die Infrastruktur Protokolle wie RSTP Spanning Tree BPDUs, LLDP und Cisco CDP Protokoll !!
Alle diese Protokolle kommen hier vom Mikrotik untagged am Port eth1 raus weil die Bridge per Default immer untagged in VLAN1/PVID1 hängt, denn das sind L1 Protokolle die immer direkt Punkt zu Punkt auf der Physik kommen. Die Bridge muss diese also per Definition untagged aussenden im Single Spann Verfahren:
Dein Port 2 ist aber untagged ja immer im VLAN 1 und du kannst im Gegensatz zur Version 4 ja scheinbar das VLAN 1 nicht als "Not Member" deklarieren und so von den anderen PVID Ports isolieren.
Wenn dann natürlich die PVID 100 und 200 Ports noch zusätzlich in der VLAN 1 Broadcast Domain sind ist es vollkommen klar das du an den Untagged 100er und 200er Ports dann von den untagged Protokollen im VLAN 1 geflutet wirst und diese dort siehst.
Letzteres spricht dann für einen klaren Bug bzw. fehlendem Feature ("Not Member" Setting) im Switch !
Übrigens die RSTP BPDU Pakete vom Internet Router reicht der Switch (dort ist STP deaktiviert !) dann Tagged im VLAN 100 weiter.
Fazit:
Es rennt alles vorbildlich wie es soll und der böse Buhmann ist klar die alte Switch Hardware bzw. fehlerhaft Firmware deines TP-Link Switches. Soviel ist sicher !
Du hast alles richtig gemacht bis dann aber an alter Chinesen Hardware gescheitert... Kein Grund zum Aufgeben also !
Zeigt auch wieder das man sowas mit dem Wireshark klar nachweisen und wasserdicht beweisen kann !
Messaufbau:
(Das die Mac Adressen der L3 Interfaces gleich sind ist übrigens völlig normal. Die VLAN Domains sind ja L2 seitig völlig getrennt und der Switch führt jeweils getrennte Mac Adress Datenbanken pro VLAN L2 Collision Domain !)
Der Mikrotik eth1 Port wird am Switch bidirektional auf den Spiegelport 10 gesendet so das man dort ein 1:1 Abbild des Traffics bekommt.
Der RasPi macht einen Ping auf die IP Adresse des Internet Routers (auch ein Mikrotik). Der entspricht deiner FritzBox.
Man sieht hier deutlich den RasPi ICMP Echo Request der entsprechend am Port mit einem 802.1q VLAN Tag 200 zum Mikrotik, VLAN 200 L3 Interface geht.
Das routet dann das Paket weiter über das VLAN 100 IP Interface raus mit dem entsprechenden VLAN Tag 100 zum Switchport 2 und dann untagged weiter via Switchport 1 an den Internet Router:
Entsprechend kommt dann die Rückantwort (ICMP Echo Reply) vom Internet Router untagged zum Switchport 1 dann mit einem VLAN 100 Tagging and Port 2 zum VLAN 100 IP Interface Mikrotik:
Der routet es dann wieder via VLAN 200 IP Interface und 200er Tag zum Switchport 2 und dann untagged zum RasPi raus via Port 3:
Also Bilderbuch mässiger könnte es kaum sein
Was dich und deinen mackigen Switch ggf. zu Fall gebracht haben sind die Infrastruktur Protokolle wie RSTP Spanning Tree BPDUs, LLDP und Cisco CDP Protokoll !!
Alle diese Protokolle kommen hier vom Mikrotik untagged am Port eth1 raus weil die Bridge per Default immer untagged in VLAN1/PVID1 hängt, denn das sind L1 Protokolle die immer direkt Punkt zu Punkt auf der Physik kommen. Die Bridge muss diese also per Definition untagged aussenden im Single Spann Verfahren:
Dein Port 2 ist aber untagged ja immer im VLAN 1 und du kannst im Gegensatz zur Version 4 ja scheinbar das VLAN 1 nicht als "Not Member" deklarieren und so von den anderen PVID Ports isolieren.
Wenn dann natürlich die PVID 100 und 200 Ports noch zusätzlich in der VLAN 1 Broadcast Domain sind ist es vollkommen klar das du an den Untagged 100er und 200er Ports dann von den untagged Protokollen im VLAN 1 geflutet wirst und diese dort siehst.
Letzteres spricht dann für einen klaren Bug bzw. fehlendem Feature ("Not Member" Setting) im Switch !
Übrigens die RSTP BPDU Pakete vom Internet Router reicht der Switch (dort ist STP deaktiviert !) dann Tagged im VLAN 100 weiter.
Fazit:
Es rennt alles vorbildlich wie es soll und der böse Buhmann ist klar die alte Switch Hardware bzw. fehlerhaft Firmware deines TP-Link Switches. Soviel ist sicher !
Du hast alles richtig gemacht bis dann aber an alter Chinesen Hardware gescheitert... Kein Grund zum Aufgeben also !
Zeigt auch wieder das man sowas mit dem Wireshark klar nachweisen und wasserdicht beweisen kann !
1
Super, vielen Dank für deine Analyse. Echt super.
Ich habe heute Nachmittag auch quasi das Identische gemacht.
D.h. Inet geht nicht, weil ja kein "helfendes" TP-LINK VLAN1 mehr da ist. Das hat mir die Loops gemacht.
Das stimmt so, oder? Jedenfalls muss ich im Moment wieder mit TP Link fahren, da ich sonst kein Inet habe O-(
Vielleicht liegt die nun wiederum nur am SNIFFER Tool, dass das VLAN Tag für ausgehenden Traffic nicht anzeigen kann?? Da gab's doch mal ein Forumeintrag dazu.
Also mit Wireshark auf Ether1:
Jeder eingehende Traffic hat das Tag 100, der ausgehende Traffic hat nix. Getestet habe ich auch mit PING
Irgendwo habe ich wohl schon noch ein Fehler drin oder irgendwann bei den ganzen Tests und Versuchen einen eingebaut.
Schaut so aus als bleibt mir nix anderes übrig, als die derzeitige Config zu exportieren und das Teil dann zurücksetzen und von 0 beginnen.
Also falls du Lust hast, bei mir draufzuschauen
dann könnte ich zu einer Session einladen. Teams, Skype, Zoom egal. Ich bin jedenfalls im Moment so erreichbar https://us04web.zoom.us/j/677569430?pwd=Z29BVFJjVVpGSXZScDAxSE5sVXZCQT09
Danke. Du leistest wertvolle Unterstützung!
Ich habe heute Nachmittag auch quasi das Identische gemacht.
- Den TP Link habe ich mitterweile durch einen MT ersetzt und mach dort L2 Switching mit Switch Port Mirroring zur Analyse.
D.h. Inet geht nicht, weil ja kein "helfendes" TP-LINK VLAN1 mehr da ist. Das hat mir die Loops gemacht.
# model = 951G-2HnD
/interface bridge add name=bridge1 protocol-mode=none
/interface ethernet switch port
set 0 default-vlan-id=100 vlan-header=always-strip vlan-mode=secure
set 1 vlan-header=add-if-missing vlan-mode=secure
set 2 default-vlan-id=200 vlan-header=always-strip vlan-mode=secure
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
/interface ethernet switch vlan
add independent-learning=yes ports=ether1,ether2 switch=switch1 vlan-id=100
add independent-learning=yes ports=ether2,ether3 switch=switch1 vlan-id=200
/interface ethernet switch rule
add mirror=yes new-dst-ports=ether4 ports=ether2 switch=switch1- Den eigentlichen MT sniffe ich mit seinem sniffer tool und forwarding auf mein Laptop/Wireshark. So kann ich mir das Ether1 aus Sicht vom MT anschauen.
- der MT sendet anscheinend bei mir im Moment wieder keinen(!) getaggten Traffic auf Ether1 ins Internet
Vielleicht liegt die nun wiederum nur am SNIFFER Tool, dass das VLAN Tag für ausgehenden Traffic nicht anzeigen kann?? Da gab's doch mal ein Forumeintrag dazu.
Also mit Wireshark auf Ether1:
Jeder eingehende Traffic hat das Tag 100, der ausgehende Traffic hat nix. Getestet habe ich auch mit PING
- PING ins Internet direkt aus dem MT Terminal heraus => der ausgehende Traffic hat kein TAG
- PING ins Internet von einem 200er WLAN Client aus: diesen Traffic sehe dann interessanterweise nicht im Wireshark
Irgendwo habe ich wohl schon noch ein Fehler drin oder irgendwann bei den ganzen Tests und Versuchen einen eingebaut.
Schaut so aus als bleibt mir nix anderes übrig, als die derzeitige Config zu exportieren und das Teil dann zurücksetzen und von 0 beginnen.
Also falls du Lust hast, bei mir draufzuschauen
dann könnte ich zu einer Session einladen. Teams, Skype, Zoom egal. Ich bin jedenfalls im Moment so erreichbar https://us04web.zoom.us/j/677569430?pwd=Z29BVFJjVVpGSXZScDAxSE5sVXZCQT09Danke. Du leistest wertvolle Unterstützung!
Vom "Router"- MT kommender Traffic scheint nicht getaggt...
Ooops ! Das kann aber nicht sein wenn du es richtig konfiguriert hast ?! Du siehst ja oben an den Traces das der MT Traffic getagged ist und das auch zwingend sein muss, denn sonst würde der Swith das gar nicht forwarden, da er an reinem reinen getaggten Port ungetaggte Frames verwirft.Gut möglich aber das du deine Netzwerkkarte nicht im Promiscous Mode betreibst so das diese im Wireshark Tagged Pakete gar nicht anzeigt !! Kann das sein !
Das hier solltest du dazu zwingend beachten:
https://www.intel.com/content/www/us/en/support/articles/000005498/netwo ...
Sofern du eine Intel Karte im Rechner hast.
Realtek Karten mach das in der Regel von sich aus richtig.
Check das also im Geräte Manager sofern du Winblows als Wireshark Rechner hast !
der MT sendet anscheinend bei mir im Moment wieder keinen(!) getaggten Traffic auf Ether1 ins Internet
Oder dein Wireshark zeigt das nicht richtig an ! Siehe oben...Kannst du ja ganz einfach checken indem du den Wireshark mal an einen Tagged Switchport hängst. Dort müssen zwangsweise 802.1q Tags sichtbar sein.
Bei Intel Karten ist zwingend ein Eingriff in die Registry nötig !
Jeder eingehende Traffic hat das Tag 100, der ausgehende Traffic hat nix. Getestet habe ich auch mit PING
Wenn dem so ist dann..- zeigt erstens dein Wireshark die Tags richtig an
- zweitens ist aber dann ganz sicher deine Mikrotik Konfiguration fehlerhaft ! Frames die am Switch Uplink Port rein und rausgehen müssen zwingend getaggt sein. Sind sie das nicht kann der Switch alle diese Pakete nicht mehr dem richtiogen VLAN zuordnen. Klar, wie sollte das auch gehen ohne einen VLAN Tag. Alle diese Frames forwardet der Switch dann im VLAN 1 was ja bei deinem TP-Link Modell nicht abschlatbar ist.
Du solltest also dringenst nochmal deine MT Konfig überprüfen. Da stimmt was nicht !
PING ins Internet von einem 200er WLAN Client aus: diesen Traffic sehe dann interessanterweise nicht im Wireshark
Müsste aber natürlich zusehen sein ! Siehe die Wireshark Traces oben im Screenshot !Irgendwo habe ich wohl schon noch ein Fehler drin
Ganz sicher...!Zoom besser nicht:
https://www.heise.de/security/meldung/Videokonferenz-Software-Ist-Zoom-e ...
Danke. Du leistest wertvolle Unterstützung!
Danke für die Blumen. Setzt den MT erstmal zurück mit Haken bei Kein Backup, Keine Default Konfig und fange nochmal neu an. Die Screenshots zum richtigen Setup siehst du ja alle oben.
Wenn alle Stricke reissen mach ich die Konfig auf einem hAP ac hier und poste dir die fertige Konfig zum Download.
hi
Alles neu und minimalistisch eingestellt. Selbes Verhalten.... ;-(
Das ist die ganze Konfig. Da kann man doch nichts falsch machen ??
Das wireless Zeugs habe ich drinnen, weil ich mit meinem Laptop keine LAN Möglichkeit hab und aber von hier manage.
Alles neu und minimalistisch eingestellt. Selbes Verhalten.... ;-(
Das ist die ganze Konfig. Da kann man doch nichts falsch machen ??
Das wireless Zeugs habe ich drinnen, weil ich mit meinem Laptop keine LAN Möglichkeit hab und aber von hier manage.
[admin@MikroTik] > export
# apr/11/2020 21:14:05 by RouterOS 6.46.5
# software id = 9TV0-81R3
#
# model = RBD52G-5HacD2HnD
# serial number = A6470A02AF29
/interface wireless
set [ find default-name=wlan1 ] disabled=no ssid=MikroTik
set [ find default-name=wlan2 ] disabled=no mode=ap-bridge ssid=siouxnet-test vlan-id=200 vlan-mode=use-tag
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys supplicant-identity=MikroTik wpa2-pre-shared-key=xxxxx
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/interface bridge
add name=bridge1 vlan-filtering=yes
/interface vlan
add interface=bridge1 name=vlan100 vlan-id=100
add interface=bridge1 name=vlan200 vlan-id=200
/interface bridge port
add bridge=bridge1 interface=wlan2
add bridge=bridge1 interface=ether2
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=ether1
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=200
/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether1,vlan100 vlan-ids=100
add bridge=bridge1 tagged=bridge1,ether1,wlan2,vlan200 vlan-ids=200
/ip dhcp-client
add disabled=no interface=vlan100
/ip address
add address=192.168.1.1/24 interface=vlan200 network=192.168.1.0
/ip dns
set allow-remote-requests=yes
/ip pool
add name=pool1 ranges=192.168.1.40-192.168.1.140
/ip dhcp-server
add address-pool=pool1 disabled=no interface=vlan200 name=dhcp-server1
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=192.168.1.1 domain=lan gateway=192.168.1.1 netmask=24
/system clock
set time-zone-name=Europe/Vienna
/tool sniffer
set filter-interface=ether1 filter-ip-protocol=icmp filter-stream=yes streaming-enabled=yes streaming-server=192.168.1.62
Ich glaube hier müsste man den getaggten WAN Traffic auch innerhalb des MT sehen, einfach den input und/oder output enablen und das Log anschauen.
/interface bridge filter
add action=log chain=output disabled=yes log=yes log-prefix=log_wan_out out-interface=ether1
add action=log chain=input disabled=yes in-interface=ether1 log=yes log-prefix=log_wan_in
Ping vom Terminal ins Inet:
/interface bridge filter
add action=log chain=output disabled=yes log=yes log-prefix=log_wan_out out-interface=ether1
add action=log chain=input disabled=yes in-interface=ether1 log=yes log-prefix=log_wan_in
Ping vom Terminal ins Inet:
- ausgehend keine Tagging
- eingehend 100 VLAN ID
Hier die funktionierende Konfig auf einem hAP ac:
Du kannst dir die Konfig Datei auch original HIER runterladen.
Zur Kontrolle nochmal die VLAN Bridge Settings dieser Konfig:
Das für die Untagged Endgeräte Ports im VLAN 200 für den Konfig Zugang (LAN und beide WLAN Bänder)
Hier nochmal ein Wireshark Trace mit dem gleichen Test und Sniffer Aufbau von oben.
Der Raspberry Pi schickt einen NTP Request an den NTP Zeitserver der TU Berlin und wie du siehst kommt das NTP Paket 2mal am Switchport 2 vorbei das Tagged zum Mikrotik geht !
Beides mal, wie es sein soll, korrekt getagged mit der VLAN ID 100 und der VLAN ID 200 !!:
NTP Paket vom Raspberry im VLAN 200 an die VLAN 200 IP Adresse des hAP Routers:
Geroutet via VLAN 100 Interface an den Internet Router:
Antwort des TU Berlin NTP Servers via Internet Router zum VLAN 100 Interface:
Antwort via VLAN 200 Interface auf den RasPi:
Fazit:
Bilderbuchmässig wie es sein soll !!
Nun bist du wieder dran !
[admin@hAP ac] > export
# apr/12/2020 12:42:49 by RouterOS 6.46.5
# software id = V9FH-123W
#
# model = RouterBOARD 952Ui-5ac2nD
# serial number = 6CBA06751234
#
/interface bridge
add igmp-snooping=yes name=vlan-bridge vlan-filtering=yes
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-g/n comment="2,4Ghz AP" country=germany disabled=\
no frequency=2422 mode=ap-bridge ssid=MikroTik wps-mode=disabled
set [ find default-name=wlan2 ] band=5ghz-n/ac channel-width=20/40/80mhz-eCee comment=\
"5Ghz AP" country=germany disabled=no frequency=auto mode=ap-bridge ssid=\
"MikroTik 5Ghz" wps-mode=disabled
/interface wireless manual-tx-power-table
set wlan1 comment="2,4Ghz AP"
set wlan2 comment="5Ghz AP"
/interface wireless nstreme
set wlan1 comment="2,4Ghz AP"
set wlan2 comment="5Ghz AP"
/interface vlan
add comment="Internet (WAN)" interface=vlan-bridge name=vlan100 vlan-id=100
add comment="Lokales LAN" interface=vlan-bridge name=vlan200 vlan-id=200
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=dhcp_pool200 ranges=10.0.200.100-10.0.200.150
/ip dhcp-server
add address-pool=dhcp_pool200 disabled=no interface=vlan200 name=dhcp200
/interface bridge port
add bridge=vlan-bridge frame-types=admit-only-vlan-tagged interface=ether1
add bridge=vlan-bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether4 \
pvid=200
add bridge=vlan-bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether5 \
pvid=200
add bridge=vlan-bridge frame-types=admit-only-untagged-and-priority-tagged interface=wlan1 \
pvid=200
add bridge=vlan-bridge frame-types=admit-only-untagged-and-priority-tagged interface=wlan2 \
pvid=200
/interface bridge vlan
add bridge=vlan-bridge tagged=vlan-bridge,vlan100,ether1 vlan-ids=100
add bridge=vlan-bridge tagged=vlan-bridge,vlan200,ether1 vlan-ids=200
/ip address
add address=10.0.200.1/24 interface=vlan200 network=10.0.200.0
/ip dhcp-client
add disabled=no interface=vlan100
/ip dhcp-server network
add address=10.0.200.0/24 dns-server=10.0.200.1 domain=vlan200.intern gateway=10.0.200.1 \
netmask=24
/ip dns
set allow-remote-requests=yes
/system clock
set time-zone-name=Europe/Berlin
/system identity
set name="hAP ac"
/system ntp client
set enabled=yes
[admin@hAP ac] > Zur Kontrolle nochmal die VLAN Bridge Settings dieser Konfig:
Hier nochmal ein Wireshark Trace mit dem gleichen Test und Sniffer Aufbau von oben.
Der Raspberry Pi schickt einen NTP Request an den NTP Zeitserver der TU Berlin und wie du siehst kommt das NTP Paket 2mal am Switchport 2 vorbei das Tagged zum Mikrotik geht !
Beides mal, wie es sein soll, korrekt getagged mit der VLAN ID 100 und der VLAN ID 200 !!:
NTP Paket vom Raspberry im VLAN 200 an die VLAN 200 IP Adresse des hAP Routers:
Geroutet via VLAN 100 Interface an den Internet Router:
Antwort des TU Berlin NTP Servers via Internet Router zum VLAN 100 Interface:
Antwort via VLAN 200 Interface auf den RasPi:
Fazit:
Bilderbuchmässig wie es sein soll !!
Nun bist du wieder dran !
Hello
Ich hab mittlerweile ein halbes fliegendes Labor hier herum.
Deine Einstellungen habe ich übernommen, halt mit zusätzlichen VLAN settings für WLAN wieder. Also: vlan-id=200 vlan-mode=use-tag beim jeweiligen Wireless Interface und in der VLAN Tabelle beim 200er als Tagged rein).
Und wieder alles beim Alten.
Aber, jetzt habe ich meine 'Traffic Analyse' analysiert:
Also was passiert mit der Anzeige der VLAN Tags bei den mir zur Verfügung stehenden Mittel: Torch, Sniffer im Terminal, Sniffer mit Forward des Traffic über eingekappselte Frames (=was ich bisher immer verwendet hatte) und Port Mirroring am MT selbst). Und jetzt kommt's:
Es ist ein einfacher Anzeigefehler.......
1) MT sniffer traffic forward von getaggtem Traffic. Mein Wireshark läuft auf einem Laptop mit WLAN Verbindung zum MT.
Da sniffe ich also Ether1 mit ICMP Filter und setze gleichzeitig vom MT Terminal einen Ping ins Internet ab.
ausgehend - VLAN Tag fehlt:
eingehend - VLAN Tag da:
Und im Terminal direkt kann man gleichzeitig die richtigen Tags sehen. Man muss sich blöderweise nur durch alles durchklicken, damit die Spalten angezeigt werden ...
2) Torch
Wenn man sich den Ether1 Traffic anschaut, dann sieht man auch das VLAN Tag.
Insofern man das richtig macht. Ich habe mich vom Winbox UI aushebeln lassen. Ich habe erst jetzt überrissen, dass der linke Teil kein FILTER, sondern ein COLLECT ist. Checkt man das VLAN-ID Feld also nicht an, dann wird der Traffic zwar angezeigt, aber keine Inhalte in der Spalte VLAN-ID.
Und als Draufgabe muss man den laufenden Torch nocheinmal explizit Starten, also ein zusätzlicher Klick auf START, sonst ist das Setting nur scheinbar aktiv.
=> Ich habe mich selbst blind gemacht.
Ausserdem zeigt der Torch dort nur eingehende Packete an. Man sucht dort vergebens ausgehenden Traffic mit einem bestimmten VLAN Tag....
3) Port Mirroring
Mein alter Laptop mit LAN Anschluss wurde für die Analysen aktiviert. Ich habe den MT selbst für den Zugriff auf den Traffic am dortigen Ether1 ausgewählt und den mit Boardmitteln auf Ether5 gespiegelt.
Nachdem ich nun heute dort gar kein Tagging (weder rein, noch raus) gesehen habe, ist mir der Hinweis bezüglich Intel Treiber eingefallen.
Treiber Bezeichnung ist bei mir zwar e1i (also in dem Hinweis nicht gelistet), aber hab's trotzdem eingetragen, rebootet und gestaunt Juhu, endlich sehe ich an einem Mirrorport auch VLAN Traffic. Diese Transparenz macht alles viel einfacher
Das Finale:
Einen herzlichen Dank für die Unterstüzung gilt @aqui !
Jetzt hab ich endlich wieder die volle Kontrolle über mein Netz.
Vor dem ganzen Spektakel hier wollte ich eigentlich nur schnell intern auf IPv6 gehen und 2-3 Standorte mit VPN verbinden. So gehts also weiter ...
Frohe Ostern
Ich hab mittlerweile ein halbes fliegendes Labor hier herum.
Deine Einstellungen habe ich übernommen, halt mit zusätzlichen VLAN settings für WLAN wieder. Also: vlan-id=200 vlan-mode=use-tag beim jeweiligen Wireless Interface und in der VLAN Tabelle beim 200er als Tagged rein).
Und wieder alles beim Alten.
Aber, jetzt habe ich meine 'Traffic Analyse' analysiert:
Also was passiert mit der Anzeige der VLAN Tags bei den mir zur Verfügung stehenden Mittel: Torch, Sniffer im Terminal, Sniffer mit Forward des Traffic über eingekappselte Frames (=was ich bisher immer verwendet hatte) und Port Mirroring am MT selbst). Und jetzt kommt's:
Es ist ein einfacher Anzeigefehler.......
1) MT sniffer traffic forward von getaggtem Traffic. Mein Wireshark läuft auf einem Laptop mit WLAN Verbindung zum MT.
Da sniffe ich also Ether1 mit ICMP Filter und setze gleichzeitig vom MT Terminal einen Ping ins Internet ab.
- Ausgehender Traffic (Ether 1 mit VLAN 100) hat da (und auch im Terminal selbst) keinen VLAN Tag .... das hatte ich ja berichtet. Das ist aber falsch, dieser Traffic ist in Wirklichkeit sehr wohl getaggt.
- Eingehender Traffic (100) auf Ether1 wird hingegen richtig angezeigt.
ausgehend - VLAN Tag fehlt:
Und im Terminal direkt kann man gleichzeitig die richtigen Tags sehen. Man muss sich blöderweise nur durch alles durchklicken, damit die Spalten angezeigt werden ...
2) Torch
Wenn man sich den Ether1 Traffic anschaut, dann sieht man auch das VLAN Tag.
Insofern man das richtig macht. Ich habe mich vom Winbox UI aushebeln lassen. Ich habe erst jetzt überrissen, dass der linke Teil kein FILTER, sondern ein COLLECT ist. Checkt man das VLAN-ID Feld also nicht an, dann wird der Traffic zwar angezeigt, aber keine Inhalte in der Spalte VLAN-ID.
Und als Draufgabe muss man den laufenden Torch nocheinmal explizit Starten, also ein zusätzlicher Klick auf START, sonst ist das Setting nur scheinbar aktiv.
=> Ich habe mich selbst blind gemacht.
Ausserdem zeigt der Torch dort nur eingehende Packete an. Man sucht dort vergebens ausgehenden Traffic mit einem bestimmten VLAN Tag....
3) Port Mirroring
Mein alter Laptop mit LAN Anschluss wurde für die Analysen aktiviert. Ich habe den MT selbst für den Zugriff auf den Traffic am dortigen Ether1 ausgewählt und den mit Boardmitteln auf Ether5 gespiegelt.
/interface ethernet switch set mirror-source=ether1 mirror-target=ether5 numbers=switch1Treiber Bezeichnung ist bei mir zwar e1i (also in dem Hinweis nicht gelistet), aber hab's trotzdem eingetragen, rebootet und gestaunt
Juhu, endlich sehe ich an einem Mirrorport auch VLAN Traffic. Diese Transparenz macht alles viel einfacher Das Finale:
- Der Mikrotik macht was er soll, und das mit meinem Ursprungseinstellungen
- Der TP-Link in der Version 1 mit seinem Default_Vlan ist natürlich für Traffic wie MNDP, STP, CPD und LLDP echt übel. Es gibt wohl einen Hack, wo an die Member-Ports im Binary der Firmware umstellen kann. Also Hex Editor....
- Bei mir läuft als Switch Ersatz ein anderer MT. Jetzt mit VLAN auf der Bridge, denn die Konfig auf dem Switch Chip hat bei mir nicht auf Anhieb gewünschtes geliefert.
Einen herzlichen Dank für die Unterstüzung gilt @aqui !
Jetzt hab ich endlich wieder die volle Kontrolle über mein Netz.
Vor dem ganzen Spektakel hier wollte ich eigentlich nur schnell intern auf IPv6 gehen und 2-3 Standorte mit VPN verbinden. So gehts also weiter ...
Frohe Ostern
Jetzt hab ich endlich wieder die volle Kontrolle über mein Netz.
👍 So sollte es sein !und 2-3 Standorte mit VPN verbinden. So gehts also weiter ...
Kein Thema mit Mikrotik, dazu gibts hier ja auch diverse Tutorials:Clientverbindung OpenVPN Mikrotik
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
usw.
Einen herzlichen Dank für die Unterstüzung
Immer gerne ! 
