04.07.2023

7241

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!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 7739417642

Url: https://administrator.de/forum/vlan-regel-von-a-nach-b-aber-nicht-umgekehrt-7739417642.html

Ausgedruckt am: 21.12.2024 um 13:12 Uhr

63 Kommentare

Neuester Kommentar

Ganz einfach, wie immer Schema "first match wins" ..

# 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

Somit wird auch nur die eine Richtung freigeschaltet. Interface Namen natürlich anpassen!!

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

Zitat von @chiefteddy:
Ist denn das Routing zw. den VLANs konfiguriert (Routing-Tabelle)?

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:

"first match wins" ..

Viele Grüße, commodity

Hallo alle und danke für die Unterstützung.

Ja, dass der Router routet habe ich verstanden (musste mich da umgewöhnen von z.B. Zyxel Firewalls). Wenn ich die reject Regeln deaktiviere, dann funktioniert der VLAN-übergreifende Zugriff. 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?

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...

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"...

Zitat von @commodity:

Die Regel müsste bei standardkonformer Erstellung der VLANs IMO greifen. @aqui">VLAN-Tutorial von @aqui verwendet?

Wie es der Zufall will habe ich exakt diese Anleitung verwendet (wusste nicht mehr, dass ich die von hier hatte)

Du hast aber schon nicht nur die Rule übernommen, sondern den ganzen Inhalt der CodeBox oben?

Ja, den ganzen Inhalt, habe nur meine Liste anders benamst...

Hier meine config (Auszug). Die FW Basics habe ich aus einem Mikrotik Tutorial. Die oben genannte Regel ist nicht angewendet, das ist die ursprüngliche Ausgangslage. SFP 8-10 sind APs, wobei auf der 10 der Mesh-Master ist. SFP11 ist mein Switch. SFP 1 und 2 sind IPTVs.

/interface bridge port
add bridge=LAN frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=no interface=sfp-sfpplus1 pvid=21
add bridge=LAN frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=no interface=sfp-sfpplus2 pvid=21
add bridge=LAN frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=no interface=sfp-sfpplus3 pvid=21
add bridge=LAN frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=no interface=sfp-sfpplus4
add bridge=LAN frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=no interface=sfp-sfpplus5
add bridge=LAN frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=no interface=sfp-sfpplus6
add bridge=LAN frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=no interface=sfp-sfpplus7
add bridge=LAN ingress-filtering=no interface=sfp-sfpplus8
add bridge=LAN ingress-filtering=no interface=sfp-sfpplus10
add bridge=LAN ingress-filtering=no interface=sfp-sfpplus11
add bridge=LAN ingress-filtering=no interface=sfp-sfpplus12
add bridge=LAN frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=no interface=ether1
add bridge=LAN ingress-filtering=no interface=sfp-sfpplus9
/ip neighbor discovery-settings
set discover-interface-list=none
/ip settings
set max-neighbor-entries=8192
/ipv6 settings
set disable-ipv6=yes max-neighbor-entries=8192
/interface bridge vlan
add bridge=LAN tagged=LAN untagged=sfp-sfpplus10,sfp-sfpplus9,sfp-sfpplus8 \
    vlan-ids=1
add bridge=LAN tagged=\
    LAN,sfp-sfpplus10,sfp-sfpplus9,sfp-sfpplus8,sfp-sfpplus11,sfp-sfpplus12 \
    vlan-ids=20
add bridge=LAN tagged=\
    LAN,sfp-sfpplus10,sfp-sfpplus9,sfp-sfpplus8,sfp-sfpplus11,sfp-sfpplus12 \
    vlan-ids=30
add bridge=LAN tagged=\
    LAN,sfp-sfpplus10,sfp-sfpplus9,sfp-sfpplus8,sfp-sfpplus11,sfp-sfpplus12 \
    vlan-ids=40
add bridge=LAN tagged=\
    LAN,sfp-sfpplus10,sfp-sfpplus8,sfp-sfpplus9,sfp-sfpplus11,sfp-sfpplus12 \
    vlan-ids=21
