Den DNS Verkehr dazu zwingen auf den PiHole umgeleitet zu werden, selbst wenn dieser im Browser oder ähnlichem z.b. auf cloudflare gestellt wurde
Warum wollen wir das?
Damit z.b. die Kids oder auch Mitarbeiter oder Ähnliche nicht einen frei wählbaren DNS-Server nutzen können.
Und wie geht das genau?
Dieses Tutorial ist nur für das USG-Pro4 oder für das USG-3P
Wir müssen die config.gateway.json bearbeiten.
Auf geht's:
Als erste legen wir ein VLAN für Unseren PiHole an. Hier soll als einziges Device der PiHole laufen!
Als Beispiel nutzen wir VLAN999 mit der IP 10.9.9.1
Der PiHole hört auf die 10.9.9.9
Wir nehmen in diesem Beispiel an, dass wir 5 weitere VLANs haben.
VLAN10, VLAN20, VLAN30, VLAN40, VLAN50
Ich gehe hier von aus, dass ihr bereits eine FW-Gruppe mit euren Admin Devices habt.
Wir erstellen als erstes eine FW-Gruppe mit der IP des PiHole und dem Port 53
Dann passen wir erstmal unsere Firewall LAN IN Regeln dementsprechend an:
Accept TCP & UDP from anywhere to (PiHole Gruppe) auf port 53
Damit stellen wir sicher, dass alle Devices die DNS Anfragen an den PiHole senden können
Accept All Protocols from (Gruppe Admin Geräte) to any port in (PiHole Gruppe) on any port
Damit stellen wir sicher, das wir mit unseren Admin Devices auf den PiHole kommen.
Block TCP & UDP Port 853 from Any (damit Blocken wir DoT von Clients)
Da wir DoT von Devices am PiHole vorbei unterbinden wollen, müssen wir diese FW Regel umsetzen.
Da wir DoH am PiHole vorbei auch unterbinden wollen müssen wir eine zusätzliche Add List in den PiHole einspielen - das Blocken von port 443 in der FW wäre fatal!:
https://raw.githubusercontent.…ohservers/master/list.txt
Jetzt müssen wir die config.gateway.json bearbeiten:
Wir benutzen WinSCP um uns auf unseren Cloudkey/Controller aufzuschalten.
Dann navigieren wir in folgenden Ordner: /usr/lib/unifi/data/sites/default/
Wir Speichern die config.gateway.json lokal auf unserem Rechner und bearbeiten Sie mit Notepad++
Wir fügen folgendes ein:
{
"service": {
"nat": {
"rule": {
"4001": {
"description": "Redirect DNS queries to pihole",
"destination": {
"port": "53"
},
"inbound-interface": "ethx",
"inside-address": {
"address": "10.9.9.9",
"port": "53"
},
"protocol": "tcp_udp",
"type": "destination"
},
"4002": {
"description": "Redirect DNS queries to pihole VLAN10",
"destination": {
"port": "53"
},
"inbound-interface": "ethx.10",
"inside-address": {
"address": "10.9.9.9",
"port": "53"
},
"protocol": "tcp_udp",
"type": "destination"
},
"4003": {
"description": "Redirect DNS queries to pihole VLAN20",
"destination": {
"port": "53"
},
"inbound-interface": "ethx.20",
"inside-address": {
"address": "10.9.9.9",
"port": "53"
},
"protocol": "tcp_udp",
"type": "destination"
},
"4004": {
"description": "Redirect DNS queries to pihole VLAN30",
"destination": {
"port": "53"
},
"inbound-interface": "ethx.30",
"inside-address": {
"address": "10.9.9.9",
"port": "53"
},
"protocol": "tcp_udp",
"type": "destination"
},
"4005": {
"description": "Redirect DNS queries to pihole VLAN40",
"destination": {
"port": "53"
},
"inbound-interface": "ethx.40",
"inside-address": {
"address": "10.9.9.9",
"port": "53"
},
"protocol": "tcp_udp",
"type": "destination"
},
"4006": {
"description": "Redirect DNS queries to pihole VLAN50",
"destination": {
"port": "53"
},
"inbound-interface": "ethx.50",
"inside-address": {
"address": "10.9.9.9",
"port": "53"
},
"protocol": "tcp_udp",
"type": "destination"
}
}
}
}
}Bei Adress "10.9.9.9" tragt ihr die IP des PiHole ein, bei Inbound Interface tragt ihr das von euch für LAN genutzte Interface am USG ein "ethx/ethx.xx"
USG Pro-4 : eth0 = LAN1 | eth1 = LAN2 | eth2 = WAN1 | eth3 = WAN2
USG 3P: eth0 = WAN1 | eth1 = LAN1 | eth2 = LAN2
Achtung, solltet ihr schon Einträge in der config.gateway.json haben, achtet auf die richtige Formatierung - am besten nutzt ihr einen JSON Validator
Wenn wir fertig sind übertragen wir die Datei wieder mit WinSCP auf den Cloudkey/Controller und provisionieren das USG.
Das war es dann schon, nun wird sämtlicher DNS Traffic, egal ob er am Device hardcoded ist an euren PiHole weitergeleitet.
Disclaimer: Alle Anleitungen/Tutorials sind nach bestem Wissen und Gewissen verfasst, gehen immer von den definierten Software/Firmware-Versionen aus und sind auf das englische GUI ausgelegt.
Es gibt keine Garantien auf Erfolg. Im Falle eines Misserfolges hilft aber sicherlich die Community hier immer weiter.
Keiner der Autoren oder der Betreiber des Forums ist für die aus der Nutzung resultierenden Probleme/Herausforderungen verantwortlich.
Jegliche hier beschriebenen Schritte erfolgen ausnahmslos in eigener Verantwortung des Durchführenden. Eltern haften für ihre Kinder.
Kommentare 11
Neu erstellte Kommentare unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.
Neu erstellte Kommentare unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.
BlackSpy
Cool, Danke.
Brauchen wir nur noch ein WIKI um verschieden config.gateway.json zusammen zu fügen.
Mir stellte sich immer die Frage: Wenn ich den Code für doppeltes NAT habe und mag jetzt zB deinen WIKI umsetzen wie füge ich die json zusammen.
defcon
kannst du mir den code schicken? Dann bastel ich dir etwas und beschriebe es so gut ich kann.
BlackSpy
Danke dir, dann kann ich auch sehen wie du es machst und daraus ableiten wie es funktioniert. Top 👍
defcon
@BlackSpy, da hast du ...
Und hier nochmal etwas erweitert mit Zwangstrennung um 04:30 Uhr morgens.
BlackSpy
WOW, absolut TOP.
Danke dir, werde die Tage das ganze mal zerlegen und mir anschauen wie du es zusammen gefügt hast, danach sollte ich mir selbst die config.gateway.json basten können, grade in Bezug auf VPN und IP Zuweisung kann man da einiges machen.
👍👍👍👍👍👍👍👍👍👍👍👍👍👍
defcon
Ich passe das hier nochmal an, damit die ganze Sache auch auf VLANs hört und man saubere Logs bekommt.