visucius
Feb 01, 2022, updated at 10:21:18 (UTC)
view944
view7
0
Goto Top

Mikrotik Firewall - Chromcast

GermansolvedQuestionMikroTikOther systems
Guten Morgen,

Mikrotik und ich mal wieder.

In meinem Setup (3 vLANs) nutzen wir in(nerhalb) eines vLANs einen Chromcast. D.h. Client und Chromcast befinden sich innerhalb des gleichen vLANs!

Sobald ich die folgende Firewallregel aktiviere, können Client und Chromcast nicht mehr kommunizieren. Bzw. der Client (Windows-PC mit Chrome als Browser) findet den Chromcast nicht mehr.

FW-Regel:
 4 X  ;;; block everything else
      chain=input action=drop in-interface-list=!Mgmt log=yes log-prefix="input_notMgmt"


Fehlermeldung:
bildschirmfoto 2022-02-01 um 10.33.02

Das vLAN44 in dem Chromcast&Client sind, ist dabei natürlich kein Mgmnt-Interface.

Frage:
a) Warum geht dieser Traffic überhaupt über die "Input-Chain" der Firewall?! Ich dachte, diese definiert zunächst mal nur den Routerzugriff selber?! Und der Chromcast-Traffic ist bzw. soll doch zudem nur netzintern laufen?!

b) Wie behebe ich das am sinnvollsten?!

Vielen Dank im Voraus!
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 1796004874

Url: https://administrator.de/contentid/1796004874

Printed on: April 18, 2024 at 15:04 o'clock

7 Comments
Latest comment
Goto Top
Mitglied: 1795827498
1795827498 Feb 01, 2022 updated at 10:23:15 (UTC)
Goto Top
Du blockst für alle non management Netze DNS abfragen an den Router (siehst du ja am Port 53 UDP als Ziel). Und ohne DNS ist nunmal schlecht Kirschen essen in jeglicher Hinsicht.

Gruß /n
Member: Visucius
Visucius Feb 01, 2022 updated at 10:34:31 (UTC)
Goto Top
Ups, ja stimmt auffallend. Danke Dir. Und klingt auch plausibel bzw. erklärt ebenso den Schluckauf beim DNS face-wink

D.h. die DNS-Abfrage ist nicht in der folgenden Regel enthalten (darüber)?
 3    ;;; accept estdablished, related
      chain=input action=accept connection-state=established,related log=no log-prefix=""

Meine Herangehensweise wäre jetzt bei der eingangs erwähnten "Block-Regel" die DNS-Anfragen mit !Port53 zu exkludieren. Sehe aber gerade, dass das gar nicht geht, bzw. ausgegraut ist. Gibts da ne andere Herangehensweise?!

Eine zusätzliche Input-Chain (darüber) für DNS ist mir in den üblichen MT-Ressourcen eigentlich nicht untergekommen?!
Mitglied: 1795827498
1795827498 Feb 01, 2022 updated at 10:42:32 (UTC)
Goto Top
Zitat von @Visucius:
D.h. die DNS-Abfrage ist nicht in der folgenden Regel enthalten (darüber)?
 3    ;;; accept estdablished, related
      chain=input action=accept connection-state=established,related log=no log-prefix=""
Nein! Das lässt nur bereits in der State-Table enthaltene Verbindungen durch, Stichwort Statefull Firewall. Und UDP hat keine States.
Meine Herangehensweise wäre jetzt bei der eingangs erwähnten "Block-Regel" die DNS-Anfragen mit !Port53 zu exkludieren. Sehe aber gerade, dass das gar nicht geht, bzw. ausgegraut ist. Gibts da ne andere Herangehensweise?!
DNS erlauben.
Hier lesen wie man generell vorgeht https://help.mikrotik.com/docs/display/ROS/Building+Advanced+Firewall

Eine zusätzliche Input-Chain (darüber) für DNS ist mir in den üblichen MT-Ressourcen eigentlich nicht untergekommen?!
Du hast das Konzept Firewall-Chains wohl noch nicht ganz verstanden. Es gibt nur eine INPUT-Chain, aber man kann sich seine eigenen Chains anlegen in die man von dort aus springt (JUMP).
Member: aqui
Solution aqui Feb 01, 2022 updated at 11:03:04 (UTC)
Goto Top
D.h. die DNS-Abfrage ist nicht in der folgenden Regel enthalten (darüber)?
Nein, oder nur halb denn DNS nutzt immer auch UDP (Siehe hier) und bei UDP gibt es bekanntlich kein "established" und somit bleibt UDP 53 da bei dir hängen ! face-wink
Established betrifft auch nur den Return Traffic also wenn etwas VOM MT gesendet wurde und die dann folgende Antwort. Z.B. DNS sendet der MT nur an seinem Uplink DNS Port sofern DNS konfiguriert ist. Eingehende DNS Frames von Clients z.B. die den MT als DNS Cache nutzen (sofern von dir konfiguriert ?!) bleiben ebenfalls hängen da es da ja kein Established Bit gibt.
Da solltest du also dein Regelwerk nochmal dringend überarbeiten. Bedenke auch das Reihenfolge auch hier zählt !
Die Torch Funktion oder der Wireshark hätte dir hier, auch ohne Thread, sofort Klarheit gebracht ! face-wink
Member: Visucius
Visucius Feb 01, 2022 at 11:10:14 (UTC)
Goto Top
Hier lesen wie man generell vorgeht https://help.mikrotik.com/docs/display/ROS/Building+Advanced+Firewall

Dort wird das wie folgt gelöst:
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN

(anders als in der "first-time-config": add chain=input in-interface=ether1 action=drop comment="block everything else";)

Bei mir ist LAN=Bridge ... ist das so richtig?! Oder muss ich statt der (vlan-)Bridge die vLANs selber dort drunterpacken?!

ohne Thread sofort Klarheit gebracht
Klarheit ist so ein großes Wort face-wink
Mitglied: 1795827498
Solution 1795827498 Feb 01, 2022 updated at 11:13:42 (UTC)
Goto Top
Zitat von @Visucius:
Bei mir ist LAN=Bridge ... ist das so richtig?! Oder muss ich statt der (vlan-)Bridge die vLANs selber dort drunterpacken?!
Die vLAN Interfaces gehören in die LAN Liste nicht die Bridge.
Member: Visucius
Visucius Feb 01, 2022 updated at 11:22:33 (UTC)
Goto Top
Zitat von @1795827498:

Zitat von @Visucius:
Bei mir ist LAN=Bridge ... ist das so richtig?! Oder muss ich statt der (vlan-)Bridge die vLANs selber dort drunterpacken?!
Die vLAN Interfaces gehören in die LAN Liste nicht die Bridge.

Ahh verstehe! Ich meine, deshalb habe ich mich mit "LAN" schon mal ausgesperrt und die Krücke !Mgmnt "gebastelt". Wird sofort gefixt!

Danke Dir und @aqui für die Erklärung!
GermansolvedQuestionMikroTikOther systems
Hotly discussed
AlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment