Zwei OpenWRT Netzwerke verbinden, aber nur bestimmte Verbindungen zulassen

[Mitec]

Bisher ist alles "in Reihe". Im Aussperren habe ich nun schon Routine. Nein, Option "-A" kannte ich noch nicht. Beschäftige mich schon lange mit Servern aber lokales Netzwerk war immer zu komplex.

Also, ich erkläre nochmal wie ich bisher vorgegangen bin, Ziel ist weiterhin, dass Home Assistant aus dem Netzwerk "lan" auf die Netzwerkkameras im Netz "IoT" zugreifen können.

1. Router2 Reset
2. lan-Interface auf IP 192.168.4.1
3. über radio1 verbinden mit Router1, Netzwerk "lan" hat nun eine Internetverbindung.
4. das Vorhandene Wifi "OpenWRT" wird umbenannt zu "IoT" und das zugewiesene Netzwerk "lan" wird entfernt.
5. neue Netzwerkschnittstelle "IoT", Typ: statische Adresse, Netzwerk: WLAN "IoT" (phy1-ap0)

Im folgenden Dialog kann ich dann die Netzwerkschnittstellen für IoT bearbeiten, hier ist jetzt allerdings kein Gerät hinterlegt, hier sollte doch nun IoT stehen, welches ich eben gewählt habe, oder?
6. Jedenfalls setzt ich in diesem Dialog: IP4 = 192.168.5.1, Netzwerkmaske 255.255.255.0, DHCP aktiv

Nun hat die Netzwerkschnittstelle aber noch keinen Netzwerkadapter. Und ich kann mich auch nicht mit dem Netzwerk verbinden. Hinterlege ich bei der WLAN-Verbindung wieder "lan" ist eine Verbindung möglich.
Das Netzwerk "IoT" sollte ja ähnlich wie "lan" aussehen? Es sind ja beides Netzwerke, nur eines soll eben über die Firewall geblockt werden. Bei "lan" steht jedoch br-lan IPv4: 192.168.4.1/24. Bei "IoT" steht "phy1-ap0" und IPv4: 192.168.5.1/24

Also lege ich eine Bridge an, br-IoT, aber nun die Brückenports... hier gibt es nur eth-Switch und eth-VLANs zur Auswahl...
"Um WLAN-Netzwerke anzubinden, muss die der Netzwerkbrücke zugehörige Schnittstelle in den Drahtloseinstellungen gesetzt werden."
Also speichern, WLAN, IoT-Netz wählen, und nun bei "Netzwerk" br-IoT? Geht nicht. Hier komme ich einfach nicht weiter...

Also lösche ich die Bridge wieder und probiere neu:
Netzwerkadapter hinzufügen, Type "VLAN (802.1q)", ID "2". (VLAN-ID für das IoT-Netzwerk)
Grundgerät "phy1-ap0"

Netzwerkadapter hinzufügen, Type "Netzwerkbrücke", Adaptername br-IoT, Brückenport "phy1-ap0.2"

Netzwerkschnittstelle, IoT wählen, Gerät nun "br-IoT", Anwenden.

Beim Versuch zu verbinden: Fehler: Aktivierung der Verbindung ist gescheitert: IP-Konfiguration konnte nicht reserviert werden

Ich habe nun die Netzwerkschnittstellen lan und IoT verglichen. Beide haben als IPv4 Gateway 192.168.2.1 (wwan). Ist das korrekt?

Puh, ich bin nun eine Wochen dran, dabei sind das vermutlich nur ein paar Klicks die mir fehlen...

 

[blurrrr]

Wenn die Dinger in Reihe geschaltet sind, hast Du nur 2 Optionen. Wenn wir mal von diesem Konstrukt ausgehen...

<Router 1> <-> <Router 2> <-> <Router 3>

bzw. konkreter von diesem Teilabschnitt...

<HA-Host> <-> <Router 3 (inkl. NAT)> <-> <Cam>

bleiben Dir für den Zugriff vom HA-Host zur Cam nur die Optionen:

1) Portfreigabe (wie Du es schon von extern kennst, konkreter "Firewall-Regel + DNAT (Destination-NAT/Ziel-NAT)"
2) SNAT abschalten, Firewall-Regel erstellen (HA-Host -> Cam -> erlauben)

Ich persönlich finde die 2. Variante wesentlich angenehmer, weswegen ich auch meinte, dass man intern nicht noch zusätzlich NAT braucht. So kannst Du sämtliche IPs in Deinem Heimnetzwerk auch direkt ansprechen (auch wenn sie in einem nachgelagerten Netzwerk liegen, z.B. Zugriff von der HA-Host-IP auf die Cam-IP).

 

[Mitec]

Ok, nur zuerst müssen sich die Clienten nun mit dem WLAN "IoT" verbinden können und dazu muss DHCP für das WIFI IoT funktionieren. Das vor ein paar Tagen funktioniert, aber nur da ich das Netzwerk "lan" direkt bei WIFI IoT hinterlegt habe. Nun soll es jedoch ein eigenes Netzwerk werden.

So bin ich vorgegangen:
Vorhandenes Netzwerk OpenWRT abgeändert:
-wireless.default_radio1.ssid='OpenWrt'
+wireless.default_radio1.ssid='IoT'
-wireless.default_radio1.network='lan'
+wireless.default_radio1.network='iot'

Und nun benötige ich einen Netzwerkadapter (ist das das selbe wie Netzwerkinterface bei OpenWRT oder kann es sowohl ein Gerät als auch ein Netzwerkadapter sein? Und soll ich besser gleiche eine Bridge anlegen oder genügt ein Interface?). Es scheitert ja an grundsätzlichen Dingen gerade. Und dann habe ich wieder gelesen, beide Netzwerke dürfen nicht das selbe Gateway haben (also 192.168.2.1).

 

[Mitec]

Ein kleines Schritt für mich wäre zu verstehen: Die vorhandene Schnittstelle "lan" hat als Device "br-lan" mit list ports "eth0.1"
Für was steht "eth0.1" und muss / sollte ich das auch bei meiner IoT Bridge (br-iot) nehmen?
eth0.1 ist das VLAN (802.1q)
eth0 ist ein Netzwerkadapter
eth0.2 ist auch ein Netzwerkadapter? müsste das nicht auch ein VLAN sein?

update: fährt man mit dem Mauszeiger über den Netzwerkadapter eth0.2 steht da "Switch VLAN"

Fazit: für einen Neueinsteiger ist es fast ein Ding der Unmöglichkeit dieses System zu verstehen.

 

[Barungar]

Korrekt, eth0 ist ein "physischer" Netzwerk-Adapter.
eth0.1 ist ein "Alias" bzw. ein "virtueller" Netzwerk-Adapter, sowas wird in der Regel konfiguriert, wenn auf dem eth0 ein VLAN-Taggging nach 802.1q aktiv ist. Es kann aber auch einfach "nur" eine komplett abweichende Konfiguration sein, z.B. in ein anderes (Sub-)Netz. Das könnte z.B. der Fall eth0.2 sein - ohne Dein System und seine Konfig zu kennen, kann man das aus der Ferne schwierig beantworten.

"br.lan" ist ein Brücken (Bridge) - Interface, das auf OSI Layer 1-2 mehrere virtuelle und/oder physische Netzwerkadapter verbindet.

 

[Mitec]

Hallo. Danke. Es ist die Standardkonfiguration von OpenWRT ohne eine Anpassung. Es wurde bisher nur "lan" die IP 192.168.4.1 zugewiesen und als Client mit einem anderen Router (192.168.2.1) verbunden um "lan" mit Internet zu versorgen. Nun soll ein weiteres Netzwerk 192.168.5.1 hinzugefügt werden welches sich wie "lan" verhält. Also DHCP und Internet bereitstellt aber eben in einem anderen Netzwerk mit anderem IP-Bereich.

 

[blurrrr]

Na das ist doch auch richtig so?

WAN: Verbindung zum vorgelagerten Router (Default-Gateway)
LAN: AP-Modus mit eigenem WLAN, welches zusätzlich (vermutlich?) noch in ein lokales Netz gebridged wird (ggf. in Kombi mit LAN-Ports).

 

[Mitec]

Nur wie ich das nun einrichte ist die Frage: einfach die Einstellungen für LAN nehmen und gleich wie IOT?

config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'eth0.1'

config device
    option name 'br-iot'
    option type 'bridge'
    list ports 'eth0.1'

config interface 'lan'
    option device 'br-lan'
    option proto 'static'
    option ipaddr '192.168.4.1'
    option netmask '255.255.255.0'
    option ip6assign '60'

config interface 'iot'
    option device 'br-iot'
    option proto 'static'
    option ipaddr '192.168.5.1'
    option netmask '255.255.255.0'
    option ip6assign '60'

Das habe ich nun gesetzt. Doch 1. vermute ich, dass ich bei 'br-iot' nicht 'eth0.1' verwenden soll.
Und zweitens, noch ist keine Verbindung möglich da DHCP nichts zuweist. Nachdem ich das nun so eingetragen habe, ist wieder kein Zugriff mehr auf den Router möglich...

update:
nach entfernen von 'eth0.1' aus 'br-iot' ist eine Verbindung wieder möglich. Immer aber nur über LAN. WIFI hat noch nie verbunden auch mit fester IP nicht!

 

[blurrrr]

Konfiguriere das ganze doch mal via GUI und schau Dir danach die Config im Textformat an?

 

[Mitec]

Hallo, das habe ich bisher ja, das war jetzt nur ein Versuch um es hier auch besser und eindeutig zu zeigen. Im Gui ist es aber aber exakt das selbe. Die Verbindung mit fester IP klappt nun doch. Auch die Camera ist verbunden (ist statisch hinterlegt).
Es stehen nun zwei Dinge an:
1. DHCP aktivieren
2. Ein Gerät bei der Netzwerkbrücke hinterlegen (wie im letzten Beitrag gezeigt)

Zu 1.: Netzwerkschnittstellen, iot, DHCP-Aktivieren, Neustart. Resultat: DHCP-Server vergibt keine IP

 

[blurrrr]

DHCP ist auch korrekt konfiguriert? Was sagen denn die Logs dazu?

 

[Mitec]

)Ich nutze die Standardeinstellungen für DHCP, ich wüsste nicht wo ich da etwas speziell konfigurieren soll, daher bin ich ja hier

Fri Feb 14 16:22:45 2025 daemon.info hostapd: phy1-ap0: STA b0:00:22:33:44:eb IEEE 802.11: associated (aid 6)
Fri Feb 14 16:22:45 2025 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED b0:00:22:33:44:eb auth_alg=sae
Fri Feb 14 16:22:45 2025 daemon.info hostapd: phy1-ap0: STA b0:00:22:33:44:eb WPA: pairwise key handshake completed (RSN)
Fri Feb 14 16:22:45 2025 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED b0:00:22:33:44:eb
Fri Feb 14 16:23:31 2025 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED b0:00:22:33:44:eb

Update: es lag an der Firewall. Danke für den Tipp mit den Logs

 

[Mitec]

Ok, dann zur Firewall, dort habe ich nun iot => wan in der ersten Spalte. Wenn ich Input auf Reject stelle, ist keine Verbindung mit dem Netzwerk möglich. Das habe ich erwartet. DHCP kommt ja von dort. Merkwürdig ist für mich aber noch: wenn nur Output auf reject steht, dann ist auch keine Verbindung zu dem WLAN IoT möglich... was könnte das den für Gründe haben? Kann der DHCP Server auf dem Router dann einfach die IP Adresse gar nicht an das Gerät senden?

 

