Pi-Hole als System-DNS

[Crocogator]

Hallo,

Irgendwie hänge ich mit meiner Sense an einem „Denk“-Problem fest:

Setup: Ich habe einen Raspi 4 mit dem Pi-Hole (v4.3.1) und lokalem Unbound Service per LocalHost an einem separaten Interface (OPT1, igb2) der Sense (v20.1.a_120-amd64) angeschlossen. Pi-Hole soll sämtliche DNS Anfragen der Sense „bearbeiten“. Dazu sind auf der Sense „Services: Dnsmasq DNS: Settings“ sowie „Services: Unbound DNS: General“ disabled. Als einziger DNS Server ist im Setup der Sense die IP-Adresse des Pi-Holes unter „System: Settings: General“ eingetragen. Die beiden Optionen unter „DNS server options“ sowie „Gateway switching“ sind nicht „angekreuzt“. Für die DHCP IP-Adressenmetrik ist die MAC-ID des Raspis als statistisches Interface Mapping unter „Services:DHCPv4: [OPT1]“ eingetragen. Raspi kann sämtliche Netze (LAN, WAN) per Ping erreichen, ebenfalls wird Raspi aus diesen per Ping erreicht.

Problem: Die Sense IGNORIERT für eigene DNS-Anfragen den als System DNS eingetragenen Pi-Hole:

root@OPNsense:~ # host intel.de 192.168.10.9
Using domain server:
Name: 192.168.10.9
Address: 192.168.10.9#53
Aliases:

Host intel.de not found: 2(SERVFAIL)

Grundsätzlich werden allerdings (auch nicht eingetragene) externe DNS-Server erreicht:

root@OPNsense:~ # host intel.de 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

intel.de has address 13.91.95.74
intel.de mail is handled by 100 mtab.intel.com.

Wird hingegen ein externer DNS-Server (z.B. 8.8.8. unter „System: Settings: General“ eingetragen, dann wird die DNS-Anfrage ebenfalls korrekt aufgelöst:

host intel.de
intel.de has address 13.91.95.74
intel.de mail is handled by 100 mtab.intel.com.

Wird der Pi-Hole im Setup unverändert an einem LAN-Switch des Routers (FB) angeschlossen und als DNS-Server verwendet, so funktioniert alles prima, Pi-Hole tut also was er soll.

Auch wenn der Raspi an de Sense-Interface angeschlossen ist, so kann auf der SSH-Console des Raspis sowohl auf die Sense als auch auf das Internet zugegriffen werden. Auch funktioniert die DNS-Auflösung:
 
xxx@RaspiPi4:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.10.9  netmask 255.255.255.0  broadcast 192.168.10.255
        inet6 fe80::dea6:32ff:fe07:XXXX  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:07:XX:XX  txqueuelen 1000  (Ethernet)
        RX packets 82766  bytes 10538900 (10.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 86669  bytes 14082819 (13.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Lokale Schleife)
        RX packets 512837  bytes 123663752 (117.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 512837  bytes 123663752 (117.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

• Raspi hat per DHCPv4 die korrekte IP-Adresse (192.168.10.9) bezogen,

xxx@RaspiPi4:~ $ route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.10.1    0.0.0.0         UG    0      0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0

• Raspi hat als Standard-Gateway (192.168.10.1) die OPT1 Interface IP Adresse der Sense für die Default-Route bezogen,

xxx@RaspiPi4:~ $ cat /etc/resolv.conf
# Dynamic resolv.conf file for glibc resolver generated by resolvconf
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search localdomain

• Raspi verwendet als DNS-Server den Unbound Service per LocalHost.

Auch die lokale DNS-Auflösung auf dem an der Sense angeschlossenen Raspi funktioniert:

xxx@RaspiPi4:~ $ dig intel.de @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> intel.de @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19619
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;intel.de.                      IN      A

;; ANSWER SECTION:
intel.de.               3600    IN      A       13.91.95.74

;; Query time: 198 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Fr Sep 06 20:21:16 CEST 2019
;; MSG SIZE  rcvd: 53

Warum verweigert die Sense den als System-DNS eingetragenen Pi-Hole? Wo ist der Wurm drin?

[dsecure]

Moin,

Du musst oder solltest sämtlichen DNS Traffic auf das Pi-Hole umleiten, per FW Rules versteht sich.

schau dir mal den Link an -> https://forum.opnsense.org/index.php?topic=9245.msg41626#msg41626

[Crocogator]

Moin moin dsecure,

Zunächst einmal Danke für den Link, allerdings geht s so nicht bei mir:

• Der Pi-Hole "sitzt" an einem sparaten Port (OPT1), also nicht auf dem LAN-Interface.
• Der Pi-Hole verwendet selbst Unbound zur DNS-Auflösung, daher macht Unbound auf der Sense wenig Sinn.
• Auch nach einer Adaption der Forward Regeln (statt localhost die IP vom Pi-Hole) geht s nicht.
• Für die DHCP Services verwende ich Dnsmasq, aber der löst keine DNS-Anfragen auf.
• Die von Pi-Hole ausgelösten DNS-Anfragen versuche ich per Redirekt wieder einzufangen, um sie dann in den VPN Tunnel einzuleiten, damit diese Port-53 Requests erst beim VPN Provider aus dem Tunnel ins Internet geroutet werden.

Sobald ich nur den Pi-Hole als System-DNS eintrage, ist alles andere egal, die Sense macht keine DNS-Abfragen mehr!
Erst mal vielen Dank, gibt es weitere Vorschläge?

[dsecure]

Wie hast du die FW Regeln definiert, es wundert mich das einerseits der Raspi rauskommt und DNS resolven kann aber die Sense nicht über den Raspi.

Hast du auch mal versucht den raspi ohne sense zu betreiben, worauf ich hinaus will ist, dass evtl. der Pi für sich selbst resolven kann aber ein Problem mit der Weiterreichung an den Client besteht.

[Crocogator]

Bezüglich der Regeln bin ich gerade dabei, diese komplett neu zu gestalten und zu testen. Wird noch etwas dauern.

Ohne Sense (z.B. an einer Fritzbox) funktioniert der Pi problemlos.

Ich vermute allerdings auch, das die vom Pi ausgelösten Unbound DNS Requests (via LocalHost auf dem Pi) nur von der Sense durchgereicht werden (Pi kann ja DNS korrkt auflösen), aber NICHT für die Sense-interne Namensauflösung verwendet werden. Damit bekommt der Pi seine korrekte DNS-Auflösungsantwort, aber die Sense benutzt die Antwort nicht.

Paket Transport Weg:

LAN-Client (Windows) --> DNS Router (Fritzbox) --> DNS Gateway Sense (via DHCP) --> Forwarded to Pi@OPT1 Port --> Pi-Hole Filter --> Pi@127.0.0.1 (Unbound) --> DNS Standard-Gateway Sense für UDP-Port 53 Pakete --> Redirektion to VPN Tunnel --> Tunnelaustritt beim VPN Provider --> authoritative/Root Server DNS Server Kontakt (und dann die Kette wieder retour).

Ich versuche das Problem weiter zu verstehen ...

[dsecure]

Oke, hat es einen Grund warum du einen Fritz DNS Router vor der Sense hast oder verbindest du 2 Netzwerke via VPN miteinander?

Verstehe nicht den Grund das es kompliziert sein muss, würde sowie so keine Fritzbox hinter der FW betreiben...

Wäre das nicht einfacher?
Client -> Sense -> PiHole -> VPN/Fritz -> ISP    (So habe ich es gelöst)

oder per VPN Einwahl:
Client -> GW/VPN -> Sense -> PiHole -> Sense -> GW

mach mal einen nslookup bzw. dif vom client, der Sense und vom Pihole selbst, damit du sehen kannst wer deine DNS auflöst.

Es gibt eine Einstellung, die es verbietet einen override zu machen bei der DNS konfig, bin gerade beschäftigt aber ich kann gerne nach her nochmal nachsehen ob ich die Einstellung finde.


Edit:

Bei mir liefert ein  -> dig intel.de @127.0.0.1 -p 53                                   
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> intel.de @127.0.0.1 -p 53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44143
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;intel.de.                      IN      A

;; ANSWER SECTION:
intel.de.               900     IN      A       13.91.95.74

;; Query time: 412 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: So Sep 08 21:51:59 CEST 2019
;; MSG SIZE  rcvd: 53


Ich denke dein Raspi macht das was er soll, das Problem müsste wo anders liegen

Edit2:

Dein Dnsmasq auf der Sense hast du als forwarder konfiguriert?

[Crocogator]

So, das Testen der Sense hat doch sehr viel mehr Zeit gefressen als gedacht, aber nun habe ich zumindest jeden Menüeintrag einmal gesehen ...

Mein zentrales Problem scheint zumindest ansatzweise gelöst, aber der Reihenfolge nach:

Zur Architektur nochmals Folgendes:

• Alle Endpunkte (Windows PC, Smartphones, Notebooks) sind per WLAN "ganz üblich" über eine FB konnotiert, die mit Ihrem WAN-Interface an einem Sense-Port "hängt". Die FB wird nur als WLAN-Host benutzt, da dies wesentlich komfortabler ist als beispielsweise die Sense mit einem WLAN Netz auszurüsten. Die FB "verteilt" Standard-Gateway und DNS-Server via DHCP, dabei trägt sich die FB selbst als Standard-Gateway und DNS-Server im Heimnetz ein. Geprüft und ok, aber wenn man vergisst, nach Änderungen die lokalen Caches zu löschen, steht man ziemlich im Wald!!

• Auf der WLAN ("Internet") Seite der FB "holt" sich die FB selbst per DHCP von der Sense am LAN-Interface die Gateway- und DNS-Server Koordinaten. Die Sense wird dabei das Standard-Gateway und die IP-Adresse des Pi (Pi-Hole) wird als DNS-Server übermittelt (beides geprüft und ok).

• DNS-Anfragen werden (habe ich überprüft!) so sämtlich an Pi-Hole übermittelt. Auch dies kann man sehr schön im Log (Pi-Hole Dashboard) sehen. Diese schickt nach Filterung die DNS Fragen via LocalHost an den DNS-Resolver (Unbound) - alles Pi-lokal - und gibt die Ergebnisse der Namensauflösung an die Sense zurück. Auch dies lässt sich gut bestätigen (Host Anfrage der Sense z.B. auf der Konsole) und funktioniert.

• Die von Pi-Unbound erzeugten DNS Anfragen werden über den OPT1 Port an die Sense (Standard-Gateway) geschickt. Hier muss noch geprüft werden, ob diese über den VPN Tunnel oder normal per WAN transportiert werden. Auch sind noch Fragestellungen offen, wie eigentlich die Namensauflösung funktioniert, solange der VPN Tunnel noch nicht steht. Vorab: es funktioniert, aber ich habe es noch nicht verstanden, da zum VPN Aufbau (genau) eine DNS-Auflösung (ohne Tunnel) benötigt wird. Auch müssen noch Tests bezüglich eines Kill-Switches realisiert werden, wenn der VPN Tunnel ungeplant zusammenbricht.

• Die Sense verwendet auf der WAN-Port Seite - Richtung Internet - eine separate weitere Fritzbox als "Ersatz-Modem" im Exposed-Host Modus, die dann mit dem Internet des ISPs verbunden ist. Diese Lösung war kostengünstig greifbar, Performance ist gut und die Box bleibt remote administrierbar.

Damit sollte auch die Frage geklärt sein, wer den DNS-Server stellt: Es ergibt sich hier die per DHCP aufgebaute Zuordnungskette:

• Endpunkte WLAN (PC, Noti, Smarti): DNS-Server WLAN-Fritzbox (im Home-Netz)
• WLAN-Fritzbox (WAN Seite): DNS-Server Pi-Hole
• Sense: DNS-Server Pi-Hole
• Pi-Hole auf dem Pi: verwendet den DNS-Server Unbound per LocalHost, Anfragen gehen über die Sense ins Internet.

Wesentlich, die entscheidende Einstellung war (u.a.):
Unter Firewall: NAT: Port Forward:
Interface: LAN, Protocol: TCP/UDP, Destination Invert, Destination : LAN address, Dest Port Range : DNS, Redirect target IP : 127.0.01 (verstehen ich allerdings NOCH nicht), Redirect target port: DNS.Unter Setup „System:Settings:General“:Pi-Hole als einzigen DNS Server mit Gateway „none“ eintragen.
DNS-Server Options: Kreuz machen bei „do not use the local DNS …”, Rest ungekreuzt. Damit verschwindet LocalHost als Namensauflöser (DNSMASQ oder Unbound).

Dnsmasq ist im Forward-Mode. Folgende Optionen sind gekreuzt:

• Enable Dnsmasq
• Enable DNSSEC
• Register DHCP leases
• Register DHCP static mappings
• Rest nicht aktiviert!

Nachdem das jetzt läuft, müssen noch die restlichen Firewall Regeln aktiviert bzw. geprüft werden.