28.10.2023, aktualisiert um 10:40:13 Uhr

4362

DNS-Rebind-Schutz

Hi,
um meine externe Url auch intern nutzen zu können (duckdns) muß ich einen Rebind Schutz einrichten.
Das ging bei der Fritz einfach über ein Menü. Beim Hex finde ich gar keine Doku dazu.

Sinn ist es, das speziell diese eine Adresse nicht extern aufgelöst wird.

Schlagt mich nicht gleich wieder..... ;)

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

Content-ID: 62431330404

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

Ausgedruckt am: 21.11.2024 um 21:11 Uhr

37 Kommentare

Neuester Kommentar

Dann lege doch einfach einen entsprechenden Wert (A, cname?) an.

Rebind scheinst du zu verwechseln.

Und nicht vergessen, DNS ist eine Kette.

geht das bitte genauer. Das mußte ich bei FB machen

Sicher was du vor hast, verstanden zu haben?

Static DNS: https://wiki.mikrotik.com/wiki/Manual:IP/DNS

Home Assistant braucht eine Adresse wie https://myduckdns....:8123 die Intern und extern funktioniert.
Von Extern funktioniert das, nur intern wird die Adresse nicht aufgelöst

Guten Tag,
kommt den ein vernünftiges Resultat raus, wenn du einen öffentlichen DNS-Server verwendest. Also unter Windows zum Beispiel mit dem Befehl:

nslookup hostname.domainname.tld 1.1.1.1

Ich vermute dein interner DNS-Server (du hast so wie ich das gelesen habe einen eigenen in Betrieb genommen) gleicht nicht so schnell mit dem öffentlichen ab.

Gruß

Zitat von @sat-fan:

Home Assistant braucht eine Adresse wie https://myduckdns....:8123 die Intern und extern funktioniert.
Von Extern funktioniert das, nur intern wird die Adresse nicht aufgelöst

Das ist bei AVM hier dokumentiert, aber das ist nichts halbes und nichts ganzes mit einer Fritzbox.

Weil dort kannst du keine richtige A-Record oder CNAME hinterlegen.

Home Assistant braucht eine Adresse wie https://myduckdns....:8123 die Intern und extern funktioniert.

Klingt für mich nach einem Fall des Hairpin NAT

Viele Grüße, commodity

https://www.youtube.com/watch?v=1I5FywY6opQ (ab 2:05)
https://forum.mikrotik.com/viewtopic.php?t=172380

@aqui
danke addressiert genau mein Problem. Leider funktioniert der Eintrag:

add action=masquerade chain=srcnat dst-address=192.168.200.85 out-interface=\
    vlan-200-Admin protocol=tcp src-address=192.168.200.0/24

dennoch nicht. Auch nicht mit out. interface bridge ...
ne Idee dazu ?

Habe jetzt mein Homeassistant ins Netzwerk 10.0.0.0/24 übernommen. Bin mir noch nicht ganz sicher ob Hairpin überhaupt der richtige Ansatz ist. Mein Hairpin Eintrag ist jetzt:

/ip firewall nat
add action=masquerade chain=srcnat comment=Hairpin dst-address=10.0.0.85 log=\
    yes out-interface=bridge protocol=tcp src-address=10.0.0.0/24

so läuft das aber nicht wie ich mag. Nochmal zur Erklärung:
Extern geht der link https://myduckdns:8123 auf meinen Homeserver 10.0.0.xx:8123 das funktioniert.
Intern funktioniert dieser link nicht.
Es wird die externe IP von Duckdns über 8.8.8.8 aufgelöst, aber da die Anfrage von einen Browser intern kommt, routet der Hex die Anfrage nicht. Es geht nur um Anfragen an eine Domain, die nicht extern geroutet werden soll. Mit dem Hairpin setup gelingt mir das leider nicht.

Extern geht der link https://myduckdns:8123 auf meinen Homeserver 10.0.0.xx:8123

Na ja ganz so ist es ja nicht...
Der Hostname wird bzw. muss ja in eine gültige IP Adresse aufgelöst werden. Dies ist natürlich nicht die 10er IP Adresse, denn die ist unroutebar im Internet, da private RFC 1918 IP.
Eine nslookup myduckdns auf einem externen Client sollte dir dann als Antwort immer die öffentliche WAN Port IP Adresse des NAT Routers ausgeben hinter der der Zielserver liegt. Das ist die Adresse die dir der Router auf dem WAN Port in der Übersicht anzeigt.
Dort ist dann ein Port Forwarding konfiguriert was am WAN Port des Routers eingehenden Traffic mit Zielport TCP 8123 dann auf deine interne 10er IP forwardet.