[blurrrr]

INPUT/OUTPUT bezieht sich immer auf den Firewall-Host selbst. Wenn nix rein darf (z.B. DHCP-Anfrage), gibt's nix, wenn nix raus darf (z.B. DHCP-Antwort), gibt's ebenso nix. Von einem Netz in ein anderes wäre dann entsprechend FORWARD.

Da der DHCP-Dienst auf dem IoT-Interface durchaus auf a) DHCP-Requests (und ggf. DNS-Anfragen) reagieren sollte und b) auch entsprechende Antworten zurückschicken sollte... Lediglich die Management-Dienste (WebGUI, SSH, etc.) sollten vielleicht nicht aus dem jeweiligen Netz ansprechbar sein (abgesehen von Deiner Management-Kiste bzw. Deinem Management-Netz).

 

[Confluencer]

Ich muss gestehen dass ich hier in dem Topic schon lange nicht mehr durchsteige. Prosa Beschreibungen mangelt es gerne mal an Eindeutigkeit.

Um Deine aktuelle Konfiguration unmissverständlich mit uns zu Teilen helfen folgende Dateien:
- /etc/config/network (komplett!)
- /etc/config/wireless (hier reicht der jeweilige config wifi-iface '<interfacename>' Abschnitt für das WLAN Inteface um das es geht. Achtung option key unbedingt anonymisieren!)
- /etc/config/firewall (komplett!)
- /etc/config/dhcp (hier reicht der jeweilige config dhcp '<netzwerkname>' Abschnitt für das Netzwerk um das es geht)

 

[Mitec]

Nun funktionieren also beide Netzwerke und können untereinander kommunizieren. Nun noch die Verbindung des IoT Netzes ins Internet verbieten. Hierfür will ich Firewall - Traffic Rules einsetzen.
Die Firewall prüft zunächst, ob das Paket für den Router selbst bestimmt ist (also die Ziel-IP-Adresse des Routers) oder für ein anderes Gerät im lokalen Netz. Wenn es für das lokale Netz ist, gilt die Forward-Regel. Ist es für das Internet, wird der Router gefragt (DNS) wohin das Paket gehen soll (Input Regel). Findet er nicht dazu, nutzt er den Output um die Anfrage weiter zu leiten (Output-Regel). Ist das soweit korrekt?

Nur was ich jetzt gehört habe und was wieder Gegensätzlich zu anderen Aussagen ist: hat der Rechner bereits eine Anfrage gestellt und kennt den Weg bereits, dann geht es eben nicht über Input zu dem Router sondern läuft auch über Forward direkt weiter?
Noch mehr durcheinander kommt man dann bei der neuen Bezeichnung der Firewall bei OpenWRT. Da steht nun nicht mehr Forward, sondern "Intra zone forward". Das kennzeichnet, dass es für das interne Zugreifen auf andere Geräte ist.

 

[blurrrr]

Findet er nicht dazu, nutzt er den Output um die Anfrage weiter zu leiten (Output-Regel). Ist das soweit korrekt?

Das ist soweit korrekt (auch der Teil vor dem Zitat), bzgl. DNS schau mal hier rein: https://de.wikipedia.org/wiki/Domain_Name_System#Resolver.

Wenn es für das lokale Netz ist, gilt die Forward-Regel.

Jain... die FORWARD-Chain ist für alles, was nicht die Firewall direkt betrifft und ausserhalb des eigenen Netz-Segments des Hosts läuft (ansonsten würden die Anfragen die Firewall auch erst garnicht erreichen). Netzintern können die Hosts einfach direkt miteinander kommunzieren, das trifft auf die Firewall bzw. das Interface der Firewall in diesem Segment eben auch zu, daher auch "nur" INPUT+OUTPUT, während FORWARD alle Netze ausserhalb des Hosts betrifft. Also "wenn es für das lokale Netz ist", ist so nicht ganz korrekt.