add bridge=LAN tagged=sfp-sfpplus11,LAN vlan-ids=50
/interface l2tp-server server
set authentication=mschap2 default-profile=L2TP-VPN enabled=yes max-mru=1480 \
    max-mtu=1460 use-ipsec=yes

/ip address
add address=192.168.1.1/24 interface=vlan1_admin network=192.168.1.0
add address=192.168.20.1/24 interface=vlan20_intern network=192.168.20.0
add address=192.168.30.1/24 interface=vlan30_guest network=192.168.30.0
add address=192.168.40.1/24 interface=vlan40_iot network=192.168.40.0
add address=192.168.21.1/24 interface=vlan21_iptv network=192.168.21.0
add address=192.168.100.1/24 interface=wireguard1 network=192.168.100.0
add address=192.168.50.1/24 interface=vlan50_doorbird network=192.168.50.0

/ip firewall address-list
add address=192.168.1.0/24 list=allowed_to_router
add address=0.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=172.16.0.0/12 comment=RFC6890 list=not_in_internet
add address=192.168.0.0/16 comment=RFC6890 list=not_in_internet
add address=10.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=169.254.0.0/16 comment=RFC6890 list=not_in_internet
add address=127.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=224.0.0.0/4 comment=Multicast disabled=yes list=not_in_internet
add address=198.18.0.0/15 comment=RFC6890 list=not_in_internet
add address=192.0.0.0/24 comment=RFC6890 list=not_in_internet
add address=192.0.2.0/24 comment=RFC6890 list=not_in_internet
add address=198.51.100.0/24 comment=RFC6890 list=not_in_internet
add address=203.0.113.0/24 comment=RFC6890 list=not_in_internet
add address=100.64.0.0/10 comment=RFC6890 list=not_in_internet
add address=240.0.0.0/4 comment=RFC6890 list=not_in_internet
add address=192.88.99.0/24 comment="6to4 relay Anycast [RFC 3068]" list=\  
    not_in_internet
add address=192.168.20.0/24 list=allowed_to_router


/ip firewall filter
add action=accept chain=input comment="Accept established, related" \  
    connection-state=established,related
add action=accept chain=input src-address-list=allowed_to_router
add action=accept chain=input disabled=yes protocol=icmp
add action=accept chain=input log=yes protocol=igmp
add action=accept chain=input dst-port=123 in-interface=LAN protocol=udp
add action=accept chain=input dst-port=13231 in-interface=sfp28-2 protocol=udp
add action=drop chain=input log=yes
add action=fasttrack-connection chain=forward comment=FastTrack \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related \
    connection-type=""  
add action=drop chain=forward comment="Drop invalid" connection-state=invalid \  
    log=yes log-prefix=invalid
add action=drop chain=forward comment=\
    "Drop tries to reach not public addresses from LAN" dst-address-list=\  
    not_in_internet in-interface=LAN log=yes log-prefix=!public_from_LAN \
    out-interface=!LAN
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
add action=reject chain=forward in-interface=vlan30_guest out-interface=\
    !sfp28-2 reject-with=icmp-network-unreachable
add action=reject chain=forward disabled=yes in-interface=vlan40_iot log=yes \
    out-interface=!sfp28-2 reject-with=icmp-network-unreachable
add action=reject chain=forward in-interface=vlan50_doorbird out-interface=\
    !sfp28-2 reject-with=icmp-network-unreachable
/ip firewall nat
add action=masquerade chain=srcnat out-interface=sfp28-2 to-addresses=0.0.0.0
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set h323 disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip ipsec policy
set 0 dst-address=0.0.0.0/0 src-address=0.0.0.0/0
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh address=192.168.1.0/24 port=xxxx
set api disabled=yes
set winbox address=192.168.1.0/24,192.168.20.0/24 port=xxxxx
set api-ssl disabled=yes