Beim Mikrotik sieht das Port Forwarding korrekt konfiguriert in der Firewall so aus für den Beispielport UDP 51820:

Mit anderen Worten: Es ist klassisches Bilderbuch Hairpin NAT Problem wie es im MT Tutorial beschrieben ist.

Nebenbei: 8.8.8.8 solltest aus Datensicherheitsgründen besser nicht benutzen.

Steh iwi immer noch auf dem Schlauch. Die NAT Regel mit dem dsnat hatte ich schon drin. Wie gesagt, der Zugriff von extern klappt.
Hier meine aktuellen ... noch lang nicht fertige !! Firewall und NAT Regeln:

/ip firewall filter
add action=accept chain=forward comment="Foreward Homeassistant" dst-address=\  
    10.0.0.85 dst-port=8123 protocol=tcp
add action=drop chain=input comment="WAN -> FW | Ping blockieren" \  
    in-interface=ether1 protocol=icmp
add action=accept chain=input comment=\
    "ALLG | Erlauben: established,related,untracked" connection-state=\  
    established,related,untracked
add action=accept chain=input comment="LAN -> FW | Zugriff FW erlauben" \  
    in-interface=bridge
add action=accept chain=input comment="DMZ -> FW | DNS erlauben UDP" \  
    dst-address=10.0.0.133 dst-port=53 protocol=udp
add action=accept chain=input comment="DMZ -> FW | DNS erlauben TCP" \  
    dst-address=10.0.0.133 dst-port=53 protocol=tcp
add action=drop chain=input comment=\
    "ALLG.| Alles ohne Verbindungsstatus DROP" connection-state=invalid  
add action=accept chain=forward comment=\
    "ALLG. | Aufgebaute Verbindungen erlauben"  
add action=drop chain=input comment="drop all not coming from LAN" \  
    in-interface-list=!LAN
add action=accept chain=forward comment=\
    "LAN -> WAN | Internet zugriff erlauben" in-interface=bridge \  
    out-interface=pppoe-out1
add action=drop chain=forward comment="ALLG. | Alles andere verwerfen"  
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \  
    ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment=Hairpin dst-address=10.0.0.85 log=\
    yes out-interface=bridge protocol=tcp src-address=10.0.0.0/24
add action=masquerade chain=srcnat comment=Hairpin dst-address=10.0.0.85 log=\
    yes out-interface=bridge protocol=tcp src-address=192.168.100.0/24
add action=dst-nat chain=dstnat comment=443 dst-port=443 in-interface-list=\
    WAN protocol=tcp to-addresses=10.0.0.85 to-ports=8123
add action=dst-nat chain=dstnat comment=8123 dst-port=8123 in-interface-list=\
    WAN protocol=tcp to-addresses=10.0.0.85 to-ports=8123

Achte immer darauf das das Regelwerk abhängig ist von der Reihenfolge und es gilt "First match wins"!!
Bedeutet bei einem positiven Hit wird dann der Rest des Regelwerkes nicht mehr abgearbeitet. Möglicherweise greift deshalb deine Hairpin Regel nicht, denn die sollte natürlich immer an erster Stelle vor den anderen (26) stehen?! 🤔

Hilft nichts. Hier das setup:

Übersicht – home assistant – mozilla firefox 05.11.2023 23_32_44

admin@192.168.100.1 (mikrotik) - winbox (64bit) v7.11.2 on hex (mmips) 05.11.2023 21_00_59

Dann musst du wohl mal mit dem Wireshark ran....

oh jeh .. schon wieder was neues für mich ... Die Lernkurve wird nicht flacher ....

Wozu hat man einen Mikrotik?

Der sagt einem doch ganz viel...

Wie man im NAT-Bild zur Firewall sieht, leitet das (korrekte) Hairpin-NAT Pakete weiter.
Guckst Du: 1768 Bytes bei 34 Packets.

Auch die (korrekte) Firewall-Rule tut es.
Guckst Du: 816.1 KiB bei 9331 Packets.

Das könntest Du jetzt im Wireshark beobachten. Oder im großartigen Tool "Packet Sniffer" unter Tools schon in Router OS eingebaut. Am Interface, das den Server beherbergt sniffen und nach Traffic vom WAN filtern. Da sollte was zu sehen sein.

Warum geht es dann nicht von intern? Ohne vollständigen Export der Konfiguration (immer hilfreich) nicht ganz einfach zu sagen.

Erst wollte ich sagen: Ich sehe in Deinem Ruleset keine Firewall-Regel, die Traffic von Deinem Server 10.0.0.85 in Dein Heimnetz 192.168.100.0/24 erlaubt. Rule 9 erlaubt ja nur den Traffic ins WAN.
Bei genauem Hinschauen erlaubt aber (die unsauber kommentierte) Rule 8 den Forward für alles überall hin (deshalb haben Deine nachfolgenden Regeln 10 und 11 auch keine Wirkung - wie man an den Countern ("0") erkennt - die Firewall ist damit faktisch abgeschaltet und der hEX wurde zur Fritzbox kastriert). Aber immerhin sollten sich Server und Heimnetz so in beide Richtungen erreichen.

Da es zumindest in eine Richtung nicht geht:
Liegt das Server-Netz ebenso auf der Bridge wie das Heimnetz? Bilder von IP/Addresses und IP/Routes (oder Export) wären vielleicht hilfreich.
Generell musst Du beim Network-Debugging nachverfolgen, wohin Pakete durchgehen und wohin nicht. Bei letzteren dann logisch den Weg vom Ausgangspunkt zum Ziel nachverfolgen (gedanklich die Leitung "ablaufen"). Dann findest Du meist die Ursache.

Insgesamt sind Deine FW-Rules heikel. Im Moment kann das gesamte Internet auf Deine Geräte (außer dem Router selbst) zugreifen. Solange Du noch eine Fritzbox mit aktivem NAT davor hast, ist das IMO kein Problem. Wenn Du aber schon am Modem hängst, ist das gefährlich. Dann solltest Du keine Daten haben, die Dir wichtig sind oder die persönlich bleiben sollten. Bzw. Dich zügig mit der Firewall beschäftigen. Mikrotik hat eine ausgezeichnete Standard-Firewallkonfiguration. Die sollte immer aktiv sein und so weit verstanden, dass man seine individuellen Anpassungen vornehmen kann. Dass die Firewalls in den Tutorials meist deaktiviert werden, dient der didaktischen Zielstellung, ist aber im produktiven Betrieb natürlich nicht vertretbar.

Viele Grüße, commodity

Wozu hat man einen Mikrotik?

Stimmt, der hat mit Torch den Wireshark gleich onboard und per Mausklick bedienbar!

Die Kurve bleibt also doch erstmal flach.
Ansonsten lesen...

https://www.heise.de/ratgeber/Fehler-erschnueffeln-221587.html

Wenn es das denn nun war:
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen!

nein Leider nicht. Baue immer noch daran rum.
Hatte jetzt NGINX als option überlegt.
um die Funktion zu nutzen muß man in der configuration.yaml
folgende Änderungen machen:

 cors_allowed_origins:
        - https://google.com
        - https://www.home-assistant.io
    ip_ban_enabled: true
    login_attempts_threshold: 5  
    use_x_forwarded_for: true
    trusted_proxies:
      - 172.30.33.0/24

und diese Zeilen raus nehmen:

   ssl_certificate: /ssl/fullchain.pem
     ssl_key: /ssl/privkey.pemt

aber sobald ich das mache, Kann Alexa nicht mehr über das Netz zugreifen ...
I ch werde noch wahnsinnig mit dem blöden Problem

I ch werde noch wahnsinnig mit dem blöden Problem

Na ja, wenn Du die Ratschläge und Fragen komplett ignorierst können wir hier jedenfalls nicht helfen. Aber manchmal reicht es ja, es nur niederzuschreiben. Good Luck jedenfalls!

Viele Grüße, commodity

quatsch ... so ist das nicht. Ich bin dran. Aber leider habe ich nicht immer die Zeit, die Manuals und howto´s zu lesen und zu verstehen. Der Ansatz mit NGINX sah für mich viel einfacher und vielversprechender als Netztwerktraffic zu analysieren ...