Nur was ich jetzt gehört habe und was wieder Gegensätzlich zu anderen Aussagen ist: hat der Rechner bereits eine Anfrage gestellt und kennt den Weg bereits, dann geht es eben nicht über Input zu dem Router sondern läuft auch über Forward direkt weiter?

Du vermischt da 2 Dinge:

1) DNS
2) Routing

DNS ist wie ein Telefonbuch (s. auch die Anleitung hier von @Barungar). Wenn Du etwas direkt via IP ansprichst, ist DNS egal, wenn Du aber einen FQDN ansprechen willst (host.domain.tld), dann ist DNS involviert bzw. auf Deiner Seite primär ein Resolver (s. o.g. Wikipedia-Artikel). Also, DNS = Telefonbuch, beim Routing könnte man schon fast von einem Navi sprechen (oder selbstfahrenden Autos), der springende Punkt ist allerdings: Entweder kennst Du schon die Adresse von Deinem Ziel, oder Du musst sie erst nachschlagen. Hast Du die Adresse, kann es eigentlich auch schon direkt losgehen, dafür braucht es dann kein DNS mehr. In der Regel nutzen wir heutzutage aber eher DNS-basierte Dinge anstatt direkt öffentliche IP-Adressen, da sich die FQDNs dann doch besser merken lassen. Deine Firewall agiert - in dem von Dir angesprochenen Szenario - dann auch als Resolver und bekommt dadurch - wie Du schon ganz richtig gesagt hast - ebenfalls DNS-Anfragen rein (INPUT) und leitet sie dann entsprechend weiter (OUTPUT). Wenn die Antwort auf die DNS-Anfrage den Client wieder erreicht hat und das Ziel bekannt ist, werden die Pakete an das Ziel geschickt (FORWARD).

Was Du nun meinst, bezieht sich auf die TTL (time-to-live) der DNS-Records, womit der Gültigkeitswert in Sekunden für einen DNS-Record angegeben wird (und dieser befindet sich dann solange in einem lokalen Cache). Verhält sich ungefähr so: Ich suche Deine Adresse raus und fahre hin. Am nächsten Tag fahre ich wieder hin, musste aber nicht mehr nach der Adresse suchen, habe ich ja schon. Würde ich in 10 Jahren nochmal fahren, würde ich vermutlich erstmal wieder nach der Adresse schauen, wer weiss, ob die überhaupt noch gültig ist. Mit der TTL wird dieser Gültigkeitszeitraum (in Sekunden) im DNS pro Record definiert. Bei DynDNS-Adressen beläuft sich das meist auf irgendwas zwischen 60-300 Sekunden (1-5 Minuten), regulär ist es aber oftmals etwas zwischen 1-12 Stunden.

 

[Mitec]

Hallo! Danke für die tolle bildliche Erklärung. Bin ja schon happy, FQDN nicht nachschlagen zu müssen
Resolver ist klar.
DNS Funktion ist klar.

Jain... die FORWARD-Chain ist für alles, was nicht die Firewall direkt betrifft und ausserhalb des eigenen Netz-Segments des Hosts läuft

da fängt der Kopf wieder an zu rauchen

Netzintern können die Hosts einfach direkt miteinander kommunzieren, das trifft auf die Firewall bzw. das Interface der Firewall in diesem Segment eben auch zu,

Aber nur wenn Forward erlaubt? Dann darf das Interface eben kommunizieren.

daher auch "nur" INPUT+OUTPUT,

Wo ist "nur"Input und Output, ich habe doch drei Optionen in der Firewall?

während FORWARD alle Netze ausserhalb des Hosts betrifft.

Bedeutet, alle IP und DNS Anfragen die nicht direkt die IP des Hosts / Routers ansprechen?

