09.05.2025, aktualisiert um 12:15:37 Uhr

1859

Mikrotik, Gerät aus einem VLAN nicht erreichbar

gelöstFrage MikroTik Router, Routing Netzwerkgrundlagen

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.

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

Jetzt 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 -> accept

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?

Bitte 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: 30.05.2025 um 23:05 Uhr

14 Kommentare

Neuester Kommentar

Hallo,

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.

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.

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.

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.

Hallo,

ich hatte ein ähnlich seltsames Problem auf einem Mikrotik L009 (den roten) aber ohne VLAN, nur eine einfache LAN-Bridge.
Da konnte ich z.B. durch das Gerät "hindurch" pingen also devices welche auf verschiedenen Ports sind problemlos pingen, aber auf den Mikrotik selbst nicht, dieser wiederum konnte pingen usw.
Quasi verhielt sich dieser so als wäre ein "spezifischer MAC-Filter" aktiv.

Noch merkwürdiger war / ist der Workaround dazu:

Den Switch bzw die Bridge nach dem Hochfahren nochmal aus und wieder einschalten - kein Witz dann geht es
problemlos.

Beim scheduler einfach einen Trigger "Startup" anlegen und dort folgende Befehle rein:

/delay 10
/interface/disable bridge1-LAN
/log info "Bruecke aus!"  
/delay 5
/interface/enable bridge1-LAN
/log info "Bruecke ein!"  

Natürlich sollte der betroffene Adapter in der geschalteten bridge enthalten sein.

Dieser Workaround ist seit der 7.10 drin und ich hatte noch keine Zeit / Lust nach dem Fehler zu suchen - geht einfach und das reicht mir erst mal

Das dieser Effekt bei deiner Konfig vorhanden ist, ist sehr unwahrscheinlich aber schaden tut es auf keinen Fall.
Das Problem ist ja wenn man die Bridge manuell ausmacht dann sperrt man sich ja idR selbst aus.
Man kann den SAFE-Mode ein machen dann die Bridge aus und warten bis man wieder rein darf, dann den / die Pings durchführen.
Natürlich sollte sichergestellt sein dass das Gerät auch auf den Ping reagiert / antwortet.
Hier kann u.U. NAT helfen damit das "gepingte" Gerät eine Anfrage aus dem "eigenen Netz" sieht.

Grüße

Der geschilderte "Effekt" ist ein sicheres Indiz für eine Fehlkonfiguration der LAN IP Adresse. Lässt sich auch mit Ver. 7.18 auf mehreren Plattformen absolut nicht nachvollziehen! Solch Verhalten wäre auch aus Management Sicht fatal.
Oftmals passiert sowas wenn die LAN IP direkt auf Bridge Memberports gemappt ist statt dem Bridge Interfave oder dedizierte Routing only Ports (solche mit direkter IP Adressierung) fälschlicherweise Memberports der Bridge sind. Hier kann man nur Kristallkugeln...
Irgend so ein Konfig "Kinken" wird das bei dir ganz sicher sein. Diese "Workaround" Frickelei ist bei korrekter IP Konfig natürlich überflüssig.

Das Problem ist ja wenn man die Bridge manuell ausmacht dann sperrt man sich ja idR selbst aus.

Auch das ist so pauschal gesagt nicht richtig! Zu mindestens wenn man das Mikrotik WinBox Tool für den Konfigurationszugang benutzt. Die WinBox kann bekanntlich den Mikrotik auch ganz OHNE irgendwelche IP Adresse rein nur über die Hardware Mac Adresse verbinden. Damit ist ein Konfig Zugang auch ohne Bridge immer sicher möglich.

Hier kann u.U. NAT helfen damit das "gepingte" Gerät eine Anfrage aus dem "eigenen Netz" sieht.

NAT ist in der Regel auch völlig überflüssiger Overkill für sowas. Es reicht wenn man im Ping Tool unter "Advanced" eine entsprechende Quell IP aus dem Interface Netz angibt und fertig ist der Lack. Gewusst wie...

Na dann bin ich mal gespannt, zeige bitte den Fehler in der Konfiguration(ja mehr ist nicht drin, das Ding ist im Moment nur ein oller Switch), ich bin für jede Hilfe dankbar, welche erlaubt das StartupScript weg zu lassen:
Und nein - der DHCP-Server(auch ein Mikrotik) ist nicht die Ursache, 30 andere Devices haben kein Problem damit, es wurde auch schon zeitweise ein anderer Router als DHCP-Quelle verwendet, eine Fritzbox.
Und auch eine statische Konfiguration, all das ändert rein gar nichts am Problem....

[user@L009] > /export   
# 2025-05-11 15:29:34 by RouterOS 7.18.2
# software id = 36BE-JC3N
#
# model = L009UiGS-2HaxD
# serial number = 
/interface bridge
add name=bridge1-LAN
/interface ethernet
set [ find default-name=sfp1 ] disabled=yes
/interface bridge port
add bridge=bridge1-LAN interface=ether1
add bridge=bridge1-LAN interface=ether2
add bridge=bridge1-LAN interface=ether3
add bridge=bridge1-LAN interface=ether4
add bridge=bridge1-LAN interface=ether5
add bridge=bridge1-LAN interface=ether6
add bridge=bridge1-LAN interface=ether7
add bridge=bridge1-LAN interface=ether8
/ipv6 settings
set disable-ipv6=yes
/ip dhcp-client
add default-route-tables=main interface=bridge1-LAN
/system identity
set name=L009
/system note
set show-at-login=no
/system routerboard settings
set auto-upgrade=yes baud-rate=off enter-setup-on=delete-key
/system scheduler
add name=bridge_aus_an_beim_start on-event="/delay 10\r\  
    \n/interface/disable bridge1-LAN\r\
    \n/log info \"Bruecke aus!\"\r\  
    \n/delay 5\r\
    \n/interface/enable bridge1-LAN\r\
    \n/log info \"Bruecke ein!\"\r\  
    \n" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup  