/ip firewall nat
add action=masquerade chain=srcnat out-interface=sfp28-2 to-addresses=0.0.0.0
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set h323 disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip ipsec policy
set 0 dst-address=0.0.0.0/0 src-address=0.0.0.0/0
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh address=192.168.1.0/24 port=xxxx
set api disabled=yes
set winbox address=192.168.1.0/24,192.168.20.0/24 port=xxxxx
set api-ssl disabled=yes
/ip ssh
set strong-crypto=yes
/ppp secret
add name=vpn-user profile=L2TP-VPN service=l2tp
/routing igmp-proxy
set quick-leave=yes
/routing igmp-proxy interface
add interface=vlan21_iptv
add alternative-subnets=0.0.0.0/0 interface=sfp28-2 upstream=yes
/system clock
set time-zone-name=Europe/Zurich
/system note
set show-at-login=no
/system ntp client
set enabled=yes
/system ntp server
set enabled=yes manycast=yes multicast=yes
/system ntp client servers
add address=ch.pool.ntp.org
add address=pool.ntp.org
/system resource irq rps
set ether1 disabled=no
/system script
add dont-require-permissions=no name=bogus owner=xxxxx policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="/ip\  
    \_firewall address-list\r\
    \nadd address=0.0.0.0/8 comment=RFC6890 list=not_in_internet\r\
    \nadd address=172.16.0.0/12 comment=RFC6890 list=not_in_internet\r\
    \nadd address=192.168.0.0/16 comment=RFC6890 list=not_in_internet\r\
    \nadd address=10.0.0.0/8 comment=RFC6890 list=not_in_internet\r\
    \nadd address=169.254.0.0/16 comment=RFC6890 list=not_in_internet\r\
    \nadd address=127.0.0.0/8 comment=RFC6890 list=not_in_internet\r\
    \nadd address=224.0.0.0/4 comment=Multicast list=not_in_internet\r\
    \nadd address=198.18.0.0/15 comment=RFC6890 list=not_in_internet\r\
    \nadd address=192.0.0.0/24 comment=RFC6890 list=not_in_internet\r\
    \nadd address=192.0.2.0/24 comment=RFC6890 list=not_in_internet\r\
    \nadd address=198.51.100.0/24 comment=RFC6890 list=not_in_internet\r\
    \nadd address=203.0.113.0/24 comment=RFC6890 list=not_in_internet\r\
    \nadd address=100.64.0.0/10 comment=RFC6890 list=not_in_internet\r\
    \nadd address=240.0.0.0/4 comment=RFC6890 list=not_in_internet\r\
    \nadd address=192.88.99.0/24 comment=\"6to4 relay Anycast [RFC 3068]\" list=\  
    not_in_internet"  
/tool bandwidth-server
set enabled=no

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,

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

Zitat von @commodity:

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,

nur meine Liste anders benamst...

Hi und danke erst mal... wenigstens weiss ich jetzt, dass es nicht kompletter Mist ist. Ich habe natürlich alles angepasst, Namen und die Liste. Habe es jetzt nochmals 1:1 übernommen (Namen angepasst):

/interface vlan
add interface=LAN name=vlan1_admin vlan-id=1
add interface=LAN name=vlan20_intern vlan-id=20
add interface=LAN name=vlan21_iptv vlan-id=21
add interface=LAN name=vlan30_guest vlan-id=30
add interface=LAN name=vlan40_iot vlan-id=40
add interface=LAN name=vlan50_doorbird vlan-id=50

/interface list
add name=myVlanList

/interface list member
add interface=vlan40_iot list=myVlanList
add interface=vlan50_doorbird list=myVlanList

