Mikrotik, Gerät aus einem VLAN nicht erreichbar
Hallo zusammen,
ich finde momentan leider meinen Fehler nicht.
Anbei ist der Auszug aus meiner Firewall.
Mir geht es speziell um das VLAN 1 und um das VLAN 111.
VLAN 1 ist mein internes VLAN mit der IP 192.168.7.0/24
VLAN 111 ist mein IOT VLAN mit der IP 192.168.111.0/24
Aktuell ist es so, dass ich aus dem VLAN 1 ohne Probleme die IP Adresse 192.168.7.5 anpingen kann.
Mit der unten stehenden Config verbiete ich das aus dem VLAN111. Was soweit auch richtig ist.
Jetzt dachte ich, dass ich mit dieser Config, aus dem VLAN 111 die IP 192.168.7.5 anpingen kann.
Auch wenn ich nach fast ganz oben schiebe, kann ich die IP 192.168.7.5 nicht anpingen. Andere Geräte im IP Bereich 192.168.7.0/24 lassen sich ohne Probleme dann aus dem VLAN111 pingen. zb. 192.168.7.10 oder 192.168.7.11. Auch der Router 192.168.7.1 lässt sich pingen. Nur die 192.168.7.5 nicht.
Von einem Gerät aus dem Netz 192.168.7.0/24 ist ein Ping ohne jegliches möglich.
Egal wie ich die Firewall Regeln anpasse, der Ping kommt nicht an das eine Gerät durch.
Habe ich einen Fehler in der Config?
ich finde momentan leider meinen Fehler nicht.
Anbei ist der Auszug aus meiner Firewall.
Mir geht es speziell um das VLAN 1 und um das VLAN 111.
VLAN 1 ist mein internes VLAN mit der IP 192.168.7.0/24
VLAN 111 ist mein IOT VLAN mit der IP 192.168.111.0/24
Aktuell ist es so, dass ich aus dem VLAN 1 ohne Probleme die IP Adresse 192.168.7.5 anpingen kann.
Mit der unten stehenden Config verbiete ich das aus dem VLAN111. Was soweit auch richtig ist.
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input comment="wireguard ip input" src-address=192.168.77.0/24
add action=accept chain=input comment="wireguard udp input" dst-port=63558 protocol=udp
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input in-interface=vlan90 protocol=icmp
add action=accept chain=forward comment="iobroker intern erreichbar" dst-address=192.168.111.10 in-interface=vlan1
add action=accept chain=forward comment="iobroker von wlan erreichbar" dst-address=192.168.111.10 in-interface=vlan70
add action=accept chain=forward dst-address=192.168.111.10 in-interface=vlan90
add action=accept chain=forward dst-address=192.168.111.11 in-interface=vlan1
add action=accept chain=forward dst-address=192.168.111.12 in-interface=vlan1
add action=accept chain=forward dst-address=192.168.111.40 in-interface=vlan1
add action=accept chain=forward disabled=yes dst-address=192.168.70.2 in-interface=vlan1
add action=accept chain=forward dst-address=192.168.111.11 in-interface=vlan70
add action=accept chain=forward dst-address=192.168.111.27 in-interface=vlan1
add action=drop chain=forward in-interface=vlan200 out-interface=!ether1
add action=drop chain=forward comment="WLAN Gast nur ins Internet" disabled=yes in-interface=vlan90 out-interface=!ether1
add action=reject chain=forward comment="iot keine Zugriff auf Intern" in-interface=vlan1 out-interface=vlan111 reject-with=icmp-network-unreachable
add action=reject chain=forward comment=" iot keine Zugriff auf WLAN Intern" in-interface=vlan70 out-interface=vlan111 reject-with=icmp-network-unreachable
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" disabled=yes ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" disabled=yes ipsec-policy=out,ipsec
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="Reverse Proxy" connection-nat-state=dstnat in-interface=ether1
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat dst-port=80,443 in-interface=ether1 protocol=tcp to-addresses=192.168.7.11Jetzt dachte ich, dass ich mit dieser Config, aus dem VLAN 111 die IP 192.168.7.5 anpingen kann.
add action=accept chain=forward comment="test" dst-address=192.168.7.5 in-interface=vlan111 Auch wenn ich
accept established,related, untracked -> forward -> acceptVon einem Gerät aus dem Netz 192.168.7.0/24 ist ein Ping ohne jegliches möglich.
Egal wie ich die Firewall Regeln anpasse, der Ping kommt nicht an das eine Gerät durch.
Habe ich einen Fehler in der Config?
Kommentieren
Teilen
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: 672802
Url: https://administrator.de/forum/mikrotik-geraet-aus-einem-vlan-nicht-erreichbar-672802.html
Ausgedruckt am: 10.05.2025 um 16:05 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
die Reihenfolge ist hier halt sehr wichtig und natürlich auch der Weg des Paketes zurück.
Das sollte ausreichen.
Gruß
die Reihenfolge ist hier halt sehr wichtig und natürlich auch der Weg des Paketes zurück.
/ip firewall filter
add action=accept chain=forward comment="Allow ping from VLAN111 to 192.168.7.5" in-interface=vlan111 dst-address=192.168.7.5 protocol=icmp place-before=22
add action=accept chain=forward comment="Allow ping response from 192.168.7.5 to VLAN111" src-address=192.168.7.5 out-interface=vlan111 protocol=icmp place-before=22 Das sollte ausreichen.
Gruß
Danke für die Antwort.
Leider kommt auch hier kein Ping zurück.
Leider kommt auch hier kein Ping zurück.
Na dann aktiviere das log für die forward drop rule und schaue nach was blockt.
Kann es sein das du ggf. einen Firewall Logik Denkfehler bezogen auf den Mikrotik machst??
Die Mikrotik Router Firewall funktioniert NICHT wie eine dedizierte Firewall nach einer Whitelisting Logik ala "alles was nicht explizit erlaubt ist ist generell verboten" sondern, wie es grundsätzlich bei Routern üblich ist, nach einer Blacklisting Logik ala "es ist generell alles erlaubt was nicht ausdrücklich verboten ist".
Deine obigen Firewall Regel Settinges lassen den leisen Verdacht aufkommen das du von einer grundsätzlich falschen Annahme der Mikrotik Firewall Logik ausgehst die konträr zur einer "klassischen" Firewall Logik ist. Kann das sein...?
"Accept" muss man in der Regel nicht extra definieren, weil das nach der o.a. grundlegenden Logik ja so oder so immer Default ist. Das siehst du ja daran das das Routing zw. den IP Netzen ganz ohne Regelwerk ja immer offen ist ohne jegliche Beschränkung. Du muss also explizit deny'en (blacklisten) was du nicht willst. Der Rest ist immer offen (Accept). Blacklisting Logik eben...
Nur nebenbei: Manchmal ist ein WinBox Screenshot sinnvoller als der Export, weil man hier das Regelwerk und die chronologische Reihenfolge ("first match wins") besser in Gänze zu übersehen ist. Das erleichtert für Außenstehende das Troubleshooting.
Sehr einfache Regelwerk Grundlagen auch hier.
Die Mikrotik Router Firewall funktioniert NICHT wie eine dedizierte Firewall nach einer Whitelisting Logik ala "alles was nicht explizit erlaubt ist ist generell verboten" sondern, wie es grundsätzlich bei Routern üblich ist, nach einer Blacklisting Logik ala "es ist generell alles erlaubt was nicht ausdrücklich verboten ist".
Deine obigen Firewall Regel Settinges lassen den leisen Verdacht aufkommen das du von einer grundsätzlich falschen Annahme der Mikrotik Firewall Logik ausgehst die konträr zur einer "klassischen" Firewall Logik ist. Kann das sein...?
"Accept" muss man in der Regel nicht extra definieren, weil das nach der o.a. grundlegenden Logik ja so oder so immer Default ist. Das siehst du ja daran das das Routing zw. den IP Netzen ganz ohne Regelwerk ja immer offen ist ohne jegliche Beschränkung. Du muss also explizit deny'en (blacklisten) was du nicht willst. Der Rest ist immer offen (Accept). Blacklisting Logik eben...
Nur nebenbei: Manchmal ist ein WinBox Screenshot sinnvoller als der Export, weil man hier das Regelwerk und die chronologische Reihenfolge ("first match wins") besser in Gänze zu übersehen ist. Das erleichtert für Außenstehende das Troubleshooting.
Sehr einfache Regelwerk Grundlagen auch hier.
Es ist tatsächlich so, dass ich anders herum gedacht habe.
Hier ist Screenshots, wie es momentan aussieht.
Jetzt aber die wichtigste Frage.
Wenn ich einen Router mit Standardconfig habe, dann sieht diese Config so aus:
Ab welchem Punkt muss ich dann starten, meine Regeln einzufügen?
Ich lerne ja immer gerne dazu, daher würde ich die Regeln auch dementsprechend umbauen und schauen, wie es dann aussieht. Wenn ich schon umbaue, dann würde ich es auch gleich gerne dieses mal Richtig machen.
Hier ist Screenshots, wie es momentan aussieht.
Jetzt aber die wichtigste Frage.
Wenn ich einen Router mit Standardconfig habe, dann sieht diese Config so aus:
Ab welchem Punkt muss ich dann starten, meine Regeln einzufügen?
Ich lerne ja immer gerne dazu, daher würde ich die Regeln auch dementsprechend umbauen und schauen, wie es dann aussieht. Wenn ich schon umbaue, dann würde ich es auch gleich gerne dieses mal Richtig machen.
Wenn ich einen Router mit Standardconfig habe, dann sieht diese Config so aus:
Richtig! Das ist in erster Linie das Standardregelwerk für den Internet WAN Port (üblicherweise eth1) den das Regelwerk wasserdicht absichert.Dieses Regelwerk beeinflusst nicht das lokale Forwarding der lokalen LANs. Das ist, wie oben schon gesagt, immer offen. (Blacklisting Logik)
⚠️ Das Default Regelwerk arbeitet mit den Interface Listen "WAN" und "LAN". Es ist daher zwingend die lokalen LAN Interface immer mit in diese Liste "LAN" aufzunehmen wenn man als Basis mit dem Default Firewall Regelset arbeitet!!
Fehlt eine entsprechende Aufnahme in diese Interface Listen werden diese lokalen IP Interface nicht vom Regelwerk beachtet!! Gleiches gilt für die WAN Liste z.B. man erstellt ein virtuelles PPPoE Interface und vergisst dies in die WAN Liste aufzunehmen.
Wenn man mit einem eigenen Setup ohne Listen arbeitet gilt das natürlich nicht. Listen sind aber sinnvoll um Interfaces mit gleichen Anforderungen zusammenzufassen um das Regelwerk schlank zu halten.
Ab welchem Punkt muss ich dann starten, meine Regeln einzufügen?
Das kommt ganz darauf an WAS für eine Regel du konfigurieren willst oder musst. Es gilt ja immer first match wins was bedeutet das bei einem positiven Hit der Rest nicht mehr abgearbeitet wird.Wenn du jetzt z.B. eine Erlaubnis für den VPN Zugang mit Wireguard (UDP 51820) auf den WAN Port setzen willst dann machst du das direkt unter Fasttrack Rule "0" oder direkt unter der "1" oder den Regeln 1-4. Hinter 5 darf es nicht mehr stehen denn das dropt allen anderen Traffic der von außen ins WAN Interface kommt. Eine solche Regel nach "5" ist dann wirkungslos. Reihenfolge zählt also.
Alle lokalen Regeln z.B. zw. deinen VLANs können auch nach "11" konfiguriert sein.
Vor der Fasttrack Regel solltest du nichts setzen weil diese das Hardware Verhalten der Firewall beim Forwarding massgeblich beeinflusst.
https://wiki.mikrotik.com/Manual:IP/Fasttrack
Um auf Deine Ausgangsfrage zurück zu kommen: Vermutlich ist 192.168.7.5 bei Dir ein Gerät mit eigener Firewall. Viele Geräte-Firewalls blocken per default Anfragen aus anderen Subnetzen. Jeder Windows-Computer beispielsweise operiert auf diese Weise.
Die Lösung ist demnach, an dieser Stelle die nötigen Freigaben einzutragen.
Die Lösung ist demnach, an dieser Stelle die nötigen Freigaben einzutragen.