Deswegen stand da ja auch "kann unter Umständen", bedeutet dass man NAT nicht unter allen Umständen braucht.
"Kann" schließlich kein "Muss".
Evtl. wird auch mit einem anderen Gerät im Netz gepingt, bei dem man nicht mal eben schnell die Quell-IP eingeben / einstellen kann.
Natürlich sollte der Ping von allen (LAN)Devices aus funktionieren und nicht nur vom Mikrotik aus

Und die 1-2 Klicks als "überflüssiger Overkill" zu betrachten, hmm kann man natürlich so sehen

ich bin für jede Hilfe dankbar, welche erlaubt das StartupScript weg zu lassen:

Damit meinst du dein eigenes Script oder das Default Script mit der Default Konfig? Da die Maschine keine Default Konfig hat vermutlich dann wohl Letzteres, oder?

Was oft auch ein häufiger Fehler ist das beim Firmware Update vergessen wurde den Bootloader auch upzudaten. Dann kann es auch zu solchen Effekten kommen. Das solltest du also nochmal als Allererstes überprüfen in der WinBox unter System --> Routerboard. Der Bootloader sollte immer die gleiche Image Version haben wie die Firmware!!

Da du ja aktuell keine produktive Konfig hast wäre es einmal spannend wie sich das Gerät verhält wenn du unter System --> Reset configuration die Box auf die Werkseinstellungen zurücksetzt und dann einmal die Default Konfig abnickst.
Ether1 ist dann der WAN/Internet Port den du in den bestehendes Heimnetz steckst. Dort rennt auch ein DHCP Client der dann sofort eine IP bekommen sollte. On Top macht der Port dann auch gleich NAT.

Sollte das auch wider Erwarten Probleme machen kann es sein das du ein Autonegotiation Problem hast mit dem Mikrotik Port und deinem Netzwerk Anschlussport. Die Geräte können sich dann nicht auf eine gemeinsame Geschwindigkeit einigen und auch den Duplex Mode nicht korrekt aushandeln. Der Grund ist das man Switch auf Switch steckt und oftmals die MDI-X Umschaltung der Ports scheitert.
https://de.wikipedia.org/wiki/Medium_Dependent_Interface
In der Regel zeigen sich dann Effekte wie du sie beobachtest.

Sowas kann man mit einem Crossover Kabel fixen oder man setzt den Anschlussport einer Seite auf einen festen statischen Wert für Speed und Duplex.
Der nächste Test sollte dann das Entfernen des DHCP Clients auf dem Bridgeport sein und stattdessen dort einmal eine statische IP Adresse zu konfigurieren und mit dem Setup die Connectivity testen. Sollte damit auch das Problem weiter bestehen spräche das ebenfalls für ein Autonegotiation Problem.
Die o.a. Konfig ist ja eigentlich keine, denn damit hast du die Box lediglich zu einem dummen Layer 2 Switch gemacht. Sie ist syntaktisch aber auch nicht falsch.
Final kann man natürlich einen Hardware Defekt auch nicht ausschliessen.

Genau das scheint mein Problem gewesen zu sein.
Auf die Firewall in der Heizung habe ich keinen Zugriff. Ich habe jetzt Kurzerhand die Heizung in das VLAN genommen, in der ich diese benötige. Jetzt scheint alles so zu funktionieren, wie ich es wollte.

Danke für die ganze Hilfe.

Zitat von @wusa88:

Genau das scheint mein Problem gewesen zu sein.
Auf die Firewall in der Heizung habe ich keinen Zugriff. Ich habe jetzt Kurzerhand die Heizung in das VLAN genommen, in der ich diese benötige. Jetzt scheint alles so zu funktionieren, wie ich es wollte.

Danke für die ganze Hilfe.

Wenn das Gerät zwingend als Absender-IP eine aus seinem eigenen Subnetz erwartet hättest du das auch mit einem SRC-NAT abfackeln können ohne das Netz des Gerätes zu wechseln .

/ip firewall nat add chain=srcnat out-interface=vlan1 dst-address=192.168.7.5 action=masquerade

Somit erscheint dann jeglicher Traffic aus anderen Netzen in Richtung Gerät als wenn er vom Router selbst mit der IP 192.168.7.1 kommt, und damit hätte die FW des Gerätes nichts mehr einzuwenden.

Zitat von @BiberMan:

Perfekt, vielen Dank für den Input.
Ich habe alles jetzt wieder auf Ursprungszustand zurückgesetzt und sieht da, es funktioniert wunderbar.

Danke an alle für die wertvolle Hilfe!

gelöstFrage MikroTik Router, Routing Netzwerkgrundlagen

Mehr von wusa88

Ubuntu verschiedene Internetzugänge mit Wireguard, WLAN funktioniert, LAN nichtwusa88 - 34 Kommentare

Wireguard Client Docker, Mikrotik Routerwusa88 - 12 Kommentare

Mikrotik, Wireguard, Linux Mint Netzwerk GUIwusa88 - 10 Kommentare

Mikrotik hap Lite als AccessPoint nutzenwusa88 - 3 Kommentare

Heiß diskutiert