/ip firewall filter
add action=accept chain=forward in-interface=vlan20_intern out-interface-list=myVlanList
add action=accept chain=input comment="Accept established, related" connection-state=established,related  
add action=accept chain=input src-address-list=allowed_to_router
add action=accept chain=input disabled=yes protocol=icmp
add action=accept chain=input log=yes protocol=igmp
add action=accept chain=input dst-port=123 in-interface=LAN protocol=udp
add action=accept chain=input dst-port=13231 in-interface=sfp28-2 protocol=udp
add action=drop chain=input log=yes
add action=fasttrack-connection chain=forward comment=FastTrack connection-state=established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related connection-type=""  
add action=reject chain=forward in-interface=vlan30_guest out-interface=!sfp28-2 reject-with=icmp-network-unreachable
add action=reject chain=forward in-interface=vlan40_iot log=yes out-interface=!sfp28-2 reject-with=icmp-network-unreachable
add action=reject chain=forward in-interface=vlan50_doorbird out-interface=!sfp28-2 reject-with=icmp-network-unreachable
add action=drop chain=forward comment="Drop invalid" connection-state=invalid log=yes log-prefix=invalid  
add action=drop chain=forward comment="Drop tries to reach not public addresses from LAN" dst-address-list=not_in_internet \  
    in-interface=LAN log=yes log-prefix=!public_from_LAN out-interface=!LAN
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

Die Liste wird mit auch korrekt angezeigt.

Hat leider keine Wirkung. Ich kann auch die accept Regel so anpassen, dass als out-interface nur vlan40_iot erlaubt ist (ohne Liste). Auch das hat keine Wirkung.

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.

RouterOS habe ich das aktuellste stable, 7.10.1. Soll ich mal auf die nächste DEV gehen?

Ist der Bootloader ein separates File?

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.

Ist der Bootloader ein separates File?

/system routerboard upgrade
/system reboot

Sollte man nach jedem RouterOS Update im Anschluss erledigen.

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

hat leider alles nix gebracht. clean install mit einem basic restore -> sobald ich meine reject regel drin habe ist schicht im schacht.

auch die letzte beta hat nix gebracht.

unter logs sehe ich nicht wirklich was:

forward: in:vlan40_iot out:vlan20_intern, connection-state:established src-mac 98:6d:35:c0:46:cf, proto ICMP (type 0, code 0), 192.168.40.12->192.168.20.145, len 60 (ping versuch von vlan20 ins vlan40)

müsste forward nicht heissen dass es durch geht?

gibt es da noch irgendwo ein ausführlicheres log?

Nur mal so ein Gedanke: die Firewall im PC und in dem anderen Gerät sind deaktiviert?

Jürgen

gibt es da noch irgendwo ein ausführlicheres log?

Es gibt ein unglaubliches Log. Du kannst praktisch alles loggen. Insbesondere auch jede einzelne Regel - jeweils dort in den "action"-Einstellungen. Das gilt in Deinem Falle insbesondere für drop und reject-Regeln.

Viele Grüße, commodity

Zitat von @chiefteddy:

Nur mal so ein Gedanke: die Firewall im PC und in dem anderen Gerät sind deaktiviert?

Jürgen

Ja, ich pinge einen heizstab, der hat keine firewall...

Zitat von @commodity:

gibt es da noch irgendwo ein ausführlicheres log?

Hab ich gemacht für die reject regel. Dabei kommt das oben raus. Es verwirrt mich, dass forward steht und trotzdem der ping nicht durchgeht.

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

Zitat von @commodity:

müsste forward nicht heissen dass es durch geht?

"forward" hast Du selbst als Prefix gesetzt, korrekt?

nein, das ist kein prefix.

wenn meine regel aktiv ist, geht kein ping durch / kommt kein ping an.

aber:

add action=reject chain=forward connection-state=new in-interface=vlan40_iot log=yes log-prefix=vlan40-fail out-interface=!sfp28-2 \
    reject-with=icmp-network-unreachable

diese Änderung hat bewirkt, dass es so funktioniert wie es soll. ohne accept regel! von vlan20 habe ich nun zugriff auf vlan40. umgekehrt nicht, ausser die verbindung wurde vom vlan20 initiiert (z.B. Kameras auf dem VLAN40 connecten noch immer auf die Synology Surveillance Station im VLAN20). Ein PC im VLAN40 kann nicht mehr ins VLAN20 pingen...