Kam jetzt erst dazu mir deinen ausführlichen Beitrag vom 6.11. anzuschauen. Habe jetzt erst mal die Regel 9 unter die 11 geschoben. Muss mich dann dringend nochmal an die Firewall machen. Leider geht es nicht nur im Router gerade drunter und drüber ... Hoffe ich finde schnell die Zeit wenigstens ein paar Regeln dazu zu machen, da ich am modem Hänge !

so .. nun habe ich etwas Zeit um mich um dieses Problem zu kümmern.
Also die IoT Geräte liegen in 192.168.20.1/24
mein Homeasssisant auf 10.0.0.85
Mein PC auf dem ich hänge liegt im 192.168.100.1/24 Netz

Mir ist eigentlich nicht klar, wer mit wem redet um den Wert an meinem PC anzzuzeigen.
Primär geht es um das aulesen eines IoT Gerätes, das in der einstellung
/api/webhook/xxxxxxxxxxxxxx
myduckdns.org:8123 stehen hat

diese Einstellung ist zwingend notwendig.

extern komme ich auf http://myduckdns.org:8123
intern aber nicht... das ist das Problem.

Habe mir mal mit Torch angeschaut was bei mir am PC so raus geht ;) das ist aber wohl sinnfrei.
Wäre toll wenn mir jemand sagen könnte wie ich weiter suchen kann. Firewall und Nat einstellung sind oben gepostet. sollte noch ne Info fehlen bitte schreiben.
Danke !

Mir ist eigentlich nicht klar, wer mit wem redet um den Wert an meinem PC anzzuzeigen.

Keine besonders gute Voraussetzung für ein Troubleshooting wie du dir ja sicher auch selbst denken kannst.

Warum nutzt du dann nicht einfach einmal den Wireshark und/oder die Torch Funktion die da sofort Licht ins Dunkel bringt.
Normal (geraten) so:

IoT mit Homeassistant
Homeassistant zum PC oder App

Der Homeassistant ist üblicherweise der zentrale Sammler der IoT Daten der diese dann in der Regel in einem WebGUI präsentiert.
DuckDNS ist ein klassischer DynDNS Provider. Sehr wahrscheinlich funkt der Homeassistant mit deiner DuckDNS Domain nach Hause und meldet an DuckDNS deine öffentliche Mikrotik IP am Providerport.

Wenn du dann mobil unterwegs bist fragt deine Homeassitant App nicht deine heimische Home Assistant IP (was ja auch wenig Sinn machen würde) sondern versucht über deine DuckDNS Domain und der daran dann gebundenen öffentlichen IP deines Mikrotik über Port Forwarding per TCP UDP (leider steht da nicht ob 8123 TCP oder UDP nutzt ☹️ !) über das von dir dann in die MT Firewall gebohrte Loch auf deinen internen Homeassistant zuzugreifen.
Übliches Prozedere um unbedarften IT Laien nicht die Qual einer VPN Einrichting zuzumuten.

Genau das passiert passiert dann auch wenn du mit der App von intern zugreifen willst. Statt dann direkt die Homassitant IP oder lokalen Hostnamen zu verwenden nimmt die App dann den DuckDNS Hostnamen. Damit rennst du dann in ein klassisches Hairpin NAT genau wie oben beschrieben was du dann auch genau so wie im Mikrotik Video erklärt fixt.

Generell ist das nicht besonders sicher da du ja ein Loch in deine MT NAT Firewall fürs Port Forwarding bohren musst. Deutlich besser wäre z.B. ein klassisches L2TP VPN auf dem MT aufzusetzen so das du dich mit deinem mobilen Device und onboard VPN Client gesichert von remote mit deinem Heimnetz verbindest und wenn die Homeassistant App dann die direkte IP hat erübrigt sich auch die nach Hause Telefoniererei mit DuckDNS sowie das Loch in der Firewall.
Mikrotik L2TP VPN Server Setup

Wie gesagt Hommeassistant Kommunikation nur alles geraten weil die Praxis fehlt aber generell ist das ja der übliche Weg wie solche Apps es machen. Wireshark und Torch sind deine besten Freunde.

Ganz nebenbei bemerkt ist auch der Umweg über DuckDNS völlig überflüssig, da Mikrotik einen eigenen kostenlosen DynDNS Dienst bietet der in deinem Mikrotik schon onboard ist:
https://mikrotik-blog.com/dyndns-unter-mikrotik-routeros-einrichten
Aber auch das löst natürlich das Hairpin NAT Problem dann nicht.

