Routing-Problem: zwei Geräte im gleichen WLAN mit unterschiedlichen Routen

[viragomann]

Meine größte Sorge sind tatsächlich eigenmächtige Browser und DoH. Ich denke, die habe ich mit meinem Setup ganz gut im Griff.

Wenn du hier vielleicht einen Link zu einem Thread hättest, wo du das DoH Blocking erklärt hast, wäre ich dankbar.

Ich komme von pfSense. Da macht das der pfBlocker, den wohl fast jeder Überläufer erst mal vermisst.

[Patrick M. Hausen]

Meine größte Sorge sind tatsächlich eigenmächtige Browser und DoH. Ich denke, die habe ich mit meinem Setup ganz gut im Griff.

Wenn du hier vielleicht einen Link zu einem Thread hättest, wo du das DoH Blocking erklärt hast, wäre ich dankbar.

Ich komme von pfSense. Da macht das der pfBlocker, den wohl fast jeder Überläufer erst mal vermisst.

Ich blocke ausgehendes DNS (UDP/TCP 53) und DoT (UDP/TCP 853) per Firewall-Regel und gebe allen Clients meinen AdGuard Home auf der OPNsense als Resolver. Letzteres per Portforwarding von LAN address:53 nach 127.0.0.1:53530. Funktioniert prima, primary DNS bleibt damit der Unbound, und in Server-Netzen, wo ich nicht filtern will, ist der auch der Resolver.

In AGH habe ich dann eine Blocklist für DoH-Server abonniert. Da DoH immer erst mal ein konventioneller Lookup vorausgeht, ist das das Beste, was man m.E. tun kann.

[viragomann]

Okay, danke!

Adguard heißt hier das Zauberwort. Das habe ich noch nicht probiert. Habe da Hemmung, einen Kommerziellen Anbieter ins Spiel zu bringen.
Das Blocken der Ports mache ich soweit.

[Patrick M. Hausen]

AdGuard Home - open source.

[viragomann]

Wusste ich nicht.
Bin noch zu neu hier...

[Patrick M. Hausen]

Github:
https://github.com/AdguardTeam/AdGuardHome

Zum Installieren auf OPNsense dieses Repo einbinden:
https://www.routerperformance.net/opnsense-repo/

[Sylvan86]

In AGH habe ich dann eine Blocklist für DoH-Server abonniert. Da DoH immer erst mal ein konventioneller Lookup vorausgeht, ist das das Beste, was man m.E. tun kann.

Zur Ergänzung, wenn man noch eins drauf setzen möchte (auch aus meiner Sicht, sollte bereits das Blocken auf Domain-Ebene reichen): Es gibt zusätzlich zu den Blocklisten der DoH-Domains auch Listen mit IP-Adressen dieser Server (z.B. von HaGeZi oder DibDot aus dem OpenWRT-Umfeld).

Diese kann man dann einfach als Alias abonnieren und in den Firewall-Regeln verwenden.
Ein denkbares Problem wäre, dass auf den Servern auch noch andere Dienste laufen, welche man dann natürlich nicht mehr erreichen könnte. Aber in der Regel sind diese Server DoH-only.

Es gibt IoT Geräte, die haben eine DNS IP fix eingebrannt. Erreichen sie diese nicht, versagen sie den Dienst.

Ich weiß, solche Geräte hat man nicht, aber man weiß das erst nach dem vermeintlich günstigen Kauf und dann möchte man ein Lösung.

Du könntest noch anstatt DNS-Anfragen, welche nicht an deinen eigenen DNS-Dienst gehen, zu blocken diese Anfragen stattdessen umschreiben.
Sprich: Jegliches Paket aus dem LAN auf Port 53 was nicht an deinen Adblock-DNS-Server gerichtet ist, umleiten auf eben diesen.
Die Clients erhalten dann die Antwort nicht von dem Server den sie im Sinn hatten.
Aber Anfragen Richtung z.b. 8.8.8.8 kommen mit einer Antwort zurück.
Auf die Art erreichen die Clients ihren gewünschten Server scheinbar und sollten zufrieden sein, solange sie nicht die Authentizität des Servers anderweitig prüfen.

[Patrick M. Hausen]

Du könntest noch anstatt DNS-Anfragen, welche nicht an deinen eigenen DNS-Dienst gehen, zu blocken diese Anfragen stattdessen umschreiben.
Sprich: Jegliches Paket aus dem LAN auf Port 53 was nicht an deinen Adblock-DNS-Server gerichtet ist, umleiten auf eben diesen.

Genau das ist das Thema dieses Threads 

[white_rabbit]

Hallo.
Ok, ich könnte natürlich vom Pi-Hole auf AdGuard wechseln. Installiert und eingerichtet ist das ja relativ schnell.
Dennoch ist mir eine Sache nicht ganz klar: Warum macht ausgerechnet der Traffic über DNS bzw das Pi-Hole hier das Problem, dass die Outbound-Regeln notwendig werden? Das Pi-Hole ist zwar im Moment im gleichen Netz wie die WiFi-Clients (wobei mir nicht bewusst war, dass das nicht so sein soll) -- aber was haben die DNS-Anfragen auf das Pi-Hole mit NAT zu tun?

Die Erklärung, warum man keine Regel im selben Netz der o.g. Form haben sollte, ist mir daher in der Theorie halbwegs klar -- nur: In der Praxis habe ich so eine Regel meines Wissens gar nicht eingerichtet.