Ich habe keine Ahnung weshalb und ob das die (oder eine) lösung ist...

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

Hier dropst Du Pakete auf der Bridge ("LAN"). Das ist aber eine Regel für das WAN. Du hast die Regel vom Mikrotik Firewall-Vorschlag übernommen und fehlerhaft abgeändert.

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:

Das ist zum einen natürlich eine unsinnige Regel, weil vlan40_iot nun alle anderen VLANs erreicht...

Eben nicht und deshalb verstehe ich es nicht. Von einem Rechner im VLAN40 kann ich nix im VLAN20 pingen.

Mein nächster Verdacht wäre die fasttrack regel... Ich könnte die mal weglassen, was meinst du?

Faustregel:

Ich habe keine Ahnung weshalb

@@+++nie, nie, nie in der Firewall auf einem Mikrotik.

Warnung wurde verstanden. Du siehst ja meine Regeln, mehr ist da nicht. Ich habe nix weggelassen. Ist mikrotik standard...

Mir kommt ein vager Verdacht: Würdest Du mal bitte darstellen, wie Dein Internet angebunden ist.

Glasfaser direkt am sfp28-2

Es ist insgesamt unglücklich, dass Du den Export kastriert hast.

Habe nur die Clients (dns-einträge) und die VPN config weggelassen.

Auch mein Vorschlag, die Connection zu torchen steht noch

Hab ich gemacht. Regel weg, icmp senden und empfangen ok. Regel da, es wird gesendet aber nix empfangen.

Unabhängig davon habe ich hier noch einen "Verdächtigen":

Diese Rule ist IMO definitiv fehlerhaft...

Dann hat sie aber keine Wirkung. Habe sie schon mal deaktiviert. Aber stimmt, da müsste das interface sfp28-2 sein, korrekt?

Für's Erste: Diese Rule mal deaktivieren...

Ich habe schon kurzzeitig alle drop rules deaktiviert, ohne erfolg... Könnte jetzt höchstens noch alle aufs Mal deaktivieren.

Was mir noch aufgefallen ist, bei aktiver ursprünglicher Rolle werden pings von vlan40 in vlan20 rejected, umgekehrt aber gedropped...

Bin Euch wirklich dankbar für das Ball hin und her spielen. Solche Probleme triggern mich echt 😂

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).

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

Bitte diese Regel mal einstellen und schauen, ob sie ganz oben steht und aktiv ist. Dann mal eine Verbindung von 20 nach 40 versuchen.

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.

Sehe ich auch so, aber dennoch sollte es uns doch gelingen, den hier offenbar vorliegenden Knoten zu öffnen.
Und jeder fängt mal an.

Viele Grüße, commodity

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:

/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!

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.

Viele Grüße, commodity

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.

Hätten wir das nicht im Export gesehen?

Zitat von @commodity:

Hätten wir das nicht im Export gesehen?

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 ...

Zitat von @7426148943:

Zitat von @commodity:

Hätten wir das nicht im Export gesehen?

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 ...

Der Part fehlt weil er nicht existiert. Ich habe keine Interfacelisten.

Zitat von @clancy:
Der Part fehlt weil er nicht existiert. Ich habe keine Interfacelisten.

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

Du hast - ohne Kenntnisse von einer Firewall - die Standardfirewall gelöscht und dann mit den Hinweisen aus dem Wiki gebastelt? Na gute Nacht.

Hohoho, immer langsam, weiter oben hat's noch geheissen sieht gut aus 😉

Selbst wenn wir das hier hinbekommen (was sagt denn die Rule oben?) gilt hier: Da capo

Aber ja, hast recht, da capo, wenn auch nicht bei 0, die vlan config stammt ja aus zuverlässiger quelle. Aber ich mache jetzt mal Listen und die Basic Firewall gemäss Beispiel oben und dann mal schauen was raus kommt 🙂

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

