10
Mikrotik RouterOS 7 MAC-Filter
Hallo an das Forum,
ich bin eine absoluter Neuling was das Router OS angeht. Ich sehe potential in den Geräten von Mikrotik und möchte gerne dazu lernen.
Dank der Hilfe dieser Community ist es mir gelungen mein Enterrasys Netzwerk auf Mikrotik zu Migrieren (Bin auf 10G umgestiegen da die Uplink-Ports der Switche hart am Limit sind). Das ist mir ehrlich gesagt ganz schön schwer gefallen. Ok das Netzwerk läuft aber ich weiß da geht noch mehr mit den MTs.
Darum habe ich mir ein kleines Testlabor zusammen gebastelt um damit rum zu probieren ohne gleich Kloppe von der Frau zu kassieren wenn ich mal den Internet Zugang für ne Stunde Schrotte.
Nun zu meinem Problem:
Ich habe folgende Hardware
zwei Switche CRS354-48P-4S+2Q+ und den CRS328-24P-4S+
zwei Router RB5009UPr+S+
Ganz Simple Übung (dachte ich)
Ich möchte an einem Port nur eine bestimmt MAC-Adresse zulassen (Bitte nicht kommentieren das jeder viertklässler das aushebeln könne) Es geht um die Übung.
Dazu habe ich folgendes gemacht:
Ein Bridge angelegt
Alle Ports auf die Bridge gepackt
auf der Bridge habe ich zwei Filter eingerichtet:
1. Forward-Chain Interface Src. Mac accept
2. Forward-Chain Interface drop
Also alle MAC-Adressen werden gedropt außer die eine nicht.
Klappt auf dem CRS354 wunderbar doch auf dem CRS328 nix
Da fließt nix durch, keine Pakete die weder durch Filter 1 noch 2 durch gehen, wohingegen auf dem CRS354 alles super ist.
Ich nutze zwei PoE Kameras als Clients die traffic produzieren.
Ich habe keinen Plan warum das nicht funktioniert und bin für jeden Tipp dankbar. Wenn ich Output's posten soll bitte sagen was ich da machen soll, bin wie gesagt noch Jungfräulich was die Console angeht.
Beste Grüße und eine schöne Weihnachtszeit
Darthbully
ich bin eine absoluter Neuling was das Router OS angeht. Ich sehe potential in den Geräten von Mikrotik und möchte gerne dazu lernen.
Dank der Hilfe dieser Community ist es mir gelungen mein Enterrasys Netzwerk auf Mikrotik zu Migrieren (Bin auf 10G umgestiegen da die Uplink-Ports der Switche hart am Limit sind). Das ist mir ehrlich gesagt ganz schön schwer gefallen. Ok das Netzwerk läuft aber ich weiß da geht noch mehr mit den MTs.
Darum habe ich mir ein kleines Testlabor zusammen gebastelt um damit rum zu probieren ohne gleich Kloppe von der Frau zu kassieren wenn ich mal den Internet Zugang für ne Stunde Schrotte.
Nun zu meinem Problem:
Ich habe folgende Hardware
zwei Switche CRS354-48P-4S+2Q+ und den CRS328-24P-4S+
zwei Router RB5009UPr+S+
Ganz Simple Übung (dachte ich)
Ich möchte an einem Port nur eine bestimmt MAC-Adresse zulassen (Bitte nicht kommentieren das jeder viertklässler das aushebeln könne) Es geht um die Übung.
Dazu habe ich folgendes gemacht:
Ein Bridge angelegt
Alle Ports auf die Bridge gepackt
auf der Bridge habe ich zwei Filter eingerichtet:
1. Forward-Chain Interface Src. Mac accept
2. Forward-Chain Interface drop
Also alle MAC-Adressen werden gedropt außer die eine nicht.
Klappt auf dem CRS354 wunderbar doch auf dem CRS328 nix
Da fließt nix durch, keine Pakete die weder durch Filter 1 noch 2 durch gehen, wohingegen auf dem CRS354 alles super ist.
Ich nutze zwei PoE Kameras als Clients die traffic produzieren.
Ich habe keinen Plan warum das nicht funktioniert und bin für jeden Tipp dankbar. Wenn ich Output's posten soll bitte sagen was ich da machen soll, bin wie gesagt noch Jungfräulich was die Console angeht.
Beste Grüße und eine schöne Weihnachtszeit
Darthbully
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 71330196299
Url: https://administrator.de/forum/mikrotik-routeros-7-mac-filter-71330196299.html
Ausgedruckt am: 22.04.2025 um 03:04 Uhr
10 Kommentare
Neuester Kommentar
Gesetzt den Fall 00:C0:12:34:0A:0B ist deine Client Mac Adresse dann sollte ein:
die ganze Magie erledigen solange auf beiden RouterOS rennt.
/interface bridge filter
add action=drop chain=forward in-bridge=<deine_bridge> in-interface=ether10 src-mac-address=!00:C0:12:34:0A:0B/FF:FF:FF:FF:FF:FF 
Da fließt nix durch, keine Pakete die weder durch Filter 1 noch 2 durch gehen
heißt das, die Regeln sprechen nicht an, aber Pakete gehen von Port zu Port oder gehen auch keine Pakete zwischen den Ports?Wenn nur die Regeln nicht ansprechen, vermute ich, dass Du auf den Ports des CRS328 HW-Offloading aktiv hast. Dann filtert die Firewall IMO nicht.
https://forum.mikrotik.com/viewtopic.php?t=139291#p686828
Viele Grüße, commodity
1
Guten Morgen,
Vielen Dank aqui für den Hinweis ich habe schon drüber nachgedacht es mit dem "nicht gleich" Filter zu probieren, sollte der nächste Schritt werden.
@commodity: Ja, war ungenaue beschrieben. Also ich hänge am ETH49 (mgmt port) vom CRS354 die Switche sind per SFP+ verbunden.
Beide Kameras kann ich auf Port 49 sehen. Ich sehe auch, dass beide Kameras auf der Bridge Traffic erzeugen sprich ich kann beide Kameras an beliebigen Ports aufrufen. Am CRS354 sehe ich das der Filter Pakete durchreicht. Am CRS328 nicht.
Ja deine Vermutung ist richtig, an beiden Switchen sind die Ports auf HW-Offloading gestellt.
Wenn ich den Haken rausnehme, dann geht es auch am CRS328 durch den Filter
Strange. Ich hätte erwartet, dass sich beide Switche "gleich" verhalten. Sollte ich das bei MT melden?
Auf jeden Fall lautet in diesem Fall die Lösung: Hardware Offload ausschalten.
Vielen Dank
Vielen Dank aqui für den Hinweis ich habe schon drüber nachgedacht es mit dem "nicht gleich" Filter zu probieren, sollte der nächste Schritt werden.
@commodity: Ja, war ungenaue beschrieben. Also ich hänge am ETH49 (mgmt port) vom CRS354 die Switche sind per SFP+ verbunden.
Beide Kameras kann ich auf Port 49 sehen. Ich sehe auch, dass beide Kameras auf der Bridge Traffic erzeugen sprich ich kann beide Kameras an beliebigen Ports aufrufen. Am CRS354 sehe ich das der Filter Pakete durchreicht. Am CRS328 nicht.
Ja deine Vermutung ist richtig, an beiden Switchen sind die Ports auf HW-Offloading gestellt.
Wenn ich den Haken rausnehme, dann geht es auch am CRS328 durch den Filter
Strange. Ich hätte erwartet, dass sich beide Switche "gleich" verhalten. Sollte ich das bei MT melden?
Auf jeden Fall lautet in diesem Fall die Lösung: Hardware Offload ausschalten.
Vielen Dank
Danke für's Feedback!
Vielleicht erreichst Du Dein Ziel besser mit ACLs oder Port Security.
Evtl. ist auch ein FW Offloading möglich. Das wird zwar nur für Layer 3 (also die IP-Firewall) beschrieben, aber vielleicht ist es beim Bridge Filtering auch möglich. Insgesamt ist das Offloading aber ein komplexes und (wie ich finde) verwirrendes Thema, weil man über viele Feinheiten stolpern kann. Ich würde es an Deiner Stelle zunächst über ACLs versuchen. Beachte, dass dafür HW-Offloading auf den Ports IMO wieder aktiv sein muss
Hab' ich aber alles auch noch nicht durch... Ist ja auch ein Wahn: Bridge Filter, IP Firewall Filter, Switch Filter... Und mit static ARP kann man da IMO auch noch was anstellen
Was die unterschiedliche Behandlung durch die beiden CRS angeht, ist das in der Tat verwunderlich. Evtl. hast Du auf dem 354 eine Einstellung vorgenommen, die das Offloading automatisch deaktiviert, weil der Traffic sowieso über die CPU muss. Genau kann man das nur durch Vergleich beider Konfigurationen untersuchen. Kannst ja für beide mal einen Export machen und mit einem Diff-Programm, zB Notepad++ und Compare-Plugin untersuchen.
Vielleicht hängt es aber auch hiermit zusammen:
Wenn Du Lust hast, kannst Du MT ja mal mit einer Supportanfrage befassen und das Forum mit der Antwort beglücken. Immerhin ist im Handbuch dazu nichts (ohne Weiteres) zu finden.
Viele Grüße, commodity
Auf jeden Fall lautet in diesem Fall die Lösung: Hardware Offload ausschalten.
Aber keine schöne. Den Traffic über die CPU zu schicken ist bei den Switches in Bezug auf die zur Verfügung stehenden Ressourcen eher problematisch. Zu Testzwecken ok.Vielleicht erreichst Du Dein Ziel besser mit ACLs oder Port Security.
Evtl. ist auch ein FW Offloading möglich. Das wird zwar nur für Layer 3 (also die IP-Firewall) beschrieben, aber vielleicht ist es beim Bridge Filtering auch möglich. Insgesamt ist das Offloading aber ein komplexes und (wie ich finde) verwirrendes Thema, weil man über viele Feinheiten stolpern kann. Ich würde es an Deiner Stelle zunächst über ACLs versuchen. Beachte, dass dafür HW-Offloading auf den Ports IMO wieder aktiv sein muss
Hab' ich aber alles auch noch nicht durch... Ist ja auch ein Wahn: Bridge Filter, IP Firewall Filter, Switch Filter... Und mit static ARP kann man da IMO auch noch was anstellen
Was die unterschiedliche Behandlung durch die beiden CRS angeht, ist das in der Tat verwunderlich. Evtl. hast Du auf dem 354 eine Einstellung vorgenommen, die das Offloading automatisch deaktiviert, weil der Traffic sowieso über die CPU muss. Genau kann man das nur durch Vergleich beider Konfigurationen untersuchen. Kannst ja für beide mal einen Export machen und mit einem Diff-Programm, zB Notepad++ und Compare-Plugin untersuchen.
Vielleicht hängt es aber auch hiermit zusammen:
These devices do not support Fasttrack or NAT connection offloading.
steht hier für den 328, während der 354 (bisschen tiefer im Link) das kann. Bridge Filter sind zwar weder Fasttrack noch NAT, aber offenbar kann der 354 mehr in Hardware machen als der 328.Wenn Du Lust hast, kannst Du MT ja mal mit einer Supportanfrage befassen und das Forum mit der Antwort beglücken. Immerhin ist im Handbuch dazu nichts (ohne Weiteres) zu finden.
Viele Grüße, commodity
Hallo commodity
vielen herzlichen Dank für deine Hinweise. Wie ich ja schrieb, komme ich eigentlich aus einer anderen Switch Welt und bin daher noch absolut grün hinter den Ohren was das OS und die Hardware angeht.
Es verhärtet sich bei mir die Vermutung, dass mit dem CRS354 etwas nicht stimmt. Ich habe ja zwei. Der im Testlabor verhält sich eindeutig anders als der im Produktiv-Netz.
Bedauerlicherweise habe ich bereits sehr sehr schlechte Erfahrung mit einer "Reparatur" gemacht. Port 1 der SFP1 Ports hat keinen Link bekommen. Modul in Port zwei rein, geht. Ich hab nen Fluke Linkrunner drangestöpselt, kein Link am Port 1.
Das Ding ging mit diesem Fehler zum Verkäufer, der in zu MT geschickt hat. Nach über zwei (!) Monaten kam das Gerät mit dem selben Fehler bei mir wieder an.
Ich bin fast im Dreieck gesprungen. Letztendlich hat sich dann der Händler eingesetzt und das Ruder rumgerissen und mir einen neuen geschickt. Das ist jetzt der, der im Testlabor hängt und der macht nun auch wieder komische Sachen?
Wie soll ich denn MT das erklären, dass der Switch offensichtlich auf alle Ports das HW-Offloading deaktiviert hat? Die Haken sind ja drin
Du Steckst da Client's ran und der Prügelt die Paket durch, ich schätze der kommt dann so wieder zurück.
Ich bau mir jetzt die Konfig so wie sie im Produktiv-Netz ist. Dann mache ich einen Export von beiden Switchen und schiebe das durch Ultracompare.
Sollte es sich zeigen, das der Switch im Labor-Netz anders, bei gleicher Konfig, reagiert, Kontaktiere ich MT. Ich werde auf jeden Fall hier berichten was bei rauskommt. Aber geht der zu MT dann wird es Monate dauern bis da ein Ergebnis zu erwarten ist.
Ich bedanke mich auf jeden Fall für deine Hinweise, sie helfen mir diese Welt zu verstehen (glaube ich )
Ich wünsche euch allen ein besinnliches Weihnachtsfest und sollten wir uns nicht mehr hören auch noch einen Guten Rutsch ins neue Jahr 2024
Euer Darthbully
vielen herzlichen Dank für deine Hinweise. Wie ich ja schrieb, komme ich eigentlich aus einer anderen Switch Welt und bin daher noch absolut grün hinter den Ohren was das OS und die Hardware angeht.
Es verhärtet sich bei mir die Vermutung, dass mit dem CRS354 etwas nicht stimmt. Ich habe ja zwei. Der im Testlabor verhält sich eindeutig anders als der im Produktiv-Netz.
Bedauerlicherweise habe ich bereits sehr sehr schlechte Erfahrung mit einer "Reparatur" gemacht. Port 1 der SFP1 Ports hat keinen Link bekommen. Modul in Port zwei rein, geht. Ich hab nen Fluke Linkrunner drangestöpselt, kein Link am Port 1.
Das Ding ging mit diesem Fehler zum Verkäufer, der in zu MT geschickt hat. Nach über zwei (!) Monaten kam das Gerät mit dem selben Fehler bei mir wieder an.
Ich bin fast im Dreieck gesprungen. Letztendlich hat sich dann der Händler eingesetzt und das Ruder rumgerissen und mir einen neuen geschickt. Das ist jetzt der, der im Testlabor hängt und der macht nun auch wieder komische Sachen?
Wie soll ich denn MT das erklären, dass der Switch offensichtlich auf alle Ports das HW-Offloading deaktiviert hat? Die Haken sind ja drin
Du Steckst da Client's ran und der Prügelt die Paket durch, ich schätze der kommt dann so wieder zurück.
Ich bau mir jetzt die Konfig so wie sie im Produktiv-Netz ist. Dann mache ich einen Export von beiden Switchen und schiebe das durch Ultracompare.
Sollte es sich zeigen, das der Switch im Labor-Netz anders, bei gleicher Konfig, reagiert, Kontaktiere ich MT. Ich werde auf jeden Fall hier berichten was bei rauskommt. Aber geht der zu MT dann wird es Monate dauern bis da ein Ergebnis zu erwarten ist.
Ich bedanke mich auf jeden Fall für deine Hinweise, sie helfen mir diese Welt zu verstehen (glaube ich
)Ich wünsche euch allen ein besinnliches Weihnachtsfest und sollten wir uns nicht mehr hören auch noch einen Guten Rutsch ins neue Jahr 2024
Euer Darthbully
1
Guten Morgen commodity,
es hat jetzt etwas gedauert. Ich habe beide Switche mit der "gleichen" Konfiguration versehen.
Natürlich weichen ein paar Punkte ab wie die IP-Adressen, Reihenfolge der VLAN-Taggings und auch die Reihenfolge der Filter. Inhaltlich sind sie aber gleich.
Interessant finde ich die Tatsache, dass Mikrotik die Konfig nicht "Sortiert". So habe ich auf meinem Produktiv-Switch alle Ports die nicht "Benutzt" sind, nicht an die Bridge gebunden, wobei ich im Labor-Netz einfach alle (schön der Reihenfolge) an die Bridge gebunden habe. Genau das sieht man nun im rsc File. Natürlich meckert Ultracompare an dieser Stelle.
Ok genug geschwafelt, Beide Switche verhalten sich gleich!
Da muss anfänglich noch irgendetwas anders gewesen sein, warum der Labor-Switch die Pakete trotz HW-Offloading durch die Filter geprügelt hat.
Leider kann ich das nicht mehr nachvollziehen was ich da gemacht habe.
Ich bedanke mich nochmal für deine Denkanstöße und schau mal wie ich solche Szenarien besser geregelt bekomme, ohne den Traffic über die CPU zu schieben.
@aqui: Deine Lösung funktioniert unter den selben Bedingungen "HW-Offloading aus". Hat aber die Besonderheit, dass man nur beim Dropen der Pakete sieht, dass der Filter "Arbeitet". Deine Methode ist deutlich effektiver, da nur ein Filter verwendet wird, was ich zukünftig nutzen würde. Zu Testzwecken ist es aber für mich momentan einfacher zu "sehen" ob der Filter anspricht.
Ich wünsche euch allen noch schöne Feiertage und einen Guten Rutsch ins neue Jahr
Euer Darthbully
es hat jetzt etwas gedauert. Ich habe beide Switche mit der "gleichen" Konfiguration versehen.
Natürlich weichen ein paar Punkte ab wie die IP-Adressen, Reihenfolge der VLAN-Taggings und auch die Reihenfolge der Filter. Inhaltlich sind sie aber gleich.
Interessant finde ich die Tatsache, dass Mikrotik die Konfig nicht "Sortiert". So habe ich auf meinem Produktiv-Switch alle Ports die nicht "Benutzt" sind, nicht an die Bridge gebunden, wobei ich im Labor-Netz einfach alle (schön der Reihenfolge) an die Bridge gebunden habe. Genau das sieht man nun im rsc File. Natürlich meckert Ultracompare an dieser Stelle.
Ok genug geschwafelt, Beide Switche verhalten sich gleich!
Da muss anfänglich noch irgendetwas anders gewesen sein, warum der Labor-Switch die Pakete trotz HW-Offloading durch die Filter geprügelt hat.
Leider kann ich das nicht mehr nachvollziehen was ich da gemacht habe.
Ich bedanke mich nochmal für deine Denkanstöße und schau mal wie ich solche Szenarien besser geregelt bekomme, ohne den Traffic über die CPU zu schieben.
@aqui: Deine Lösung funktioniert unter den selben Bedingungen "HW-Offloading aus". Hat aber die Besonderheit, dass man nur beim Dropen der Pakete sieht, dass der Filter "Arbeitet". Deine Methode ist deutlich effektiver, da nur ein Filter verwendet wird, was ich zukünftig nutzen würde. Zu Testzwecken ist es aber für mich momentan einfacher zu "sehen" ob der Filter anspricht.
Ich wünsche euch allen noch schöne Feiertage und einen Guten Rutsch ins neue Jahr
Euer Darthbully
Wenn du nur eine MAC am Port zulassen willst kannst du auch gleich 802.1x mit MAC Auth am Port aktivieren und den User-Manager als Radius Server auf dem Router benutzen, dann geht der Port erst in den Forwarding-State wenn sich dort die richtige MAC meldet.
https://help.mikrotik.com/docs/display/ROS/Dot1X
https://help.mikrotik.com/docs/display/ROS/User+Manager
Damit brauchst du keinerlei Firewall Regeln.
Pj
🎄🎆
https://help.mikrotik.com/docs/display/ROS/Dot1X
https://help.mikrotik.com/docs/display/ROS/User+Manager
Damit brauchst du keinerlei Firewall Regeln.
Pj
🎄🎆
1
Hallo pjumper,
vielen Dank für die Links.
Das 802.1x steht auf auf meinem plan. Ich hab schon einen RADIUS fürs WLAN am start.
Ich frag mich gerade wie man die Filter nutzt?
Offensichtlich funktionieren die Filter nur, wenn man das HW-Offloading aus macht.
Will ich die Firewall nutzen Meckert sie weil der Port als Slave auf der Bridge hängt.
Ich Blick da nicht durch wie sich MT sich das gedacht hat.
Beste Grüße
Euer Darthbully
vielen Dank für die Links.
Das 802.1x steht auf auf meinem plan. Ich hab schon einen RADIUS fürs WLAN am start.
Ich frag mich gerade wie man die Filter nutzt?
Offensichtlich funktionieren die Filter nur, wenn man das HW-Offloading aus macht.
Will ich die Firewall nutzen Meckert sie weil der Port als Slave auf der Bridge hängt.
Ich Blick da nicht durch wie sich MT sich das gedacht hat.
Beste Grüße
Euer Darthbully
Wenn man VLANs in einer Bridge nutzt kommen die Regeln immer auf das VLAN-Interface niemals auf die Bridge selbst.
Hardware-Offloading hat halt bei manchen Devices seinen Preis you get what you pay for.
Hardware-Offloading hat halt bei manchen Devices seinen Preis you get what you pay for.
1Sollte es sich zeigen, das der Switch im Labor-Netz anders, bei gleicher Konfig, reagiert, Kontaktiere ich MT.
Ich Blick da nicht durch wie sich MT sich das gedacht hat.
Danke für's Feedback. Der Weg ist nicht ohne, aber es lohnt sich, finde ich. Die Geräte sind saustabil und 99,99% der vermuteten Hardware-Fehler sind reine PICNIC-Probleme. Ich bin auch nur Klein-Nutzer, die Dinger werden aber weltweit im Unternehmensbereich eingesetzt, auch in Rechenzentren. EU/US hängen da etwas hinterher, mal sehen, wie lange noch.Ich Blick da nicht durch wie sich MT sich das gedacht hat.
Mit wachsendem ROS-Knowhow wächst auch das Verständnis für die Konzepte der Hardware-Entwicklung in Riga und es muss klar sein, dass nicht jedes Gerät jedes Feature in Wirespeed erledigt. Dies verstehen vor allem die Laien überhaupt nicht, die dann auch mit viel Energie den Support ausbremsen. Das Mikrotik-Forum ist voll von Threads, wo die Leute ihre (überflüssigen) Supportanfragen referenzieren.
Man muss das Konzept auch nicht mögen, es lohnt sich sicher nicht für alle Usecases. Für den ambitionierten Anwender mit Lust und Zeit auf Einarbeitung lohnt es sich sicher.
Viele Grüße, commodity