Danke für die ausführlcihe Antwort.
Es ist tatsächlich nur eine App bzw. ein Gerät im Home Assistant die (EcoWitt Weather Station) die so beschissen programmiert ist, das sie den Domainnamen im lokalen Netz auflösen muss. Auch brauchen Tuya Apps ( leider laufen noch nicht alle unter LocalTuya ) und auch die Alexa API einen aufgebohrten Port, aber mit dem Sicherheitsloch kann ich leben.

Eben nur diese eine App hat dieses Problem seit einem update im Sommer. Das konnte ich einfach

Ecowitt Weather Station configuration

The following steps must be performed to set up this integration. For security reason, use the token path that you get from the Home Assistant config flow.

    Use the Ecowitt App (on your phone) or access the Ecowitt WebUI in a browser at the station IP address.
    Pick your station -> Menu Others -> DIY Upload Servers.
    Hit next and select ‘Customized’
    Pick the protocol Ecowitt, and put in the ip/hostname of your Home Assistant server.
    Path has to match! If using the Ecowitt App, remove the first forward slash from the API token, as the app will prepend one.
    Save configuration.

Ecowitt doesn’t support TLS/SSL, you can use the NGINX TLS Proxy Add-on to support HTTPS and HTTP at the same time.

werde mal weiter probieren.
Das mit der DDNS von Microtik war mir neu ! Ist sich nicht so einfach zu merken wie die duckns namen. Aber Rechner können das ja besser als ich .. Einmal eingetragen, sollte das dann auch laufen. Danke

Der Fehler liegt hier

add action=dst-nat chain=dstnat comment=443 dst-port=443 in-interface-list=WAN protocol=tcp to-addresses=10.0.0.85 to-ports=8123

Du leitest nur Pakete weiter die vom WAN aus rein kommen aber nicht die die von Intern in den Router fließen, aber du greifst ja von intern zu, ergo greift diese Weiterleitung nicht, und deswegen kommt auch keine Verbindung zu Stande 😉.

Also z.B. mit dst-address-type=local arbeiten, etc. dann kommt das sofort zum fliegen!

/ip firewall nat
add action=dst-nat chain=dstnat comment=443 dst-port=443 dst-address-type=local protocol=tcp to-addresses=10.0.0.85 to-ports=8123

Oder alternativ mit Addressliste arbeiten

/ip firewall address-list
add address="blablub.myduckdns.org" list=WANIP  
/ip firewall nat
add action=dst-nat chain=dstnat comment=443 dst-port=443 dst-address-type=local dst-address-list=WANIP protocol=tcp to-addresses=10.0.0.85 to-ports=8123

Die Hairpin Rule bleibt natürlich bestehen.

Ich perönlich würde aber einfach einen statischen DNS Eintrag auf dem Mikrotik setzen sofern dieser DNS Proxy für die Clients ist.

/ip dns static add name=blablub.myduckdns.org address=10.0.0.85

Dann brauchst du gar kein NAT und deine dynDns Adresse wird intern immer zur internen Adresse aufgelöst (Splitbrain-DNS)

Gruß Katrin

habe es gelöst ....
Weis letztendlich nicht was von den vielen Änderungen die Lösung war. Bin aber jetzt erst mal froh das es läuft.
Danke für eure Hilfe und Geduld !

Wahrscheinlich sind jetzt aber viel zu viel Einträge in der Nat:
Brauch jetzt erst mal ne Netzwerk Pause ..

/ip firewall nat
add action=masquerade chain=srcnat comment="Hairpin IoT Netz"dst-address=10.0.0.85 log=yes out-interface=bridge protocol=tcp src-address=192.168.20.0/24  
add action=masquerade chain=srcnat comment="Hairpin 100er Netz" dst-address=10.0.0.85 log=yes out-interface=bridge protocol=tcp src-address=192.168.100.0/24  
add action=masquerade chain=srcnat comment="Hairpin 10er Netz" dst-address=10.0.0.85 log=yes out-interface=bridge protocol=tcp src-address= 10.0.0.0/24  
add action=dst-nat chain=dstnat comment="Port Forward 8123 TCP" dst-port=8123 in-interface=pppoe-out1 protocol=tcp to-addresses=10.0.0.85 to-ports=443  
add action=dst-nat chain=dstnat dst-port=80,443 in-interface=pppoe-out1 protocol=tcp to-addresses=10.0.0.85
add action=masquerade chain=srcnat comment="defconf: masquerade"   ipsec-policy=out,none out-interface-list=WAN  
add action=masquerade chain=srcnat dst-address=10.0.0.0/24 src-address=192.168.20.0/24
add action=masquerade chain=srcnat dst-address=10.0.0.0/24 src-address=10.0.0.0/24
add action=src-nat chain=srcnat src-address=10.0.0.85 to-addresses= >>my_external_ip<<
add action=dst-nat chain=dstnat dst-address=>>my_external_ip<< to-addresses=10.0.0.85