Zitat von @commodity:
Geht denn die Regel von 10:57 Uhr nun bei Dir oder nicht? Dein Einsatz lässt nach!

Mein Einsatz war 100% -> am Grillfest

Habe nun die Firewall komplett neu gemacht, leicht modifiziert mit den Listen, ansonsten gemäss Anweisung oben:

/interface list
add name=WAN
add name=LAN-ALL
add name=LAN-Admin
add name=LAN-IOT
/interface list member
add interface=sfp28-2 list=WAN
add interface=vlan1 list=LAN-ALL
add interface=vlan20 list=LAN-ALL
add interface=vlan30 list=LAN-ALL
add interface=vlan40 list=LAN-ALL
add interface=vlan50 list=LAN-ALL
add interface=vlan50 list=LAN-IOT
add interface=vlan40 list=LAN-IOT
add interface=vlan20 list=LAN-Admin
add interface=vlan1 list=LAN-Admin
/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-Admin  
add action=accept chain=input comment="Allow icmp from LAN" in-interface-list=LAN-ALL protocol=icmp  
add action=accept chain=input comment="DNS input" dst-port=53 in-interface-list=LAN-ALL protocol=tcp  
add action=accept chain=input comment="DNS input" dst-port=53 in-interface-list=LAN-ALL protocol=udp  
add action=accept chain=forward comment="Allow forward LAN => WAN" in-interface-list=LAN-ALL out-interface-list=WAN  
add action=accept chain=forward comment="allow vlan1+20 => vlan40+50" in-interface-list=LAN-Admin out-interface-list=LAN-IOT  
add action=accept chain=input src-address-list=allowed_to_router
add action=accept chain=input comment="Allow igmp" log=yes protocol=igmp  
add action=accept chain=input dst-port=13231 in-interface-list=WAN protocol=udp
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
add action=drop chain=forward comment="Drop incoming packets that are not NAT`ted" connection-nat-state=!dstnat connection-state=new in-interface=sfp28-2 log=yes log-prefix=!NAT  
add action=drop chain=input comment="General input drop"  
add action=drop chain=forward comment="general forward drop"  
add action=fasttrack-connection chain=forward comment=FastTrack connection-state=established,related disabled=yes hw-offload=yes
add action=accept chain=forward connection-state=established,related connection-type="" disabled=yes  
/ip firewall nat
add action=masquerade chain=srcnat out-interface=sfp28-2 to-addresses=0.0.0.0

Funktioniert -> VIELEN DANK @7426148943 @commodity

Ist diese Config nun gut und safe? Muss ich noch was ergänzen? Braucht es Fasttrack noch?

edit: das habe ich mit meinem neu erlernten Wissen noch ergänzt:

add action=accept chain=forward in-interface=wireguard1 log=yes log-prefix=wireguard out-interface-list=LAN-ALL
add action=accept chain=forward comment="Allow forward Wireguard => WAN" in-interface=wireguard1 out-interface-list=WAN  

ok so? (funktioniert zumindest)

edit 2: dafür funktioniert jetzt IPTV nicht mehr -> ich denke da fehlt eine regel. kann mir nochmals wer helfen?

igmp-proxy ist so eingestellt wie der provider will... seine firewallregeln gehen aber nicht (Anleitung ist für eine alte V6 version)

/routing igmp-proxy
set quick-leave=yes
/routing igmp-proxy interface
add interface=vlan21
add alternative-subnets=0.0.0.0/0 interface=sfp28-2 upstream=yes

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) 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

Ja, ist der fortschrittlichste provider der Schweiz 🙂. 1/10/25gbit, p2p, alles zum selben Preis, ca. 60eur/monat. Aber ihr Support für mikrotik ist nicht so das Wahre.

Der Mikrotik war leider damals der einzige Router der 10gbit p2p und vlans beherrschte. Ich bin kein Fan davon, für meine Bedürfnisse trotz allem zu kompliziert. Aber jetzt hab ich ihn und leb damit 😂

