VLAN Regel: Von A nach B aber nicht umgekehrt
Hallo zusammen
Ich lese schon eine Weile hier mit und nun brauche ich auch mal Hilfe und zwar mit meinem neuen Mikrotik Router (vom Provider gestellt...).
Soweit läuft alles, Basic Firewall ist aktiv, meine Config sieht etwa folgendermassen aus:
SFP28-2 = WAN
1 Bridge (=LAN) mit den VLANS 1 (Netzwerkgeräte), 20 (Clients), 30 (Guest WLAN), 40 (IOT) und 50 (Schliesssystem/Türklingel).
Grundsätzlich sind die VLANs isoliert, d.h. sie dürfen ins Internet und sonst nirgends hin. Dazu habe ich pro VLAN folgende Regel erstellt: chain: forward, In. Interface = VLANxx, Out. Interface = !SFP28-2, action = reject.
Nun möchte ich aber vom VLAN20, wo mein PC sitzt, Zugriff auf die VLANs 40 und 50. 40 und 50 dürfen aber keinen Zugriff auf 20 haben. Ich bin am verzweifeln und kriege es nicht hin... hat jemand den helfenden Tipp?
Danke schon mal!
Ich lese schon eine Weile hier mit und nun brauche ich auch mal Hilfe und zwar mit meinem neuen Mikrotik Router (vom Provider gestellt...).
Soweit läuft alles, Basic Firewall ist aktiv, meine Config sieht etwa folgendermassen aus:
SFP28-2 = WAN
1 Bridge (=LAN) mit den VLANS 1 (Netzwerkgeräte), 20 (Clients), 30 (Guest WLAN), 40 (IOT) und 50 (Schliesssystem/Türklingel).
Grundsätzlich sind die VLANs isoliert, d.h. sie dürfen ins Internet und sonst nirgends hin. Dazu habe ich pro VLAN folgende Regel erstellt: chain: forward, In. Interface = VLANxx, Out. Interface = !SFP28-2, action = reject.
Nun möchte ich aber vom VLAN20, wo mein PC sitzt, Zugriff auf die VLANs 40 und 50. 40 und 50 dürfen aber keinen Zugriff auf 20 haben. Ich bin am verzweifeln und kriege es nicht hin... hat jemand den helfenden Tipp?
Danke schon mal!
Please also mark the comments that contributed to the solution of the article
Content-ID: 7739417642
Url: https://administrator.de/contentid/7739417642
Printed on: October 10, 2024 at 04:10 o'clock
63 Comments
Latest comment
Ganz einfach, wie immer Schema "first match wins" ..
Somit wird auch nur die eine Richtung freigeschaltet. Interface Namen natürlich anpassen!!
Zeppel
# Interface Liste anlegen
/interface list add name=myVlanList
# Ziel-VLAN Interfaces als Member zur Liste hinzufugen
/interface list member
add interface=vlan40 list=myVlanList
add interface=vlan50 list=myVlanList
# Regel in der Forward Chain erstellen und nach ganz oben schieben, noch vor deine Reject Regel.
/ip firewall filter add chain=forward in-interface=vlan20 out-interface-list=myVlanList action=accept place-before=0
Zeppel
Hallo,
bevor ich etwas verbiete, muss es ja erst mal erlaubt sein.
"Erlaubt" heißt hier Routing.
Ist denn das Routing zw. den VLANs konfiguriert (Routing-Tabelle)?
Wenn das Routing zw den VLANs prinzipiell funktioniert (alle können alle in allen VLANs erreichen), kann ich durch FW-Regeln bestimmen, wer wohin darf oder auch nicht.
Jürgen
bevor ich etwas verbiete, muss es ja erst mal erlaubt sein.
"Erlaubt" heißt hier Routing.
Ist denn das Routing zw. den VLANs konfiguriert (Routing-Tabelle)?
Wenn das Routing zw den VLANs prinzipiell funktioniert (alle können alle in allen VLANs erreichen), kann ich durch FW-Regeln bestimmen, wer wohin darf oder auch nicht.
Jürgen
Mikrotik-Router routen für gewöhnlich Da muss grundsätzlich nichts konfiguriert werden (Ausnahme z.B. bei WireGuard).
Der Hinweis zum schrittweisen Vorgehen ist aber absolut sinnvoll. Zunächst könnte und sollte der TO schauen, ob die VLANs ohne FW-Rules erreicht werden könnten (ggf. mit einer any-any-Rule oder indem die o.b. Rule In. Interface = VLANxx, Out. Interface = !SFP28-2, action = reject kurz mal auf accept gestellt wird). Wenn das funktioniert, bedarf es der Konfiguration der Firewall - die man bei Mikrotik verstanden haben sollte - will man nicht die Welt bei sich zu hause haben
Bei korrekter Konfiguration der VLANs ist die Lösung des Kollegen @7426148943 (wie gewöhnlich) perfekt. Ebenso wichtig der Hinweis:
Viele Grüße, commodity
Der Hinweis zum schrittweisen Vorgehen ist aber absolut sinnvoll. Zunächst könnte und sollte der TO schauen, ob die VLANs ohne FW-Rules erreicht werden könnten (ggf. mit einer any-any-Rule oder indem die o.b. Rule In. Interface = VLANxx, Out. Interface = !SFP28-2, action = reject kurz mal auf accept gestellt wird). Wenn das funktioniert, bedarf es der Konfiguration der Firewall - die man bei Mikrotik verstanden haben sollte - will man nicht die Welt bei sich zu hause haben
Bei korrekter Konfiguration der VLANs ist die Lösung des Kollegen @7426148943 (wie gewöhnlich) perfekt. Ebenso wichtig der Hinweis:
"first match wins" ..
Viele Grüße, commodity
Selbst auf Position 0 bewirkt die Regel nichts, wenn meine rejects aktiv sind...
Die Regel müsste bei standardkonformer Erstellung der VLANs IMO greifen. @aqui">VLAN-Tutorial von @aqui verwendet?Du hast aber schon nicht nur die Rule übernommen, sondern den ganzen Inhalt der CodeBox oben?
Ansonsten gilt hier wie immer: Ein Config-Export vermeidet das Fischen im Trüben.
Viele Grüße, commodity
Zitat von @clancy:
Hallo alle und danke für die Unterstützung.
Die Geschichte mit dem first match wins hat so aber leider nicht funktioniert. Selbst auf Position 0 bewirkt die Regel nichts, wenn meine rejects aktiv sind...
Dann hast du wohl die Interface-Namen nicht richtig angepasst. Klappt einwandfrei sonst würde ich es hier nicht posten...Hallo alle und danke für die Unterstützung.
Die Geschichte mit dem first match wins hat so aber leider nicht funktioniert. Selbst auf Position 0 bewirkt die Regel nichts, wenn meine rejects aktiv sind...
Noch wer einen Hinweis?
Ja, export
auf der Konsole ausführen damit wir nicht im ... fischen müssen ist doch klar oder?! Fakten schwarz auf weiß zählen hier mehr als so dolle Worte wie "klappt nicht"...
Sieht für mich gut aus. Ich sehe keinen Grund, warum die Rule des Kollgen @7426148943 nicht greifen sollte. Evtl. hast Du Dich bei der Anpassung vertippt? Oder Du hast tatsächlich, wie Du schreibst,
Bitte - falls es dann immer noch nicht funktioniert - noch einen Export mit den eingearbeiteten Anpassungen.
Viele Grüße, commodity
nur meine Liste anders benamst...
Das wäre natürlich zu wenig, da Deine VLAN-Interfaces ja auch anders heißen. Z.B. ist vlan40 in Deinem Falle ja vlan40_iot.Bitte - falls es dann immer noch nicht funktioniert - noch einen Export mit den eingearbeiteten Anpassungen.
Viele Grüße, commodity
Dann hat deine verwendete uns unbekannte RouterOS-Version wohl einen Schuss oder Bug, das klappt hier im Test wie gesagt einwandfrei.
Also mal einen Reset ohne Defaults zu laden machen, neueste RouterOS Version flashen und Bootloader aktualisieren und clean neu konfigurieren.
Du solltest auch die Counter der Regel beobeachten und im Zweifel den Sniffer benutzen und das logging aktivieren.
Also mal einen Reset ohne Defaults zu laden machen, neueste RouterOS Version flashen und Bootloader aktualisieren und clean neu konfigurieren.
Du solltest auch die Counter der Regel beobeachten und im Zweifel den Sniffer benutzen und das logging aktivieren.
Zitat von @clancy:
RouterOS habe ich das aktuellste stable, 7.10.1. Soll ich mal auf die nächste DEV gehen?
Reset ohne Defaults zu laden oder cleanes NetInstall wenn man von der 6er kommt wäre erst mal der erste Weg, bevor man zur Dev geht.RouterOS habe ich das aktuellste stable, 7.10.1. Soll ich mal auf die nächste DEV gehen?
Ist der Bootloader ein separates File?
/system routerboard upgrade
/system reboot
An sich sollte das problemlos gehen aber evtl. lohnt es sich, mal die Unterstriche rauszunehmen.
Und: Hast Du denn verifiziert, ob die Interfaces in myVlanList eingetragen sind?
Screenshot?
Wie sieht es mit Logging aus? Man kann ja sehr schön für jede Regel das Logging aktivieren. Insbesondere auch die Block Rules würde ich zum Check hier mal loggen.
Die DEV bringt sicher nichts. Ich glaube nicht an einen Bug von ROS im Filtering. ROS ist IMO in den Basics sehr zuverlässig. Bei viel Konfig-Wirrwarr bleiben aber manchmal scheinbar Konfigurationsreste in den Geräten hängen (was ein Bug sein dürfte), die bei einem Clean-Install beseitigt werden. Das würde ich aber nur dann versuchen, wenn gar nichts anderes mehr passt.
Zum Updaten gibt es hier ein prima Script:
https://github.com/beeyev/Mikrotik-RouterOS-automatic-backup-and-update (ist auch sehr nützlich, wenn man es nicht automatisiert ausführt).
Viele Grüße, commodity
Und: Hast Du denn verifiziert, ob die Interfaces in myVlanList eingetragen sind?
Screenshot?
Wie sieht es mit Logging aus? Man kann ja sehr schön für jede Regel das Logging aktivieren. Insbesondere auch die Block Rules würde ich zum Check hier mal loggen.
Die DEV bringt sicher nichts. Ich glaube nicht an einen Bug von ROS im Filtering. ROS ist IMO in den Basics sehr zuverlässig. Bei viel Konfig-Wirrwarr bleiben aber manchmal scheinbar Konfigurationsreste in den Geräten hängen (was ein Bug sein dürfte), die bei einem Clean-Install beseitigt werden. Das würde ich aber nur dann versuchen, wenn gar nichts anderes mehr passt.
Zum Updaten gibt es hier ein prima Script:
https://github.com/beeyev/Mikrotik-RouterOS-automatic-backup-and-update (ist auch sehr nützlich, wenn man es nicht automatisiert ausführt).
Viele Grüße, commodity
müsste forward nicht heissen dass es durch geht?
"forward" hast Du selbst als Prefix gesetzt, korrekt? Wenn Du das bei Deiner Forward-Rule gemacht hast, und die Connection established ist, ist routerseitig an sich alles fein.Jetzt bitte noch torchen Ist ja ein Mikrotik.
Tools/Torch und dann das sendende Interface eingeben und starten. Sodann den Ping starten. Da solltest Du den ausgehenden Ping sehen. Wenn das der Fall ist, das empfangende Interface genauso torchen. Wenn da auch was ankommt, hast Du ein Problem mit dem Endgerät (was ich an sich ausschließen würde, da es ja ohne ausschließende Firewall-Rule geht, wie Du sagst).
Viele Grüße, commodity
nein, das ist kein prefix.
korrekt, das ist die Chain - und in Deinem Fall die Richtige.Die neue Rule macht ein reject (nur noch) für neue Pakete, die von vlan40_iot in alle Interfaces geforwardet werden, die nicht sfp28-2 sind. Ergo müssten alle Pakete, die nicht nach sfp28-2 gehen durchlaufen (wenn sie nicht von einer drop-all-rule gestoppt werden - die fehlt bei Dir ja aber noch). Die Regel entspricht ja Deiner Ursprungsregel, mit Ausnahme, dass nur neue Pakete gestoppt werden.
Das ist zum einen natürlich eine unsinnige Regel, weil vlan40_iot nun alle anderen VLANs erreicht und die Regel auch intransparent ist. Zum anderen erklärt sie für mich nicht, warum es nun gehen sollte, denn wenn neue Pakete gedropt werden, kommt ja keine Connection zustande.
Faustregel:
Ich habe keine Ahnung weshalb
nie, nie, nie in der Firewall auf einem Mikrotik. Das mag bei einer Fritzbox noch ungefährlich sein. Unter ROS ist es der beste Weg, Dein Netz und Deine Daten dem Rest Welt zugänglich zu machen.Jede Firewall-Regel, die (über die Standard-Firewall von MT hinaus) eingebaut wird, wird bitte zuvor verstanden. Du bist gewarnt.
Mir kommt ein vager Verdacht: Würdest Du mal bitte darstellen, wie Dein Internet angebunden ist? Gibt es im Netz noch einen anderen Router? Es ist insgesamt unglücklich, dass Du den Export kastriert hast. So kann man sich kein vollständiges Bild machen, das macht es deutlich schwieriger. Vielleicht beglückst Du die Runde mal mit einem vollständigen Export
Auch mein Vorschlag, die Connection zu torchen steht noch Torch ist ein absolutes Killerfeature und extrem hilfreich, um Netzwerkfehlern auf die Schliche zu kommen. Nicht einfach ignorieren, sondern bitte machen, wenn Zeit ist.
Unabhängig davon habe ich hier noch einen "Verdächtigen":
Diese Rule ist IMO definitiv fehlerhaft:
add action=drop chain=forward comment=\
"Drop incoming packets that are not NAT`ted" connection-nat-state=!dstnat \
connection-state=new in-interface=LAN log=yes log-prefix=!NAT
Für's Erste: Diese Rule mal deaktivieren (oder erstmal loggen und schauen, ob sie anschlägt), dann nochmals @zeppels Vorschlag einbauen und schauen.
Viele Grüße, commodity
Zitat von @commodity:
Die neue Rule macht ein reject (nur noch) für neue Pakete, die von vlan40_iot in alle Interfaces geforwardet werden, die nicht sfp28-2 sind. Ergo müssten alle Pakete, die nicht nach sfp28-2 gehen durchlaufen (wenn sie nicht von einer drop-all-rule gestoppt werden - die fehlt bei Dir ja aber noch). Die Regel entspricht ja Deiner Ursprungsregel, mit Ausnahme, dass nur neue Pakete gestoppt werden.
Sorry, das war etwas wirr (langer Tag vermutlich).Die neue Rule macht ein reject (nur noch) für neue Pakete, die von vlan40_iot in alle Interfaces geforwardet werden, die nicht sfp28-2 sind. Ergo müssten alle Pakete, die nicht nach sfp28-2 gehen durchlaufen (wenn sie nicht von einer drop-all-rule gestoppt werden - die fehlt bei Dir ja aber noch). Die Regel entspricht ja Deiner Ursprungsregel, mit Ausnahme, dass nur neue Pakete gestoppt werden.
Also dieser Teil ist falsch:
Ergo müssten alle Pakete, die nicht nach sfp28-2 gehen durchlaufen
Die Rule rejected alle neuen Pakete von 40 nach überall - außer WAN. Und hat mit Deiner "Lösung" (20 nach 40 funktioniert) nichts zu tun.Von einem Rechner im VLAN40 kann ich nix im VLAN20 pingen.
Dieses Ergebnis ist also mit der Regel völlig korrekt. Und hat nichts mit der Strecke von 20 nach 40 zu tun.Die Fasttrack-Regel kannst Du zum Testen immer weglassen, die hat aber auch nichts mit dem Grundproblem zu tun. Die verhindert nur, dass Pakete aus bekannten Connections (also nicht "new") weiter durch die Firewall laufen. Sie verhindert aber wahrscheinlich, dass Deine selektiven Deaktivierungs-Tests nicht wie erwartet funktionieren. Zum debuggen schalte das ruhig mal aus.
Du willst ja von 20 nach 40 (und 50), korrekt?
Also fangen wir nochmals ganz oben an:
/ip firewall filter add chain=forward in-interface=vlan20_intern out-interface=vlan40_iot action=accept place-before=0
Edit: Den Ping machst Du aber schon von einem Rechner im VLAN 20, oder? Nicht mit dem Mikrotik-Tool?
Viele Grüße, commodity
Ich würde dir dringend empfehlen dich erst mal mit den Grundlagen einer iptables Firewall und dessen chains zu beschäftigen, denn ohne dieses Grundwissen wirst du nicht glücklich werden und verstehst den Grundgedanken einer "statefull" Firewall und die Reihenfolge der Abarbeitung nicht.
Ich tippe darauf das du statt die VLAN-Interfaces in die Interface-Listen einzutragen die physischen Ports dort eingetragen hast dort müssen zwingend die VLAN-Interfaces eingetragen werden!!
Hier mal eine ganz simple statefull FW jetzt erst mal ohne viel extra Schnickschnack , die definitiv funktioniert, mit der du erst mal anfangen solltest um darauf Schritt für Schritt aufzubauen:
Device in vlan20 Pingversuch an Device in vlan40_iot erfolgreich
Device in vlan40_iot Pingversuch an Device in vlan20 wie erwartet nicht erfolgreich
Ins Internet können trotzdem beide.
Works as designed!
Hier mal eine ganz simple statefull FW jetzt erst mal ohne viel extra Schnickschnack , die definitiv funktioniert, mit der du erst mal anfangen solltest um darauf Schritt für Schritt aufzubauen:
/interface list
add name=WAN
add name=LAN
/interface list member
add interface=ether1 list=WAN
add interface=vlan20 list=LAN
add interface=vlan40_iot list=LAN
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip firewall filter
add action=accept chain=input comment="input accepted/related" connection-state=established,related
add action=accept chain=forward comment="forward established/related" connection-state=established,related
add action=drop chain=forward comment="invalid forward" connection-state=invalid
add action=accept chain=forward comment="accept dstnat connections" connection-nat-state=dstnat in-interface-list=WAN
add action=accept chain=input comment="allow management" in-interface-list=LAN
add action=accept chain=input comment="Allow icmp from LAN" in-interface-list=LAN protocol=icmp
add action=accept chain=input comment="DNS input" dst-port=53 in-interface-list=LAN protocol=tcp
add action=accept chain=input comment="DNS input" dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=forward comment="Allow forward LAN => WAN" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow vlan20 => vlan40_iot" in-interface=vlan20 out-interface=vlan40_iot
add action=drop chain=input comment="General input drop"
add action=drop chain=forward comment="general forward drop"
Device in vlan20 Pingversuch an Device in vlan40_iot erfolgreich
Device in vlan40_iot Pingversuch an Device in vlan20 wie erwartet nicht erfolgreich
Ins Internet können trotzdem beide.
Works as designed!
Zitat von @commodity:
Ja, ganz von vorn finde ich auch gut. Zunächst aber mal sehen, ob die o.a. Regel nun endlich greift. Vielleicht ist es ja doch ein Bug? Ich hatte, als Deine Regel nicht ansprach zunächst die Unterstriche beim TO im Verdacht, konnte dazu aber nichts negatives finden.
Unterstriche machen nichts, das sind gültige Zeichen für Interfaces, aber ich tippe bei ihm darauf das er statt die VLAN-Interfaces in die Interface-Listen einzutragen die physischen Ports dort eingetragen hat, dort müssen ja zwingend die VLAN-Interfaces eingetragen werden. Wenn dort die physischen Ports hinterlegt wären können die Regeln aus Prinzip nicht richtig greifen. Das würde das totale Chaos bei ihm erklären. Dass machen Anfänger hier gerne mal falsch.Ja, ganz von vorn finde ich auch gut. Zunächst aber mal sehen, ob die o.a. Regel nun endlich greift. Vielleicht ist es ja doch ein Bug? Ich hatte, als Deine Regel nicht ansprach zunächst die Unterstriche beim TO im Verdacht, konnte dazu aber nichts negatives finden.
Genau der Part fehlt eben , deswegen ist dieser partielle Post auch mist und man erhält dadurch kein Gesamtbild wie du auch schon geschrieben hast ...
Dann ist genau das dein Problem, weil die Basis-Firewall Regeln darauf basieren . Lege sie an und alles wird gut. Nur Regeln aus dem Mikrotik Forum kopieren ohne die dafür essentiellen Bestandteile auch einzufügen kann nicht funktionieren .
/interface list
add name=WAN
add name=LAN
/interface list member
add interface=sfp28-2 list=WAN
add interface=vlan20 list=LAN
add interface=vlan40_iot list=LAN
# ...
# ..
Der Part fehlt weil er nicht existiert. Ich habe keine Interfacelisten.
Was erstaunlich ist, denn wenn Du die Anregung des Kollgen @7426148943 umgesetzt hättest, hättest Du mindestens eine.Und jeder Mikrotik-Router hat in seiner (sicheren) Standardkonfiguration auch solche:
Du hast - ohne Kenntnisse von einer Firewall - die Standardfirewall gelöscht und dann mit den Hinweisen aus dem Wiki gebastelt? Na gute Nacht.
Selbst wenn wir das hier hinbekommen (was sagt denn die Rule oben?) gilt hier: Da capo
Viele Grüße, commodity
weiter oben hat's noch geheissen sieht gut aus
Gut sah der erste Eindruck aus. Der ist ja nun lange widerlegt. Gut sieht der Teil aus, der ohne Veränderung abgekupfert wurde. Anspruch muss bei einer Firewall schon sein, jede Regel zu verstehen. Sonst ist der Schutz schnell passé.Wenn Du da aber noch ein bisschen Energie reinsteckst, wird das schon. Die VLANs hast Du ja fein hinbekommen.
Geht denn die Regel von 10:57 Uhr nun bei Dir oder nicht? Dein Einsatz lässt nach!
Viele Grüße, commodity
Das ist jetzt aber unbefriedigend!
Ich hätte ja gern noch herausgefunden, wo genau das Problem lag...
Nun gut. "Geht jetzt" ist ja auch schon ein Erfolg - darum geht es ja eigentlich
Und Respekt, Du lernst schnell. Bleib dran. Mikrotik eröffnet dem, der sich darauf einlässt, neue Welten. Falls einen das "langweilige" Netzwerken denn irgendwie interessiert.
Diese Regeln verstehe ich nicht alle (was nicht heißt, dass sie nicht sinnvoll sind):
1) Die Liste darf alles, was input ist. Sehr weitgehend - warum? Für wen? Den "LAN-Admin" hattest Du doch schon weiter oben berechtigt. Und auch das ohne Grenzen. Bei mir sind da nur Winbox, Webfig, SSH, VPNs, NTP und DNS erlaubt.
2) Da kenne ich mich nicht aus. Ich habe noch nie IGMP-Rules gemacht. Kann trotzdem Fernsehen - hab' aber auch kein IPTV Und mich auch noch nicht näher damit beschäftigt.
Die Anleitung bei Mikrotik erwähnt keine Firewall-Rules. Ebenso die "First Firewall" und die "Advanced Firewall" im Wiki erwähnt keine IGMP-Rules. Vielleicht weiß jemand anders da mehr.
Mein Provider empfiehlt, IGMP-Snooping zu deaktivieren, weil es negative Einflüsse auf die IP-Telefonie haben kann.
Wenn es Dich interessiert, mach vielleicht einen neuen Thread auf, dann klinken sich die echten Netzwerker wie z.B. @aqui oder @LordGurke vielleicht ein.
3) Das ist Wireguard, korrekt? Wenn Du das nutzt, macht die Regel Sinn. BTW: Jede Regel sollte ein Comment von Dir bekommen, damit Du in zwei Jahren auch noch weißt, wofür das ist.
4) Der Zweck der Regel ist mir nicht ganz klar. Offenbar sollen keine nichtöffentlichen IP-Adressen außerhalb der Bridge erreicht werden, so z.B. Geräte am Management-Port. Was sonst, weiß ich nicht. Macht aber sicher Sinn, denn ist ja Bestandteil der "first Firewall".
Ich gebe im Forward (vor der drop-all-Regel) prinzipiell nur Ziele und Dienste weiter, die benötigt werden, dann ist so eine allgemeine Regel verzichtbar. Aber sie bietet zusätzlichen Schutz.
Zum Schluss noch eine Frage: Was ist das für ein Provider, der Mikrotik-Router anbietet? Muss ja ein fortschrittlicher sein Hoffentlich muss er das nicht supporten. Und wir auch nicht
Viele Grüße, commodity
Ich hätte ja gern noch herausgefunden, wo genau das Problem lag...
Nun gut. "Geht jetzt" ist ja auch schon ein Erfolg - darum geht es ja eigentlich
Und Respekt, Du lernst schnell. Bleib dran. Mikrotik eröffnet dem, der sich darauf einlässt, neue Welten. Falls einen das "langweilige" Netzwerken denn irgendwie interessiert.
Diese Regeln verstehe ich nicht alle (was nicht heißt, dass sie nicht sinnvoll sind):
1) add action=accept chain=input src-address-list=allowed_to_router
2) add action=accept chain=input comment="Allow igmp" log=yes protocol=igmp
3) add action=accept chain=input dst-port=13231 in-interface-list=WAN protocol=udp
4) add action=drop chain=forward comment="Drop tries to reach not public addresses from LAN" dst-address-list=not_in_internet in-interface=vlan-bridge log=yes log-prefix=!public_from_LAN \
out-interface=!vlan-bridge
1) Die Liste darf alles, was input ist. Sehr weitgehend - warum? Für wen? Den "LAN-Admin" hattest Du doch schon weiter oben berechtigt. Und auch das ohne Grenzen. Bei mir sind da nur Winbox, Webfig, SSH, VPNs, NTP und DNS erlaubt.
2) Da kenne ich mich nicht aus. Ich habe noch nie IGMP-Rules gemacht. Kann trotzdem Fernsehen - hab' aber auch kein IPTV Und mich auch noch nicht näher damit beschäftigt.
Die Anleitung bei Mikrotik erwähnt keine Firewall-Rules. Ebenso die "First Firewall" und die "Advanced Firewall" im Wiki erwähnt keine IGMP-Rules. Vielleicht weiß jemand anders da mehr.
Mein Provider empfiehlt, IGMP-Snooping zu deaktivieren, weil es negative Einflüsse auf die IP-Telefonie haben kann.
Wenn es Dich interessiert, mach vielleicht einen neuen Thread auf, dann klinken sich die echten Netzwerker wie z.B. @aqui oder @LordGurke vielleicht ein.
3) Das ist Wireguard, korrekt? Wenn Du das nutzt, macht die Regel Sinn. BTW: Jede Regel sollte ein Comment von Dir bekommen, damit Du in zwei Jahren auch noch weißt, wofür das ist.
4) Der Zweck der Regel ist mir nicht ganz klar. Offenbar sollen keine nichtöffentlichen IP-Adressen außerhalb der Bridge erreicht werden, so z.B. Geräte am Management-Port. Was sonst, weiß ich nicht. Macht aber sicher Sinn, denn ist ja Bestandteil der "first Firewall".
Ich gebe im Forward (vor der drop-all-Regel) prinzipiell nur Ziele und Dienste weiter, die benötigt werden, dann ist so eine allgemeine Regel verzichtbar. Aber sie bietet zusätzlichen Schutz.
Zum Schluss noch eine Frage: Was ist das für ein Provider, der Mikrotik-Router anbietet? Muss ja ein fortschrittlicher sein Hoffentlich muss er das nicht supporten. Und wir auch nicht
Viele Grüße, commodity
Mikrotik kann man nicht supporten Guck mal ins dortige Forum. Da bist Du nach zwei Jahren in der Anstalt.
Kompliziert ja, aber guuut
Kauf Ihr Netflix, dann braucht sie das IPTV nicht mehr. Und Mediatheken gibt's doch auch sicher in der Schweiz. Wer guckt denn heute noch linear?
Und einmal hübsch essen gehen, weil Du so lange am Router gehangen hast
Viele Grüße in die Schweiz, commodity
Kompliziert ja, aber guuut
Frau ist jetzt halt ziemlich angepisst 😂
Dürfen Frauen in der Schweiz schon fernsehen? Kauf Ihr Netflix, dann braucht sie das IPTV nicht mehr. Und Mediatheken gibt's doch auch sicher in der Schweiz. Wer guckt denn heute noch linear?
Und einmal hübsch essen gehen, weil Du so lange am Router gehangen hast
Viele Grüße in die Schweiz, commodity
Zitat von @clancy:
jetzt noch die letzte Frage (hoffentlich): Fasttrack ist noch immer deaktiviert. Braucht es das? Und wenn ja, wohin gehört die Regel, ganz an die Spitze?
Ja sie ist nützlich und entlastet die Hardware vor unnötigen Durchlauferhitzungen in der Firewall, kommt vor die established, related Regel in der "forward"-Chain.jetzt noch die letzte Frage (hoffentlich): Fasttrack ist noch immer deaktiviert. Braucht es das? Und wenn ja, wohin gehört die Regel, ganz an die Spitze?
Man sollte dann aber beachten das man bei aktiven IPSEC Verbindungen diese vom Fasttrack ausnehmen muss, genauso wenn man mit Mangle-Rules arbeitet und Connections mit Routing-Marks oder Connection-Tags versieht, denn diese müssen zwingend die Firewall passieren damit sie funktionieren.
macht man bspw. so in der Forward-Chain
/ip firewall filter
add action=accept chain=forward comment="IPSEC IN - fasttrack bypass" ipsec-policy=in,ipsec
add action=accept chain=forward comment="IPSEC OUT - fasttrack bypass" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="Fasttrack connections" connection-mark=no-mark connection-state=established,related hw-offload=yes
Absolut essentiell für das Verständnis der Regelabarbeitung sind folgende Charts
https://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Das würde ich dir auch ans Herz legen mal da drüber zu schauen, lernt man sehr viel von.
Nein, offen wie ein Scheunentor. 😋
Wenn man sich selbst nicht sicher ist sollte man die Finger davon lassen oder sich erst vernünftig einlesen und jede Regel zu 100% verstehen! Never trust anyone else only yourself!
It's friday, i'm out ... 🐟
Wenn man sich selbst nicht sicher ist sollte man die Finger davon lassen oder sich erst vernünftig einlesen und jede Regel zu 100% verstehen! Never trust anyone else only yourself!
It's friday, i'm out ... 🐟
Provider lieferte die notwendigen hints...
Wären ja auch mal für die Community hier interessant, der Sinn eines Forums. Zumal es bei MT wie bei anderen Routern ja 2 Optionen gibt es über den Proxy laufen zu lassen oder sauber per PIM zu routen wie es auch hier für Magenta TV beschrieben ist.
Mikrotik Multicast Routing
Multicast Troubleshooting
Zitat von @clancy:
Dem Smiley und der hoffentlich vorhandenen Experten-Ehre entnehme ich jetzt mal dass es passt.
Nein tut es lieder nicht, das war so gemeint wie ich es geschrieben habe ...Dem Smiley und der hoffentlich vorhandenen Experten-Ehre entnehme ich jetzt mal dass es passt.
add action=accept chain=input in-interface=sfp28-2 protocol=udp
add action=accept chain=forward in-interface=sfp28-2 out-interface=vlan-bridge protocol=udp
Ich sagte ja, never trust anyone with blind eyes, only yourself! Damit lassen sich allerhand Schweinereien vom WAN aus durchführen ..
Ja auf jeden Fall. Und auch die Multicast-Subnets in der Destination am Input aufführen!
Jain. kommt halt auf den jeweiligen Provider an, enthält jetzt zwar sämtliche Multicast-Bereiche das würde ich noch weiter einschränken. Die zweite Regel muss aber in die Forward und nicht in die INPUT-Chain Aber generell geht es in die richtige Richtung.
p.s. Ein Wireshark Trace verrät dir viel was da so auf der Leitung diesbezüglich abgeht dann versteht man das ganze auch viel besser .
Firewall üben kann man auch gut virtuell machen, da lernt man sehr viel dabei.
p.s. Ein Wireshark Trace verrät dir viel was da so auf der Leitung diesbezüglich abgeht dann versteht man das ganze auch viel besser .
Firewall üben kann man auch gut virtuell machen, da lernt man sehr viel dabei.
Den Beitrag dann bitte noch auf gelöst setzen. Das Thema der Frage ist ja nun schon erledigt!
Zitat von @clancy:
interessant, das ist die config vom provider, damit IPTV läuft...
add action=accept chain=input in-interface=sfp28-2 protocol=udp
add action=accept chain=forward in-interface=sfp28-2 out-interface=vlan-bridge protocol=udp
Der Provider ist ja gut drauf!
Diese Konfig meinte @aqui sicherlich nicht
Arbeite Dich da rein und dann schickst Du dem Provider die richtige Version
Viele Grüße, commodity
Der Auszug oben offenbart 2 Kardinalsfehler:
- Der UDP Zugang auf das Internet Interface ist offen wie ein Scheunentor. Kollege @7426148943 hat es oben schon gesagt. Zumindestens das hat der TO ja in der korrigierten Version gefixt.
- Ein out-interface=vlan-bridge offenbart eine grobe Fehlkonfiguration der VLAN Bridge, denn in einem VLAN Setup wird niemals Traffic auf das Bridge Interface gesendet. Das Bridge Interface darf keinesfalls aktiv benutzt werden fürs IP Forwarding und hat auch keine IP. Das MT VLAN Tutorial weist extra in rot auf diesen Umstand hin!
igmp V2 statt V3 einstellen
Das ist zwingend erforderlich wenn der Provider SSM Multicast verwendet (z.B. Magenta TV), denn das rennt ausschliesslich nur mit IGMPv3!Nein, dazu kenne ich mich zu wenig aus
Guckst du hier. 😉