gerade mal geschaut. Außer bei der 3. Regel (10er Netz) habe ich überall Traffic. Also lass ich das wohl erst mal. Vielleicht kann nur mal jemand drüber schauen wegen der Reihenfolge. Nicht das ich mal wieder was auf mache mit meinem gefährlichen Halbwissen. Thx

Wie kann ich einen Beitrag als gelöst markieren?

Vielleicht kann nur mal jemand drüber schauen wegen der Reihenfolge. Nicht das ich mal wieder was auf mache mit meinem gefährlichen Halbwissen. Thx

Lies meinen Beitrag oben da steht wieso es bei dir nicht geklappt hat.
Verständnis ist der erste Schritt zur Erkenntnis.

Eine Firewall auf gut Glück aufzubauen ist wie wenn du eine ungeöffnete Flasche Bier bei einer Feier auf den Tisch stellst ... Genau, die bleibt nicht lange da stehen 😉.

p.s. Dein Regelwerk oben ist vollkommen unsicher, nur so nebenbei .. Da spaziert dir sogar ein Noob ohne viel Mühe am Router vorbei in dein Netz ohne das du was mitbekommst. Dein Netz kannst du jetzt also schon mal als korrumpiert betrachten, da tümmeln sich sicher schon die Verschlüsselungstrojaner und Crypto-Miner 🤗

Grundlagen wie immer hier
https://help.mikrotik.com/docs/display/ROS/Building+Your+First+Firewall
https://help.mikrotik.com/docs/display/ROS/Building+Advanced+Firewall

@8030021182

es funktioniert doch jetzt mit der o.g. Konfig
Meine Firewall habe ich so gut ich konnte aufgebaut. Nicht auf gut Glück, dafür fehlt mir komplett das wissen ;)
Es ging mir hier im Thread um den NAT Teil, den ich auf die schnelle aufgesetzt habe und nur auf Funktion geprüft habe.

Ist ja total Krass, das dieser eine Eintrag reicht

/ip dns static add name=blablub.myduckdns.org address=10.0.0.85

danke .... den verstehe ich auch ;)
Leider kam diese kurze Lösung sehr spät. Die eine Woche hairpin zu debuggen hätte ich sicher mit anderen Lernaufgaben füllen können ...
Egal ... für mich zählt das Ergebnis.

Dein Netz kannst du jetzt also schon mal als korrumpiert betrachten, da tümmeln sich sicher schon die Verschlüsselungstrojaner und Crypto-Miner 🤗

Magst du mir Angst machen ?

Das Finetuning der Firewall ist das nächste Projekt jetzt. Alle Anleitungen bzw. Tutorials hier und im Netz, sind eher für eine einfache Bridge gebaut. Diese habe ich soweit möglich berücksichtigt. Schwierig ist es, da ich gleich mit 4 Vlans anfangen muß und sich z.b. so Fragen stellen, ob IoT Geräte eine Regel ins normale Lan brauchen oder ob die Geräte nur passiv handeln und ich nur eine Regel aus dem normalen Netz für tcp ins IoT brauche. Wenn man so etwas das erste mal macht, ist es nicht einfach. Bin eigentlich stolz alles so weit am laufen zu haben. Die FW wird sicher nochmal die letzte große Herausforderung hier und ich hoffe ich bekomme hier weiter den guten Support.

Das hier ist nicht mein Job ... nur ein Hobby für ein Rentner. Ich habe nicht den Anspruch aller verstehen zu können zu wollen. Ich akzeptiere gerne die konkrete Hilfe bei meinen aktuellen Probleme von den Profis hier. Es ist schön diesen Support hier zu bekommen.