Habe alle Regeln jetzt kommentiert und ein paar Regeln sind sicher redundant, da schaue ich morgen nochmals drüber.

Für igmp hatte ich vorher keine extra regeln, aber die fw config war ja auch suboptimal wie wir festgestellt hatten... 😂 Es gibt ein paar alte Anleitungen, die einen sagen Regel machen, die anderen nicht. Ich frag mal noch den Provider und eröffne sonst einen neuen thread. Frau ist jetzt halt ziemlich angepisst 😂

Mikrotik kann man nicht supporten

Guck mal ins dortige Forum. Da bist Du nach zwei Jahren in der Anstalt.
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

IPTV läuft nun auch wieder

Provider lieferte die notwendigen hints...

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?

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.
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.

Danke @7426148943

ist das nun gut und sicher so (für zu Hause

/ip firewall filter
add action=accept chain=input comment="input accepted/related" connection-state=established,related  
add action=fasttrack-connection chain=forward comment=FastTrack connection-mark=no-mark connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="forward established/related" connection-state=established,related log-prefix=was-geht-raus  
add action=drop chain=forward comment="invalid forward" connection-state=invalid log-prefix=forward-drop  
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" src-address-list=allowed_to_router  
add action=accept chain=input comment="Allow icmp from LAN" in-interface-list=LAN-ALL protocol=icmp  
add action=accept chain=input comment="DNS input" dst-port=53 in-interface-list=LAN-ALL protocol=tcp  
add action=accept chain=input comment="DNS input" dst-port=53 in-interface-list=LAN-ALL protocol=udp  
add action=accept chain=input comment="Allow IPTV" in-interface=sfp28-2 log=yes log-prefix=igmp protocol=igmp  
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
add action=accept chain=forward comment="DNS from VLAN21 to VLAN20" dst-port=53 in-interface=vlan21 out-interface=vlan20 protocol=tcp src-port=""  
add action=accept chain=forward dst-port=53 in-interface=vlan21 out-interface=vlan20 protocol=udp src-port=""  
add action=accept chain=forward comment="Allow forward LAN => WAN" in-interface-list=LAN-ALL out-interface-list=WAN  
add action=accept chain=forward comment="Allow forward Wireguard => LAN" in-interface=wireguard1 log-prefix=wireguard out-interface-list=LAN-ALL  
add action=accept chain=forward comment="Allow forward Wireguard => WAN" in-interface=wireguard1 out-interface-list=WAN  
add action=accept chain=forward comment="allow vlan1+20 => vlan40+50" in-interface-list=LAN-Admin out-interface-list=LAN-IOT  
add action=accept chain=forward comment="allow VLAN20 => VLAN1" in-interface=vlan20 out-interface=vlan1  
add action=accept chain=input comment="Allow VPN" dst-port=13231 in-interface-list=WAN protocol=udp  
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
add action=drop chain=forward comment="Drop incoming packets that are not NAT`ted" connection-nat-state=!dstnat connection-state=new in-interface=sfp28-2 log=yes log-prefix=!NAT  
add action=drop chain=input comment="General input drop"  
add action=drop chain=forward comment="general forward drop"  

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 ... 🐟

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

Dem Smiley und der hoffentlich vorhandenen Experten-Ehre entnehme ich jetzt mal dass es passt. Danke und schönes Wochenende!

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 ...

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

Da brennen die Finger heißer als Wüstensand, ...

Zitat von @7426148943:

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 ...

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

Da brennen die Finger heißer als Wüstensand ...

interessant, das ist die config vom provider, damit IPTV läuft...

Zitat von @clancy:
interessant, das ist die config vom provider, damit IPTV läuft...

Ich sagte ja, never trust anyone with blind eyes, only yourself! Damit lassen sich allerhand Schweinereien vom WAN aus durchführen ..

Zitat von @7426148943:

Ich sagte ja, never trust anyone with blind eyes, only yourself! Damit lassen sich allerhand Schweinereien vom WAN aus durchführen ..

da hast du schon recht... wäre jetzt deine chance um einem grossen provider zu zeigen dass er mist baut mit seinen configs...

wie könnte man es denn sichern, source eintragen?

Zitat von @clancy:
wie könnte man es denn sichern, source eintragen?

Ja auf jeden Fall. Und auch die Multicast-Subnets in der Destination am Input aufführen!

etwa so?

add action=accept chain=input comment="Allow IPTV" dst-address=224.0.0.0/4 in-interface=sfp28-2 log=yes log-prefix=igmp protocol=igmp  
add action=accept chain=input dst-address=224.0.0.0/4 dst-port=5000 in-interface=sfp28-2 protocol=udp src-address=77.109.129.16

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.

Den Beitrag dann bitte noch auf gelöst setzen. Das Thema der Frage ist ja nun schon erledigt!

"Groß" ist ja bekanntlich immer relativ!

Sieht schon besser aus wenn die Multicast Adressen mit UDP 5000 als Zielport arbeiten. Magenta TV benutzt UDP 10000 (ZDF HD Stream).

Zitat von @clancy:

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

interessant, das ist die config vom provider, damit IPTV läuft...

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!

Da hat der TO wohl noch ein paar mehr Korrekturen zu machen und kann schonmal die Rüstung rausholen wenn die Trautholdeste kommt um ihren Liebesschmachtfetzen zu sehen.

Zitat von @commodity:

Der Provider ist ja gut drauf!

Offensichtlich 🤣

Die Regeln bewirken aber nichts. Die igmp proxy funktion + igmp allow alleine tut's schon allerdings mit dem vlan als carrier anstatt der Bridge. So war es eigentlich auch vorher schon. Zumindest die tv app läuft einigermassen, wenn auch nicht 100% zuverlässig.

Zitat von @aqui:

Der Auszug oben offenbart 2 Kardinalsfehler:

Da hab ich jetzt geantwortet ohne das zu lesen. Nicht nur sind die Regeln falsch, sie sind völlig unnötig so wie es ausschaut...

Zumindest die tv app läuft einigermassen, wenn auch nicht 100% zuverlässig.

Hast du es einmal mit Multicast PIM Routing versucht? Ist die deutlich bessere Variante als der Proxy.

Zitat von @aqui:
Hast du es einmal mit Multicast PIM Routing versucht? Ist die deutlich bessere Variante als der Proxy.

Nein, dazu kenne ich mich zu wenig aus (falls Du es noch nicht bemerkt hast, ansonsten einfach @7426148943 fragen

)

ich habe es jetzt aber stabil hinbekommen. der senderwechsel ist mit 2-3sekunden noch ziemlich langsam, aber es läuft!

/routing igmp-proxy interface
add alternative-subnets=0.0.0.0/0 interface=sfp28-2 upstream=yes
add interface=vlan21
/ip firewall address-list
add address=77.109.129.16 list=tv7
add address=77.109.129.17 list=tv7
add address=77.109.129.18 list=tv7
add address=77.109.129.19 list=tv7
/ip firewall filter
add action=accept chain=input comment="Allow IGMP Multicast Traffic" dst-address=224.0.0.0/4 in-interface=sfp28-2 log-prefix=igmp protocol=igmp  
add action=accept chain=input comment="init7: Allow Multicast Traffic" dst-address=239.0.0.0/8 dst-port=5000 in-interface=sfp28-2 log-prefix=iptv protocol=udp src-address-list=tv7 src-port=\  
    5000
add action=accept chain=forward comment="forward Multicast Traffice to IPTV VLAN" dst-address=239.0.0.0/8 dst-port=5000 in-interface=sfp28-2 out-interface=vlan21 protocol=udp src-address-list=\  
    tv7 src-port=5000

jetzt sehe ich auch traffic auf den Regeln und im Proxy.

einen versteckten Hinweis beim Provider habe ich noch gefunden, igmp V2 statt V3 einstellen - hat aber bei mir keinen spürbaren Effekt.