Die Geräte, die hier im Einsatz sind, sind fast nur iPads -- also keine IoT-Geräte, wie sie weiter oben angesprochen wurden.
Kann natürlich sein, dass die iPads da irgendwas aus "convenience-Gründen" eigenmächtig einstellen oder sich einen eigenen DNS-Server aussuchen, wenn das vorgegebene aus irgendwelchen Gründen nicht erreichbar ist. Aber selbst dann sind das doch keine TCP Requests wie in dem o.g. Beispiel, oder?

Aber wie auch immer: Etwas stimmt hier im WLAN offensichtlich nicht und es ist super, dass ich jetzt einen guten Anhaltspunkt habe!

[Patrick M. Hausen]

DNS-Clients ignorieren Antworten, die von anderen Adressen kommen als denen, an die sie die Anfrage geschickt haben.

Hatte @viragomann auch schon ausgeführt.

Client schickt Anfrage an 8.8.8.8.
Antwort kommt vom PiHole in deinem Netz.
Antwort wird ignoriert.

[viragomann]

@Patrick
Danke nochmals für die Links.

Aktuell evaluiere ich OPNsense für den gewerblichen Einsatz. Soll dann auch eine Lizenz bekommen.
Da habe ich den Bedarf, DoH zu blocken, nicht. Ist ein reines Server-Netz.
Aber bei Gefallen stelle ich vielleicht meine Heim-pfSensen auch um. Dann wäre es doch interessant.

Zur Ergänzung, wenn man noch eins drauf setzen möchte (auch aus meiner Sicht, sollte bereits das Blocken auf Domain-Ebene reichen): Es gibt zusätzlich zu den Blocklisten der DoH-Domains auch Listen mit IP-Adressen dieser Server (z.B. von HaGeZi oder DibDot aus dem OpenWRT-Umfeld).

Danke. Werde ich mir auch vormerken.

Ansonsten solltest du erst die Postings des Threads lesen. Wir haben das weitere schon lang und breit hier ausgeführt.

Ok, ich könnte natürlich vom Pi-Hole auf AdGuard wechseln.

Die OPNsense Konfiguration ist im Grunde für beide dieselbe, einzig...

Warum macht ausgerechnet der Traffic über DNS bzw das Pi-Hole hier das Problem, dass die Outbound-Regeln notwendig werden?

...das Problem ist, dass dein pihole im selben Subnetz läuft wie die Geräte, deren Abfragen auf ihn umgeleitet sind.

Ich will jetzt nicht zählen, wie oft ich schon versucht habe, das hier klarzustellen.
Der pi hat doch auch einen Kabelanschluss. Also nimm ihn und schließe ihn direkt an OPNsense an und gib ihm ein eigenes Subnetz, und alles ist gut.

Wenn deine Geräte ihr DNS Anfragen aus demselben Subnetz an den pihole schicken > kein Problem.
Wenn deine einen öffentlichen (oder irgendeinen außerhalb ihres Subnetzes) und abfragen > Abfragen gehen und OPNsense und werden da auf den pihole in dasselbe Subnetz zurück geleitet, kommt es zur asymmetrischen Paketvermittlung und der Client akzeptiert die Rückmeldung nicht, weil sie von der falschen IP kommt, sofern kein S-NAT gesetzt ist.

Deutlicher als im Beispiel oben, kann man das, denke ich, gar nicht mehr darstellen. Wenn du das nicht verstanden hast, lass Netzwerken besser bleiben.

Die Geräte, die hier im Einsatz sind, sind fast nur iPads -- also keine IoT-Geräte, wie sie weiter oben angesprochen wurden.

Die sind bekannt dafür, dass sie gerne DNS über HTTPS nutzen, und das kannst du schlecht umleiten, bestenfalls blockieren. Verschläge dafür wurden in diesem Thread auch schon gemacht.

[white_rabbit]

(Nachtrag: Sorry @viragomann -- hatte Deine letzte Antwort vorher nicht gesehen, weil ich vermutlich gerade zeitgleich selbst geantwortet habe)

Screenshot 1: Ok, machen wir es konkret. Ich habe AdGuard auf der OPNSense installiert und auf Port 5310 in Betrieb genommen. Das ganze sieht dann so aus.

Screenshot 2: Offenbar läuft der Service also und beantwortet Anfragen auf Port 5310 auf den beiden angegebenen Adressen.

Screenshot 3: Aus dem Netz 192.168.1.0/24 wird gemeldet: Der Port ist offen -- da kommen die Anfragen auch bei der OPNSense bzw beim AdGuard an. Das habe ich ausprobiert.

Funktioniert alles so wie es sein soll...

Aber ...

[Monviech (Cedrik)]

Zum ganzen NAT Reflection Thema hab ich mal einen größeren docs Artikel verfasst. Da werden auch die Probleme erklärt wie Source NAT für Geräte im gleichen Netzwerk.

https://docs.opnsense.org/manual/how-tos/nat_reflection.html

[white_rabbit]

Aber man sieht in den weiteren Screenshots das Problem. Ich habe dann das gleiche von einem Client im WLAN gemacht.

Hier die Screenshots:
In Screenshot 1 sieht man, dass der Port nun als "Closed" gemeldet wird -- verstehe ich nicht!?

In Screenshot 2 (s.u.) habe ich Wireshark benutzt und zunächst eine reguläre DNS-Anfrage über Port 53 an die OPNSense geschickt -- die kommt an.

In Screenshot 3 (s.u.) habe ich mit  Wireshark untersucht, was mit einer Anfrage auf Port 5310 los ist. Das kommt offenbar nicht ... bleibt die Frage, warum der Port angeblich dicht ist?
Wenn ich das gleiche über die OPNSense selbst mache, funktioniert es:

Code: [Select]

dig heise.de @172.16.16.254 -p5310
von der OPNSense aus liefert das richtige Ergebnis.

[white_rabbit]

Screenshot 2: