Hallo,
es gibt dafür bereits einige Threads etc. Allerdings hatte ich immer wieder die Schwierigkeit, dass einzeln genommen keine wirklcih funktioniert hat bei mir. Aktuell klappt es mit einem Mix aus mehreren Posts ich würde aber gerne wissen, ob die Einstellungen so korrekt sind.
Es geht darum Clients zu zwingen PiHole zu verwenden und ggf. die Anfragen dahin umzuleiten. Es wurden dazu der Post auf labzilla DNS SmartTV und Threads im hier im Forum verwendet.
Setup: OPNSense ist Gateway, PiHole DHCP und DNS Server
Interface LAN:
1. Regel -> Erlaube DNS Anfragen von PiHole
2. Regel -> Blocke alle DNS anfragen LAN NET
NAT Port forward:
1. Regel: Alle DNS Anfragen die nicht von PiHole kommen und nicht zu PiHole wollen redirecten zu PiHole DNS Port
Allerdings hatte ich damit nicht den gewünschten Erfolg. Wenn ich auf nem Windows Client nen public DNS Server hinterlegt hatte aber einen nur intern verfügbaren Namen auflösen wollte klappte das nicht.
Also noch eine Outbound Rule hinzugefügt
1. Anfragen mit Source LAN Net mit dem Ziel PiHole und Port DNS erfolgt Translation / Target Interface Adress
Und so funktioniert es dann. Interner Windows Client mit fest eingetragenem externen DNS 8.8.8.8 kann nur intern verfügbare Domains auflösen
Ich würde nun gerne wissen, ob das so sinnig ist (ja, es funktioniert) oder ob man es schöner lösen kann und ob ich für Wireguard Road Warriors (iPhone, Notebook), die sich zu Hause einwhählen auch die Outbound und NAT Port Forward Rule entsprechend analog hinterlegen muss?
Quote from: carepack on September 01, 2025, 06:48:55 PMIch würde nun gerne wissen, ob das so sinnig ist (ja, es funktioniert)
Ja, alle Settings sind nötig, damit es funktioniert.
Quote from: carepack on September 01, 2025, 06:48:55 PModer ob man es schöner lösen kann
Ja, man könnte den PiHole in ein eigenes Netzwerksegment legen.
Dann wäre die Outbound NAT Regel überflüssig. Damit würde der Pi DNS die tatsächlichen Client IPs sehen anstatt jener der OPNsense.
Quote from: carepack on September 01, 2025, 06:48:55 PMund ob ich für Wireguard Road Warriors (iPhone, Notebook), die sich zu Hause einwhählen auch die Outbound und NAT Port Forward Rule entsprechend analog hinterlegen muss?
Die Road Warriors kannst du erstmal nicht zwingen, DNS Anfragen zum VPN Server zu senden. Sie können das nur freiwillig tun.
Die Outbound NAT Regel ist nicht nötig. Die wird nur benötigt, wenn DNS Clients und Server im selben Netzwerksegment liegen.
Die Port Forwarding Regel macht Sinn für den Fall, dass die DNS Anfrage an der OPNsense ankommt, aber zum Internet raus will. D.h., wenn der gesamte Upstream Traffic der Clients über die VPN geroutet wird.
Edit:Möchte noch hinzufügen, die Block-Regel ist in meinen Augen überflüssig. Denn alle DNS Anfragen, die von anderen Geräten als dem PiHole kommen und ein anderes Ziel als diesen haben, werden ohnehin umgeleitet und erlaubt.
Was da übrig bleibt, ist gleich null.
Aber ich weiß, manche Leute schlafen dennoch besser, wenn sie das zusätzlich noch blockieren.
Du könntest aber erwägen, DNS ober HTTPS zu blockieren, um hier den Clients keine Alternative zu ermöglichen. Dafür gibt es IP-Listen im Internet.
Quote from: viragomann on September 01, 2025, 07:21:40 PMQuote from: carepack on September 01, 2025, 06:48:55 PMIch würde nun gerne wissen, ob das so sinnig ist (ja, es funktioniert)
Ja, alle Settings sind nötig, damit es funktioniert.
Quote from: carepack on September 01, 2025, 06:48:55 PModer ob man es schöner lösen kann
Ja, man könnte den PiHole in ein eigenes Netzwerksegment legen.
Dann wäre die Outbound NAT Regel überflüssig. Damit würde der Pi DNS die tatsächlichen Client IPs sehen anstatt jener der OPNsense.
Quote from: carepack on September 01, 2025, 06:48:55 PMund ob ich für Wireguard Road Warriors (iPhone, Notebook), die sich zu Hause einwhählen auch die Outbound und NAT Port Forward Rule entsprechend analog hinterlegen muss?
Die Road Warriors kannst du erstmal nicht zwingen, DNS Anfragen zum VPN Server zu senden. Sie können das nur freiwillig tun.
Die Outbound NAT Regel ist nicht nötig. Die wird nur benötigt, wenn DNS Clients und Server im selben Netzwerksegment liegen.
Die Port Forwarding Regel macht Sinn für den Fall, dass die DNS Anfrage an der OPNsense ankommt, aber zum Internet raus will. D.h., wenn der gesamte Upstream Traffic der Clients über die VPN geroutet wird.
Edit:
Möchte noch hinzufügen, die Block-Regel ist in meinen Augen überflüssig. Denn alle DNS Anfragen, die von anderen Geräten als dem PiHole kommen und ein anderes Ziel als diesen haben, werden ohnehin umgeleitet und erlaubt.
Was da übrig bleibt, ist gleich null.
Aber ich weiß, manche Leute schlafen dennoch besser, wenn sie das zusätzlich noch blockieren.
Du könntest aber erwägen, DNS ober HTTPS zu blockieren, um hier den Clients keine Alternative zu ermöglichen. Dafür gibt es IP-Listen im Internet.
Hi viragomann,
vielen Dank für deinen Input :-). Hilft mir sehr.... DoT hab ich generell geblock und DoH über Blocklisten. Die Blocklisten hab ich auch auf dem PiHole hinterlegt, der da schon einiges wegblockt. Trotzdem hab ich sie auch auf der OPNSense hinterlegt. Da die OPNsense auch den PiHole für DNS nutzt hab ich auf dem PiHole eine neue Group hinterlegt in der nur die OPNsense ist und die DoH Blocklisten nicht angewendet werden, damit OPNsense wiederum die Alias abfrage machen kann und die entsprechenden IPs bekommt.
Quote from: carepack on September 04, 2025, 10:44:15 AMDoT hab ich generell geblock und DoH über Blocklisten. Die Blocklisten hab ich auch auf dem PiHole hinterleg
Blocklisten für DoH?
Aber der PiHole ist nicht das Default Gateway.
Wenn ein Webbrowser DoH nutzen möchte, fragt er den PiHole nicht um Erlaubnis, der baut die Verbindung direkt über den Router zum gewünschten Server auf.
Wenn OPNsense das Default Gateway ist, kann das nur da geblockt werden.
Für DoH muss der Browser aber die IP-Adresse des DoH-Servers abfragen. Wenn du also:
- die Verwendung des "einen wahren" Resolvers erzwingst
- DNS-Abfragen (regulär UDP/TCP 53 oder DoT) daran vorbei sperrst
- auf dem Resolver eine gepflegte Blockliste für DoH hast, z.B. Hagezi
dann ist es so gut wie man es m.E. hinbekommen kann.
Ah ja, macht Sinn.
Jedenfalls für die meisten Clients, die die IP tatsächlich erst abfragen. Meines Wissens tun das aber nicht alle.
Müssen sie doch - DoH ist HTTPS, braucht zuerst einen FQDN, dann ein gültiges Zertifikat. Zertifikate für IP-Adressen gibt es m.W. für HTTPS nicht. Also ist da immer zuerst ein normaler Lookup.
Bleibt noch DoT... ;-)
853 sperren, fertig. Hatte ich auch schon aufgelistet.
Hi und vielen Dank für die Beteiligung zu meiner Frage. So wie Patrick es darstellt war auch mein Gedanke, welcher jetzt nochmal bestätigt wurde.
@viragomann - ich hatte auch zuerst meine Zweifel ob da nicht doch as vorbeigeht und deswegen nochmal auf ip basis auf der opnsense hinterlegt. Aber die logik ist wie patrick sie beschrieben hat auch wenns erstmal nicht logisch klingt, dass doh sich selber ersteinmal auflösen muss... aber pihole blockt es schön weg und das wollte ich erreichen: alle anfragen an pihole und wenn du dich absolut weigerst meinen pihole dns zu nutzen, dann block ich dich. klar, mit blocklisten hängst immer ein wenig hinterher, aber alles besser wie ohne :-)
Für den Fall, dass ips von doh servern hart-codiert sind, darf die opnsene eben auch noch blocken. hagezi hat dafür extra ein liste mit ip adressen, die nicht vorher aufgelöst werden müssen und direkt verwendet werden kann.
Besten Dank euch nochmal. @meyergru -> dot ist mit port 853 einfach geblockt und somit erledigt.
Ja, hatte ich überlesen, sorry.