Magst du mir Angst machen ?

Nein, will ich nicht, aber das ist leider nunmal Fakt das deine Config offen wie ein Scheunentor ist wenn du dir die Forward-Chain mal ansiehst!
Mikrotik Geräte sind nunmal nichts für Weicheier, sie sollten nur von fachkundigem Personal konfiguriert werden!
Du gefährdest nicht nur dich selbst und deine Mitmenschen die dieses Netz nutzen, auch andere die von potentiell von deinem Netz aus attackiert werden.
Also bitte beherzigen, Danke.

Im Zweifel belässt man immer einfach die Firewall Setups der Default Konfig, denn die sind wasserdicht! 😉

Habe nochmal die Firewall nach bestem Wissen und Gewissen überarbeitet. Ich weis, sie ist noch nicht perfekt, z.b. muß ich den Wireguard zugriff noch weiter einschränken.
Hoffe aber sie ist jetzt dokumentiert genug und hat keine ganz großen Fehler drin ... Bitte nicht den Kopf abreißen....

/ip dns
set allow-remote-requests=yes servers=10.0.0.133

/ip dns static
add address=10.0.0.85 name=my.duckdns.org

/ip firewall address-list
add address=10.0.0.0/24 list=VLAN1
add address=192.168.1.0/24 list=Wireguard
add address=192.168.10.0/24 list=VLAN10
add address=192.168.20.0/24 list=VLAN20
add address=192.168.0.0/24 list=VLAN100

/ip firewall filter
add action=accept chain=forward comment="Foreward Homeassistant" dst-address=10.0.0.85 dst-port=8123 log=yes protocol=tcp  
add action=drop chain=input comment="WAN -> FW | Ping blockieren" in-interface=ether1 protocol=icmp  
add action=accept chain=input comment="ALLG | Erlauben: established,related,untracked" connection-state=established,related,untracked  
add action=drop chain=input comment="ALLG.| Alles ohne Verbindungsstatus DROP" connection-state=invalid  
add action=accept chain=input comment="DNS erlauben UDP" dst-address=10.0.0.133 dst-port=53 protocol=udp  
add action=accept chain=input comment="DNS erlauben TCP" dst-address=10.0.0.133 dst-port=53 protocol=tcp  
add action=accept chain=forward comment="allow VLAN10 only internet" out-interface-list=WAN src-address-list=VLAN10  
add action=accept chain=forward comment="allow VLAN20 only internet" out-interface-list=WAN src-address-list=VLAN20  
add action=accept chain=forward comment="allow VLAN100 to VLAN20" dst-address-list=VLAN20 src-address-list=VLAN100  
add action=accept chain=forward comment="allow VLAN1 to VLAN20" dst-address-list=VLAN20 src-address-list=VLAN1  
add action=accept chain=forward comment="allow VLAN1 to VLAN100" dst-address-list=VLAN100 src-address-list=VLAN1  
add action=accept chain=forward comment="allow VLAN100 to VLAN1" dst-address-list=VLAN1 src-address-list=VLAN100  
add action=accept chain=input comment="LAN -> FW | Zugriff FW erlauben" in-interface=bridge  
add action=accept chain=input comment="WAN -> FW | WireGuard-Zugriff" dst-port=13331 protocol=udp  
add action=accept chain=input dst-address=192.168.1.1 in-interface=wireguard-vpn
add action=drop chain=input comment="drop all not coming from LAN" in-interface-list=!LAN  
add action=accept chain=forward comment="VPN -> LAN | Netzwerkzugriff" dst-address=!192.168.1.0/24 in-interface=wireguard-vpn out-interface=all-vlan  
add action=accept chain=forward comment="LAN -> WAN | Internet zugriff erlauben" in-interface=wireguard-vpn out-interface=pppoe-out1  
add action=accept chain=forward comment="LAN -> WAN | Internet zugriff erlauben" in-interface=bridge out-interface=pppoe-out1  
add action=accept chain=forward comment="ALLG. | Aufgebaute Verbindungen erlauben"  
add action=drop chain=forward comment="ALLG. | Alles andere verwerfen"  