Was Du nun meinst, bezieht sich auf die TTL (time-to-live) der DNS-Records

Und das ist dann das Routing? Also, wenn er die Adresse kennt, geht es dann allein oder über Forward wie ich es gelesen habe?
Wenn ja, vermutlich muss er davor ja auf den Router um die Adresse zu bekommen, also ich mache mir wohl umsonst Sorgen, da selbst wenn es dann über Forward gehen könnte es gar nicht gehen wird da er die Infos ja erst durch Input bekommen würde was ja aber nicht erlaubt ist...

Und so führt eine Frage zu 10 neue


Praktisch habe ich nun:

config forwarding
    option src 'lan'
    option dest 'iot'

]config zone
    option name 'iot'
    option input 'REJECT'
    option output 'REJECT'
    option forward 'ACCEPT'
    list network 'iot'

Und damit geht es gut. Da die Camera eine feste IP hat. DHCP ist nun auch geblockt. Logging für die Firewall wurde aktiviert. So konnte ich nun auch sehen, dass die TAPO Camera nicht nur Amazon sondern auch Google (DNS) versucht zu kontaktieren. Das ist der Grund warum ich das abschotten will. Die Camera versucht nun auch ständig Home Assistant zu erreichen, was nun auch blockiert ist, trotzdem funktioniert alles und auch Bewegungserkennung. Evtl. stelle ich den Input wegen den vielen Anfragen später auf Drop.

 

[blurrrr]

Grundsätzlich ist es so, dass Hosts innerhalb eines Subnetzes "ohne" OpenWRT dazwischen kommunizieren können. Um es vielleicht etwas praktikabler zu erklären:

Du hast ein Haus (Dein Heimnetzwerk). Die Haustür führt in die große weite Welt (Internet). Nebst dem gibt es noch den Flur mit div. Zimmertüren, welche alle bestimmten Regeln unterliegen (Firewall) und in div. Zimmer (lokale Netze) führen. Wenn sich nun 2 Teilnehmer in "unterschiedlichen" Zimmern (lokalen Netzen) unterhalten wollen, muss man eben durch die Zimmertüren, womit bestimmte Firewall-Regeln greifen. Befinden sich aber 2 Teilnehmer im gleichen Zimmer, besteht kein Grund, dass das Zimmer durch die Türe verlassen wird. Somit ist die Tür (Firewall) also garnicht in der Kommunikation beteiligt.

da fängt der Kopf wieder an zu rauchen

Eigentlich nicht, entweder... a) Du brauchst die Firewall garnicht, weil sich die Teilnehmer im gleichen Subnetz befinden (Firewall garnicht involviert), b) die Firewall wird direkt angesprochen (INPUT), oder die Firewall greift selbst auf etwas zu (OUTPUT), c) die Firewall soll Pakete von A nach B weiterleiten (FORWARD).

Aber nur wenn Forward erlaubt? Dann darf das Interface eben kommunizieren.

FORWARD ist nur relevant, wenn ein "Routing" stattfindet Wenn Du mit einem Client aus Netz A das Firewall-Interface in Netz A ansprichst, hat das nichts mit Routing zu tun, da die Pakete das lokale Netz ja garnicht verlassen bzw. muss die Anfrage des Clients nicht über irgendwelche Stellen geroutet werden, da die Kommunikation bei direkter Ansprache der Firewall weiterhin in diesem einen lokalen Netz abläuft.

Und weil Bilder manchmal einfach mehr helfen, als etliche schriftliche Erklärungen...:


Rot = FORWARD
Gelb/Orange = INPUT
Grün = OUTPUT
Lila = Pakete verlassen das lokale Netz nicht, Firewall ist nicht involviert

Wo ist "nur"Input und Output, ich habe doch drei Optionen in der Firewall?

FÜR die Firewall (INPUT)
VON der Firewall (OUTPUT)
DURCH die Firewall (FORWARD)

Bedeutet, alle IP und DNS Anfragen die nicht direkt die IP des Hosts / Routers ansprechen?

Richtig, denn alles was nicht "direkt" den Host/die Firewall anspricht, ist somit kein INPUT mehr, sondern will ja einfach nur "durch" und daher eben FORWARD.

Und das ist dann das Routing? Also, wenn er die Adresse kennt, geht es dann allein oder über Forward wie ich es gelesen habe?

Routing beschreibt das "weiterleiten" von Paketen. DNS ist da halt auch ein Thema, das kommt aber "on top".

Beispiel mit 2 lokalen Netzen und je 1 Host in einem Netz:

Netz A: 192.168.1.0/24
Host A: 192.168.10

Netz B: 192.168.2.0/24
Host B: 192.168.2.20

Router zwischen diesen Netzen:
NIC-A: 192.168.1.1
NIC-B: 192.168.2.1

Grundsätzlich lautet das Verhalten beim Routing wie folgt: Wenn Du (gemeint ist hier der Router, welcher das Paket grade verarbeiten soll) das entsprechende Zielnetz nicht kennst, schicke das Paket einfach weiter an Dein Standard-Gateway. Sehr gut erklären kann man sowas (mal wieder) mit einem Bild:


Es soll ein Paket aus Netz "A" (ganz links) ins Netz "H" (ganz rechts). Der Sender in Netz A wird zuerst schauen, ob er das Paket lokal (ohne Routing) zustellen kann. Ist das nicht der Fall und der Sender kennt keine spezifische Route zum Ziel, wird das Paket kurzerhand an sein Standard-Gateway übergeben (in diesem Fall R1). Dann fängt der Tanz wieder von vorne an: Bin ich im gleichen Netz? Kenne ich eine spezifische Route (in diesem Fall kennt R1 halt nur A, B und C, aber nicht H)? Alles nicht... nagut, weiter geht's zum Standard-Gateway (von R1) was dann wiederum R2 entsprechen würde. Gleiches Spiel von vorne, usw. bis dann irgendwann R4 sagt: MOMENT! Kenn ich, kann ich, hab ich! So erreicht das Paket dann schlussendlich den Zielhost im Netz "H". Die dicken Router im Internet agieren da noch anders, aber ist für jetzt erstmal nicht relevant.

So, nachdem das mit dem Routing jetzt mal kurz geklärt ist, flott zurück zu 192.168.1.x und 192.168.2.x... Also entweder ist die Ziel-IP schon bekannt, dann hat DNS da überhaupt nichts mehr mit zu tun. Dann ist es so wie von Dir beschrieben, es funktioniert sein. Sagst Du also: 192.168.1.10 zu 192.168.2.20, wird das einfach so funktionieren (muss natürlich in der Firewall erlaubt sein).

Nehmen wir jetzt aber mal an, dass wir die IP von 192.168.2.20 eben nicht wissen, dafür aber den Hostnamen kennen (z.B. "mein-host.int.domain.tld"), müssen wir halt erstmal irgendwen fragen, der uns den FQDN zu einer IP auflösen kann, damit wir unser Paket für den Zielhost überhaupt abschicken können. Ohne Adresse wird es halt schwierig irgendwas mit der Post zu schicken... Wenn der Postbote ein Paket für "blurrrr" zustellen soll, wird er vermutlich einfach mit den Achseln zucken und das Paket erst garnicht mit auf seine Tour nehmen. Also muss der FQDN vorher in eine IP aufgelöst werden und zuständig dafür ist eben der DNS-Dienst bzw. konkreter auf "Deiner" Seite primär ein DNS-"Resolver" (sofern man nicht noch anderweitige Dinge diesbezüglich einsetzt).

Da gibt es nun 2 Möglichkeiten:

1) Du nimmst einen lokalen Resolver (z.B. innerhalb des gleichen Subnetzes, z.B. auch die Firewall/den Router). Der Klassiker ist ja "lokaler Router übernimmt DHCP, DNS und Routing", quasi die "eine" Kiste die quasi alle Zuhause stehen haben. Das wäre dann die INPUT-Chain auf der Firewall.
2) Du nimmst einen externen DNS (anderes lokales Netz, oder etwas im Internet). Das wäre dann die FORWARD-Chain, da es ein Routing bis zum Ziel-DNS-Resolver inkludiert.

<Ende Teil 1>

 

[blurrrr]

Wenn ja, vermutlich muss er davor ja auf den Router um die Adresse zu bekommen, also ich mache mir wohl umsonst Sorgen, da selbst wenn es dann über Forward gehen könnte es gar nicht gehen wird da er die Infos ja erst durch Input bekommen würde was ja aber nicht erlaubt ist...

Naja, vergiss dabei nicht, dass es einen sehr großen Unterschied machen kann. Angenommen Du verbietest DNS via INPUT-Chain, bedeutet das ja, dass der Client aus Netz X die Firewall nicht als DNS-Resolver nutzen kann, welcher ggf. auch standardmässig via DHCP zugewiesen wurde. Das sieht dann z.B. so aus:

192.168.1.100 -> DNS (53/UDP) -> 192.168.1.1 = Nö!

Ist auch gut und richtig so, hast Du ja in der Firewall so definiert. ABER... was hindert jetzt den Client daran, einfach einen anderen DNS-Resolver zu kontaktieren? Du kannst natürlich hingehen und folgendes machen:

192.168.1.100 -> DNS (53/UDP) -> ANY = Nö!

Jut, sowas hätte früher vielleicht noch geklappt, aber mittlerweile gibt es auch DoT (DNS-over-TLS) und DoH (DNS-over-HTTP) und spätestens bei letzterem, wird es problematisch. Insofern wäre sowieso anzuraten, dass das IoT-Netz einfach "nirgendwohin" darf - also zumindestens nicht "eigenständig". Das wäre dann also eher ein Fall für die FORWARD-Chain, das IoT-Netz darf einfach nicht irgendwohin.

Die Camera versucht nun auch ständig Home Assistant zu erreichen, was nun auch blockiert ist, trotzdem funktioniert alles

Konkret betrachtet gestaltet es sich ja so, dass der HA-Host das Bild von einer Cam abgreift. Also von Netz A zu Netz B, was wiederum aber nicht bedeutet, dass Netz B auch (eigenständig) auf Netz A zugreifen muss (und somit im besten Fall auch nicht darf). Da die Firewall i.d.R. "stateful" ist, darf die "Antwort" auf eine Anfrage auch wieder zurück. Es dürfen aber keine "ausgehenden" Anfragen aus Netz B über die Firewall hinaus.

So konnte ich nun auch sehen, dass die TAPO Camera nicht nur Amazon sondern auch Google (DNS) versucht zu kontaktieren. Das ist der Grund warum ich das abschotten will.

Es ist relativ normal, dass Geräte versuchen irgendwas im Internet zu kontaktieren (z.B. zwecks Updates). Halte Dich einfach an folgenden Grundsatz: "So wenig wie möglich, soviel wie nötig". Heisst kurzum: Erstmal ist "alles" verboten, erlaub ist nur, was Du explizit definierst.

Die Camera versucht nun auch ständig Home Assistant zu erreichen, was nun auch blockiert ist, trotzdem funktioniert alles und auch Bewegungserkennung.

Bist Du Dir 100%ig sicher, dass die Cam versucht den HA-Host zu kontaktieren? Oder ist es vielleicht nur eine "Antwort" auf eine vorherige Anfrage vom HA-Host? Ein sehr großer Unterschied

So, das soll nun aber erstmal reichen, hast ja nun erstmal reichlich zu lesen