/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 comment="Port Forward 8123 TCP" dst-port=8123 in-interface=pppoe-out1 protocol=tcp to-addresses=10.0.0.85 to-ports=443  
add action=dst-nat chain=dstnat comment="Port Forward 443 TCP" dst-port=443 in-interface=pppoe-out1 protocol=tcp to-addresses=10.0.0.85 to-ports=443  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=tcp src-address=80.69.193.112 src-port=5060 to-addresses=10.0.0.111 to-ports=5060  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=5060 to-addresses=10.0.0.111 to-ports=5060  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7077 to-addresses=10.0.0.111 to-ports=7077  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7078 to-addresses=10.0.0.111 to-ports=7078  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7079 to-addresses=10.0.0.111 to-ports=7079  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7080 to-addresses=10.0.0.111 to-ports=7080  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7081 to-addresses=10.0.0.111 to-ports=7081  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7082 to-addresses=10.0.0.111 to-ports=7082  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7083 to-addresses=10.0.0.111 to-ports=7083  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7084 to-addresses=10.0.0.111 to-ports=7084  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7085 to-addresses=10.0.0.111 to-ports=7085  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7086 to-addresses=10.0.0.111 to-ports=7086  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7087 to-addresses=10.0.0.111 to-ports=7087  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7088 to-addresses=10.0.0.111 to-ports=7088  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7089 to-addresses=10.0.0.111 to-ports=7089  
add action=accept chain=dstnat comment="WAN -> LAN | SIP-Anbieter Netcom zu FritzBox fr Telefonie" in-interface-list=WAN protocol=udp src-address=80.69.193.112 src-port=7090 to-addresses=10.0.0.111 to-ports=7090  

Hat sich aber an der Situation nichts geändert, ist immer noch offen wie ein Scheunentor.🤪

add action=accept chain=forward comment="ALLG. | Aufgebaute Verbindungen erlauben"

Damit kann ich problemlos übers WAN direkt in alle deine Netze routen ...
Da bringt der Drop in Zeile 35 rein gar nichts weil er niemals verwendet wird.

Bitte nicht den Kopf abreißen....

Wenn du das hier aus eigener Initiative in einem Admin-Forum öffentlich postest, was erwartest du? Sollen wir dich mit Samthandschuhen streicheln, dich ins offene Messer laufen lassen und andere die hier vorbei kommen die selben Fehler machen lassen?

Ich würde ja einen langen verregneten Nachmittag investieren und mir die Materie im Detail zu Gemüte führen, dann einen Plan machen und dann erst umsetzen zu sonst frickelst du was zusammen was am Ende ineffizient und wohlmöglich arge Fehler beinhaltet. Also Rechner ausschalten, Papier und Bleistift hernehmen und den Plan aufzeichnen.
Vor allem das Verständnis was die Chains an sich bedeuten als erstes mal verinnerlichen
https://help.mikrotik.com/docs/pages/viewpage.action?pageId=328350&n ...

Packet Flow in RouterOS

Und dann die oben verlinkten Firewall-Setups Zeile für Zeile durchgehen und verstehen was diese einzeln bedeuten.

Das hat aber alles rein gar nichts mehr mit dem Thema zu tun, also bitte den Threads als gelöst markieren.

Habe viele verschneite Nachmittage und Abende damit verbracht, die Materie zu verstehen. Erwarte keine Samthandschuhe, aber konkrete Hilfe wäre schön. Bin scheinbar zu blöd ... und andere vielleicht zu überheblich. Bisher konnten mir hier einige Helfen, wenn ich die Lernkurve nicht geschafft habe...
Eine Aussage wie ...
add action=accept chain=forward comment="ALLG. | Aufgebaute Verbindungen erlauben"
Damit kann ich problemlos übers WAN direkt in alle deine Netze routen ...
Da bringt der Drop in Zeile 35 rein gar nichts weil er niemals verwendet wird.

mag richtig sein.

Aber eine Lösung was ich stattdessen machen muss, ob die einfach gelöscht werden kann oder wie modifiziert werden muß, wäre vielleicht zielführender als mir nur links auf Manuals zu schicken, denen ich offensichtlich nicht gewachsen bin.

Denke ich habe mich verklickt und statt input , forward erwischt ... Katastrophaler Fehler ...

Meine Quelle war dies hier: (Min.32)
https://www.youtube.com/watch?v=77h5QRLkwtU&t=1s

dort wird aber erklärt, das diese Regel Accept --> Forward gebraucht wird.

Gerne mache ich einen separaten Thread auf, wenn gewünscht.