[Pi-Hole] Ervaringen & discussie

[Freee!!]

MdO82 schreef op woensdag 11 november 2020 @ 17:57:
Ik twijfel even of de volgende handeling voldoende is voor mij

Per vandaag ben ik overgegaan van Ziggo naar Delta Fiber.
Mijn Pihole had ik ingesteld als dhcp en de gateway was het modem van Ziggo (192.168.178.1)

Nu wil ik de ip-range (192.168.178.*) behouden zodat ik mijn devices niet opnieuw in hoef te stellen.

Is het voldoende om het Router (gateway) IP address om te zetten naar het modem van Delta of denk ik dan te simpel.

Volgens mij is dat het enige wat nodig is, maar twijfel even

Zolang het modem van Delta een adres in the 192.168.178.* range heeft/krijgt, gaat het goed. Als het denkt, dat het DHCP-server is en zelf een andere range gaat lopen uitdelen, krijg je problemen.

[MdO82]

Freee!! schreef op woensdag 11 november 2020 @ 18:16:
[...]

Zolang het modem van Delta een adres in the 192.168.178.* range heeft/krijgt, gaat het goed. Als het denkt, dat het DHCP-server is en zelf een andere range gaat lopen uitdelen, krijg je problemen.

Delta modem zit op een andere anders en dhcp zet ik daarvan uit.

[Freee!!]

MdO82 schreef op woensdag 11 november 2020 @ 18:24:
[...]
Delta modem zit op een andere anders

Daar zou je een probleem kunnen hebben, moet in jouw adres-reeks zitten om goed te werken.

en dhcp zet ik daarvan uit.

Uitstekend.

[Dennisdn]

Ik heb tijdens het werken altijd radio538 op staan via hun website. Blijkbaar hebben ze afgelopen dagen iets doorgevoerd waardoor hij nu geblocked wordt door de PiHole. De website zelf doet het nog wel, maar het playergedeelte is geblokkeerd. Hetzelfde gebeurd via Radio.nl.

Ik heb van alles proberen te whitelisten, zelfs een poging gedaan met álles te whitelisten wat werd geblokkeerd, maar geen resultaat. Ik weet zeker dat het aan de Pi ligt, want als ik tether via mobiel dan werkt het wél direct.

Hebben jullie enig idee wat ik kan proberen?

[geenwindows]

Dennisdn schreef op maandag 16 november 2020 @ 08:58:
Ik heb tijdens het werken altijd radio538 op staan via hun website. Blijkbaar hebben ze afgelopen dagen iets doorgevoerd waardoor hij nu geblocked wordt door de PiHole. De website zelf doet het nog wel, maar het playergedeelte is geblokkeerd. Hetzelfde gebeurd via Radio.nl.

Ik heb van alles proberen te whitelisten, zelfs een poging gedaan met álles te whitelisten wat werd geblokkeerd, maar geen resultaat. Ik weet zeker dat het aan de Pi ligt, want als ik tether via mobiel dan werkt het wél direct.

Hebben jullie enig idee wat ik kan proberen?

Pi-hole tijdelijk uitschakelen (de add block functies, dns blijft actief)

soms wil het ook wel eens helpen om een nieuwe venster te openen in incognito modus, of als je chrome gebruikt: nieuw venster met tijdelijk profiel.

[route99]

Ter info met Pi-Hole:
Hier werken radio538 en radio wel op alle browsers met hun geluid.
Reclame op hun sites lijkt ook geblokkeerd te worden.

Bijvoorbeeld speedtest.net zit vol reclame als ik bij anderen zit , die is hier helemaal schoon daarvan.
Volgens het Pi-Hole panel wordt meer dan 37% van het verkeer hier geblokkeerd.

[Dennisdn]

geenwindows schreef op maandag 16 november 2020 @ 14:15:
[...]


Pi-hole tijdelijk uitschakelen (de add block functies, dns blijft actief)

soms wil het ook wel eens helpen om een nieuwe venster te openen in incognito modus, of als je chrome gebruikt: nieuw venster met tijdelijk profiel.

Helaas, allemaal al geprobeerd.

[Dennisdn]

route99 schreef op maandag 16 november 2020 @ 18:20:
Ter info met Pi-Hole:
Hier werken radio538 en radio wel op alle browsers met hun geluid.
Reclame op hun sites lijkt ook geblokkeerd te worden.

Bijvoorbeeld speedtest.net zit vol reclame als ik bij anderen zit , die is hier helemaal schoon daarvan.
Volgens het Pi-Hole panel wordt meer dan 37% van het verkeer hier geblokkeerd.

Vreemd, ik krijg het met geen mogelijkheid meer aan de gang met de Pi ertussen. De site zelf doet het prima, ook de reclames worden geblokkeerd. Alleen de player werkt niet.

Het werkt wel als ik even via mobiele hotspot de player open en dan direct weer terug ga op WiFi-met-Pi. Dan blijft ie wel gewoon doorlopen. Dus het blokkeert alleen het aanvragen.

Ik weet uit ervaring wel dat 538 een hekel aan addblockers heeft. Bij DNSGuard blokkeren ze ook en wordt je doorverwezen naar de domeinpagina van Talpa.

[ Voor 25% gewijzigd door Dennisdn op 16-11-2020 18:45 ]

[route99]

Vreemd.... Ik gebruik alleen de standaard data van Pi-Hole ik heb geen extra data toegevoegd om meer te blokkeren.
Mss kun je daar nog iets mee?

[dss58]

route99 schreef op maandag 16 november 2020 @ 19:41:
Vreemd.... Ik gebruik alleen de standaard data van Pi-Hole ik heb geen extra data toegevoegd om meer te blokkeren.
Mss kun je daar nog iets mee?

op z'n minst moet je naar mijn idee https://dbl.oisd.nl als bloklijst toe voegen

[route99]

In het kader van zoek de verschillen: Dank je .... dat zat er wel een beetje in dat er iets meer zou kunnen zijn.
Het aftelpunt... "de bare Pi-Hole".. geeft iig dat probleem niet.
Er wordt bij mij al bijna 40% uitgefilterd... op welk niveau kom je te zitten las je de listen max toevoegt?

Het is wel zo: Ben erg in mijn sas dat er zoveel al uitgefilterd wordt.... mijn irritatie niveau van "storingen" is eigenlijk tot nu toe bijna nul...
Vraagje: Wat is de toegevoegde waarde van de extra lijst in de praktijk... ;lastig begrip, voor iedereen verschillend... maar even zo door de oogharen heen.
Ik vind nl nu dat er al errug veel uitgefilterd wordt....

[alesandro_46]

Voor de Pi-hole gebruikers die dat graag in Docker willen, in onderstaande video een uitleg hoe dat middels macvlan in Portainer te doen:

[Dennisdn]

Dennisdn schreef op maandag 16 november 2020 @ 08:58:
Ik heb tijdens het werken altijd radio538 op staan via hun website. Blijkbaar hebben ze afgelopen dagen iets doorgevoerd waardoor hij nu geblocked wordt door de PiHole. De website zelf doet het nog wel, maar het playergedeelte is geblokkeerd. Hetzelfde gebeurd via Radio.nl.

Hebben jullie enig idee wat ik kan proberen?

In vandaag werkt het spontaan weer zoals het zou moeten.
Toch dank voor het meedenken allen!

[LJ80]

ThinkPadd schreef op woensdag 16 januari 2019 @ 11:28:
iOS hier Ik heb ingesteld dat ik via OpenVPN ook langs de Pi-hole ga. Dus het is kwestie van even de VPN inschakelen en ik heb weer de voordelen van Pi-hole

Een wat ouder bericht van je gevonden. :-)

Los ik hiermee dus het probleem op dat mijn VPN nu niet via pihole gaat??


Ik heb NordVPN of ProtonVPN om uit te kiezen.
En ik gebruik de bijbehorende apps wat best handig is daar deze app's automatisch verbinden met VPN.

Maar dus het probleem dat er niet meer naar de DNS in mijn router gekeken wordt welke naar de raspberrypi met pihole verwijst....

[Videopac]

Dennisdn schreef op dinsdag 17 november 2020 @ 06:44:
[...]


In vandaag werkt het spontaan weer zoals het zou moeten.
Toch dank voor het meedenken allen!

Het kan ook zijn dat je een blokkeerlijst toegevoegd hebt waar een regel aan toegevoegd was die nu weer verwijderd is.

[nero355]

MdO82 schreef op woensdag 11 november 2020 @ 17:57:
Ik twijfel even of de volgende handeling voldoende is voor mij

Per vandaag ben ik overgegaan van Ziggo naar Delta Fiber.
Mijn Pihole had ik ingesteld als dhcp en de gateway was het modem van Ziggo (192.168.178.1)

Nu wil ik de ip-range (192.168.178.*) behouden zodat ik mijn devices niet opnieuw in hoef te stellen.

Is het voldoende om het Router (gateway) IP address om te zetten naar het modem van Delta of denk ik dan te simpel.

Volgens mij is dat het enige wat nodig is, maar twijfel even

De Genexis van Caiway/Delta kan je gewoon naar een ander subnet omzetten als je dat wilt dus ook het subnet van je oude Ziggo modem/router

Standaard is 192.168.1.x/24 geloof ik en die van mij draait nu op 172.16.1.x/24

Dennisdn schreef op maandag 16 november 2020 @ 08:58:
Ik heb tijdens het werken altijd radio538 op staan via hun website. Blijkbaar hebben ze afgelopen dagen iets doorgevoerd waardoor hij nu geblocked wordt door de PiHole. De website zelf doet het nog wel, maar het playergedeelte is geblokkeerd. Hetzelfde gebeurd via Radio.nl.

Ik heb van alles proberen te whitelisten, zelfs een poging gedaan met álles te whitelisten wat werd geblokkeerd, maar geen resultaat. Ik weet zeker dat het aan de Pi ligt, want als ik tether via mobiel dan werkt het wél direct.

Hebben jullie enig idee wat ik kan proberen?

Open gewoon de directe stream!

Die kan je hier opzoeken :
- http://fmstream.org/index.php?s=radio538
- https://hendrikjansen.nl/henk/streaming.html

En als je toch al met een Pi bezig bent dan kan je ook zoiets opzetten : https://www.pimusicbox.com/
Mopidy of MPD i.c.m. een WebGUI of een applicatie die ze kan aansturen en gaan met die banaan!

[Dennisdn]

nero355 schreef op dinsdag 17 november 2020 @ 21:56:

Open gewoon de directe stream!

Die kan je hier opzoeken :
- http://fmstream.org/index.php?s=radio538
- https://hendrikjansen.nl/henk/streaming.html

En als je toch al met een Pi bezig bent dan kan je ook zoiets opzetten : https://www.pimusicbox.com/
Mopidy of MPD i.c.m. een WebGUI of een applicatie die ze kan aansturen en gaan met die banaan!

Nou... ik vind het juist wel leuk om het beeld van de stream erbij te hebben. Beetje in studio meekijken en alle andere afleiding die erop voorbij komt. Op 3schermenwerkplek staat die gewoon uiterst rechts in beeld als ik dat scherm niet gebruik. Eigenlijk was dat ook de reden dat ik weer een Pi-hole opgezet had, nadat zij de DNS van Adguard hadden geblokkeerd.

Maar vandaag werkte het dus weer als vanouds. Aan de pi niks veranderd en ik draai de Stock-versie zonder extra toegevoegde blacklist. Het gebeurde op alle computers in alle verschillende browsers op het netwerk, die het bij tether op 4G wel gewoon deden. Het zou de router geweest kunnen zijn dan, maar geen idee hoe.

[ Voor 5% gewijzigd door Dennisdn op 17-11-2020 22:17 ]

[nero355]

Dennisdn schreef op dinsdag 17 november 2020 @ 22:13:
Nou... ik vind het juist wel leuk om het beeld van de stream erbij te hebben. Beetje in studio meekijken en alle andere afleiding die erop voorbij komt. Op 3schermenwerkplek staat die gewoon uiterst rechts in beeld als ik dat scherm niet gebruik.

Ik draai dus Pi MusciBox al een jaartje of zo op een Pi 3B en zolang de stream een beetje meewerkt is het echt ideaal i.c.m. een smartphone om de WebGUI te bedienen!

Maar als je graag ook beeld erbij wilt hebben dan wordt het inderdaad een ander verhaal...

Persoonlijk zie of hoor ik het liefst helemaal geen Radio DJ's

[Kopernikus.1979]

Beste,

Ik heb in iedere VLAN een alias IP draaien op mijn Pi-Hole DNS server.
Dus concreet voorbeeld, vlan10 10.10.10.0/24 heeft 10.10.10.5 als Pihole / vlan20 10.10.
20.0/24 heeft 10.10.20.5 als Pihole. De Pi-Hole zelf draait in mijn server VLAN untagged en dan tagged alle aliassen.
Dit werkt prima en gezien de request komen binnen de eigen VLAN moet ik geen firewall regel hebben die die VLANS toelaat de PiHole DNS te benaderen. Als laatste lijn in mijn firewall heb ik een block RFC1918 to RFC1818.
Daarnaast heb ik in mijn gateway.config.json DNAT rules die ervoor zorgen dat aparaten met hardcoded dns doorgestuurd worden naar mijn Pi-Hole, ik heb zo'n regel voor elke VLAN.
Maar nu komt het probleem, als mijn block RFC1918 to RFC1918 regel aanstaat dan werkt de dns forwared niet, nochtans gebeurt de forwared binnen dezelfde VLAN dus zou de Pi-Hole moeten bereikbaar zijn.
Nu heb ik voorlopig een regel gemaakt allow RFC1918 to PiHole DNS (IP group met alle Pihole alias IP's)

Als ik bv mij verbind met IoT vlan kan ik een connectie maken met de Pi-Hole DNS op poort 53
Dus: 10.10.20.20 --> 10.10.20.5:53 werkt prima

Echter als dit gebeurt door een DNAT regel die het verkeerd doorstuurt van een device die op 10.10.20.x zit naar 10.10.20.5:53 dan werkt dit niet tenzij ik expliciet in de firewall de IoT VLAN toegang geef de PiHole.

Zou het kunnen dat de DNAT mijn Pi-Hole ziet in zijn untaged vlan? (want alle andere adressen zijn aliassen hiervan)

[ed1703]

Kopernikus.1979 schreef op woensdag 18 november 2020 @ 11:03:

Daarnaast heb ik in mijn gateway.config.json DNAT rules die ervoor zorgen dat aparaten met hardcoded dns doorgestuurd worden naar mijn Pi-Hole, ik heb zo'n regel voor elke VLAN.

Dit hit je iptables firewall.

Als laatste lijn in mijn firewall heb ik een block RFC1918 to RFC1818.

Dit dropt vervolgens je DNAT--regel, want je hebt geen allow-regel gemaakt.

Zie ook mijn antwoord in het UI-draadje:

ed1703 in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 4"

[Remco Tr]

Ik heb sinds een paar dagen heel veel lb._dns-sd._udp request.

Deze komen vanaf mijn iphone met iOS14. Iemand een idee wat dit is. Bijna om de minuut.

[MdO82]

Remco Tr schreef op woensdag 18 november 2020 @ 12:56:
Ik heb sinds een paar dagen heel veel lb._dns-sd._udp request.

Deze komen vanaf mijn iphone met iOS14. Iemand een idee wat dit is. Bijna om de minuut.

Als ik zoek op lb._dns-sd._udp request kom ik dit draadje tegen.

https://discourse.pi-hole...192-in-addr-arpa/18241/13

Heb je daar iets aan ?

[Remco Tr]

MdO82 schreef op woensdag 18 november 2020 @ 15:49:
[...]


Als ik zoek op lb._dns-sd._udp request kom ik dit draadje tegen.

https://discourse.pi-hole...192-in-addr-arpa/18241/13

Heb je daar iets aan ?

Dank je, kwam dat ook tegen. Alleen staat conditional forwarding uit en komt alleen van mijn iPhone. Misschien dat het door een app komt maar geen idee welke. Dik 2000 hits per dag

[heeten12]

Ik heb last van hetzelfde euvel. Sinds ik de update naar iOS 14 heb, gebeurt dit.

Zie online wel vaker meldingen maar helaas nog geen oplossingen. Conditional forwarding staat hier ook uit. Hoor het graag als je een oplossing vindt Remco

[Remco Tr]

heeten12 schreef op woensdag 18 november 2020 @ 18:27:
Ik heb last van hetzelfde euvel. Sinds ik de update naar iOS 14 heb, gebeurt dit.

Zie online wel vaker meldingen maar helaas nog geen oplossingen. Conditional forwarding staat hier ook uit. Hoor het graag als je een oplossing vindt Remco

Moet bijna wel iOS 14 zijn. Nooit last van gehad. Draai nu beta 14.3 b2. Maar het blijft. Wel is het na reboot even weg.

[Kopernikus.1979]

ed1703 schreef op woensdag 18 november 2020 @ 12:22:
[...]

Dit hit je iptables firewall.


[...]

Dit dropt vervolgens je DNAT--regel, want je hebt geen allow-regel gemaakt.

Zie ook mijn antwoord in het UI-draadje:

ed1703 in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 4"

Betreffende de regels wat te verfijnen...

In mijn config.gateway.json staan er 3 DNAT regels voor poort 53 te "forceren" naar mijn Pi-Hole's.

Regel 1 is voor mijn Trusted VLAN
Hier hoef ik niks voor te doen gezien Trusted VLAN toegang heeft tot Server VLAN (waar de PiHole's wonen :-)

Regel 2 is voor mijn IoT VLAN
Hiervoor zou ik een firewall regel maken die TCP-UDP verkeer komende van mijn IoT VLAN naar mijn Pi-Hole met alias IP in het IoT VLAN toelaat op poort 53.

Regel 3 is voor mijn Guest VLAN
Hiervoor zou ik hetzelfde doen, maar moet de regel hier in de LAN-IN of GUEST-IN?

Ook zijn er naast die 3 DNAT regels, 3 MASQUERADE regels, moet hiervoor ook nog iets gebeuren?

[heeten12]

Remco Tr schreef op woensdag 18 november 2020 @ 18:46:
[...]


Moet bijna wel iOS 14 zijn. Nooit last van gehad. Draai nu beta 14.3 b2. Maar het blijft. Wel is het na reboot even weg.

Bij mij is het opgelost, alleen heb ik twee zaken tegelijk gedaan.
1. Updaten naar iOS 14.2
2. Heb een statisch IP met static entry in de ARP table te geven in mijn OpnSense configuratie. Dit heb ik ook voor de rest van mijn devices maar had ik nog niet voor mijn werktelefoon gedaan

Gezien Remco al een versie verder zit, verwacht ik dat punt 2 ergens invloed heeft gehad

Edit: probleem leek lange tijd weg maar steekt toch weer de kop op. De zoektocht gaat voort!

[ Voor 7% gewijzigd door heeten12 op 19-11-2020 12:32 ]

[Yoshimi]

heeten12 schreef op donderdag 19 november 2020 @ 08:13:
[...]


Bij mij is het opgelost, alleen heb ik twee zaken tegelijk gedaan.
1. Updaten naar iOS 14.2
2. Heb een statisch IP met static entry in de ARP table te geven in mijn OpnSense configuratie. Dit heb ik ook voor de rest van mijn devices maar had ik nog niet voor mijn werktelefoon gedaan

Gezien Remco al een versie verder zit, verwacht ik dat punt 2 ergens invloed heeft gehad

Edit: probleem leek lange tijd weg maar steekt toch weer de kop op. De zoektocht gaat voort!

Ik heb bij ons thuis hetzelfde geconstateerd. Nog geen oplossing gevonden, maar wel een workaround voor nu:

Wanneer je /etc/pihole/pihole-FTL.conf edit, dan zie je daar nu waarschijnlijk 1 regel staan (mits eerder aangepast). Hier voeg je aan toe: ANALYZE_ONLY_A_AND_AAAA=true
Hierdoor analyseert FTL enkel A en AAAA records, maar niet meer de DNS-SD pointer records.

Hierna start je de DNS resolver opnieuw op en moeten ze niet meer verschijnen.
Ondertussen zoek en lees ik mee naar een definitieve oplossing

[heeten12]

Thanks! Heb het nu 'opgelost' door de DNS SD verzoeken toe te voegen aan de negeer lijst voor de stats. Dat kan via de gui in de instellingen bij web API.

Misschien dat ik het later nog via jouw tip compleet aanpas in de config

[MdO82]

Ik heb van de week mijn interne ip-range veranderd van 192.168.178.* naar 192.168.1.*
Achteraf niet nodig geweest, maar goed dat is vaak achteraf

Nu kan ik mijn rasp waar Pi-hole op draait benaderen via een 192.168.1.* adres.
Maar als ik op mijn dashboard kijk binnen pi-hole ziet hij nog het ip-adres in de range 192.168.178.*

Dit adres is overigens niet te pingen en de logging geven aan dat alle devices gebruik maken van pi-hole op de 192.168.1.* range.

Mijn rasp hangt aan ethernet en niet via WLAN.

Iemand een idee waar dit vandaan komt ?
Ik heb de boel al eens geflushed en reboot, maar kan er niet achter komen waar dit in zit.

[jpgview]

MdO82 schreef op zondag 22 november 2020 @ 17:55:
Nu kan ik mijn rasp waar Pi-hole op draait benaderen via een 192.168.1.* adres.
Maar als ik op mijn dashboard kijk binnen pi-hole ziet hij nog het ip-adres in de range 192.168.178.*

Hopelijk heb je "pihole -r" gebruikt om je pi-hole te herconfigureren met het nieuwe IP address, heb je dat nog niet gedaan, doe het dan alsnog, om het IP address overal te wijzigen waar dat nodig is.

De database /etc/pihole/pihole-FTL.db houd bij default de historiek van de laatste 365 dagen bij, dat is wat in het dashboard getoond word.

Twee mogelijkheden:
1. als je niet geinteresserd bent in de oude historiek, verwijder dan gewoon die database, e.g:
- sudo service pihole-FTL stop
- sudo rm /etc/pihole/pihole-FTL.db
- sudo service pihole-FTL start
de database word opnieuw aangemaakt zodra pihole-FTL start, alle oude info is dus weg, e.g. fresh start.
2. beperk de historische data
- maak een bestand (of voeg de setting toe) /etc/pihole/pihole-FTL.conf
- voeg de setting MAXDBDAYS=8 toe
- sudo service pihole-FTL stop
- sudo service pihole-FTL start
alle info, ouder dan 8 dagen zal nu verwijderd worden (als je pi al een tijdje draait kan dit een tijd duren). Na acht dagen met het nieuwe IP address verdwijnen de oude IP addressen dus.
Je moet zelf kiezen wat een goed setting voor je is (1 .. 365), zelf gebruik ik 8 dagen, en heb nog nooit de behoefte gehad om DNS queries op te sporen die ouder zijn.

Vergeet niet dat je na de IP wijziging ook de clients, die je gedefineerd hebt in group management / clients moet wijzigen, anders doet groupmanagement niets…

[jimmy87]

Ik heb sinds kort een pi-hole draaien, werkt aardig goed, ik heb nu alleen het probleem dat de buienradar app het niet meer doet. Hij start even en sluit dan weer af.

Dacht eerst dat het aan de app lag maar als ik pi-hole een paar minuten disable opent deze wel gewoon.
Ik zie in de query log geen redenen dat het niet zou werken (geen blocked ads op het moment dat ik de app open.)

Iemand dit al eens eerder gezien?

[hansgrave]

jimmy87 schreef op dinsdag 24 november 2020 @ 09:25:
Ik heb sinds kort een pi-hole draaien, werkt aardig goed, ik heb nu alleen het probleem dat de buienradar app het niet meer doet. Hij start even en sluit dan weer af.

Dacht eerst dat het aan de app lag maar als ik pi-hole een paar minuten disable opent deze wel gewoon.
Ik zie in de query log geen redenen dat het niet zou werken (geen blocked ads op het moment dat ik de app open.)

Iemand dit al eens eerder gezien?

Op mijn Android telefoon heb ik sinds 1 a 2 weken dat buienradar opstart met een vertraging van 10-15 seconden.

[Webgnome]

Ligt het misschien aan dat jullie beide een aantal google diensten blokkeren waardoor controleren op nieuwe versie van de app fout gaat en daardoor een crash komt?

[jimmy87]

Hmm mogelijk maar dan zou ik toch een block melding moeten zien in de query log?

[Webgnome]

dan zou je inderdaad een melding moeten zien inderdaad vanaf het ip van het device

[Raven]

Buienradar doet hier prima, al heb ik wel af en toe dat het laden van de gegevens (bijv. neerslag van komende 3 uur) langer duurt dan gebruikelijk, maar geen crashes of trage starts met PiHole ertussen.

[ Voor 5% gewijzigd door Raven op 24-11-2020 11:27 ]

[sparow]

jimmy87 schreef op dinsdag 24 november 2020 @ 09:25:
Ik heb sinds kort een pi-hole draaien, werkt aardig goed, ik heb nu alleen het probleem dat de buienradar app het niet meer doet. Hij start even en sluit dan weer af.

Dacht eerst dat het aan de app lag maar als ik pi-hole een paar minuten disable opent deze wel gewoon.
Ik zie in de query log geen redenen dat het niet zou werken (geen blocked ads op het moment dat ik de app open.)

Iemand dit al eens eerder gezien?

Ik heb al langere tijd Pi-hole draaien en sinds kort (volgens mij sinds iPhone update) heb ik dat de Buienradar app niet meer opent. Ik denk dus niet dat het met Pi-Hole te maken heeft, maar zal het even in de gaten houden.

[AudioHome]

Ik heb met buienradar ook dat hij heel traag opent, maar dat ligt niet aan Pi-Hole.
Op een ander wifi netwerk zonder Pi-hole, en ook met 4G ipv wifi zie ik hetzelfde gedrag.

[jimmy87]

Hier is het consequent opgelost als ik pi-hole op disable zet dus is echt 100% iets in pi-hole. Denk dat ik ook eens ga testen met adguard.

[Freee!!]

Bij mij gaat buienradar vlot genoeg.

[nero355]

jimmy87 schreef op dinsdag 24 november 2020 @ 09:25:
Ik heb sinds kort een pi-hole draaien, werkt aardig goed, ik heb nu alleen het probleem dat de buienradar app het niet meer doet. Hij start even en sluit dan weer af.

Ik word altijd verdrietig als ik zie dat iemand met een app zit te klooien, terwijl je gewoon een browser hebt en makkelijk https://www.buienradar.nl/ kan bookmarken en daarna heel snel kan openen!

[jimmy87]

Tja, ik gebruik hem ook niet, moeder de vrouw wel, dus met een daar is ook een website voor kom ik niet weg denk ik

[nero355]

jimmy87 schreef op dinsdag 24 november 2020 @ 23:23:
Tja, ik gebruik hem ook niet, moeder de vrouw wel, dus met een daar is ook een website voor kom ik niet weg denk ik

Kwestie van goede manieren aanleren!

[Videopac]

nero355 schreef op dinsdag 24 november 2020 @ 23:22:
[...]

Ik word altijd verdrietig als ik zie dat iemand met een app zit te klooien, terwijl je gewoon een browser hebt en makkelijk https://www.buienradar.nl/ kan bookmarken en daarna heel snel kan openen!

Voor buienradar kan dan. Het probleem is dat je bij steeds meer winkels alleen korting krijgt als je de dataverzamelende app installeert.

[nero355]

Videopac schreef op woensdag 25 november 2020 @ 20:11:
Voor buienradar kan dan. Het probleem is dat je bij steeds meer winkels alleen korting krijgt als je de dstsverzamelende app installeert.

Daar hadden we 20+ jaar geleden een mooi les voor op school één keer per week en toen ging dat nog over tracking en data verzamelen via dingen als de AH klantenkaart en soortgelijken.

Nu is het nog erger en leest zo'n app gewoon je hele telefoon uit!

#DoeEensNietMeeAanVrijwilligeSpyware

[sparow]

jimmy87 schreef op dinsdag 24 november 2020 @ 23:06:
Hier is het consequent opgelost als ik pi-hole op disable zet dus is echt 100% iets in pi-hole. Denk dat ik ook eens ga testen met adguard.

Bij mij was het opgelost doorde app buiten wifi netwerk te openen. Toen starte hij gewoon op en sindsdien ook binnen het wifi netwerk. Geen idee..

[jpgview]

OPGEPAST !!!

Pi-hole 5.2 is zonet gereleased (Pi-hole Core v5.2 – Pi-hole Web v5.2 – Pihole-FTL v5.3); maar Debain/Raspbian stretch is niet langer supported. FOUTJE, lees hier.

Debain/Raspbian stretch users moeten wachten met upgraden tot dit is rechtgezet!!!

edit
blijkbaar snel opgelost, Pi-hole FTL v5.3.1, lees hier en hier.
/edit

[ Voor 26% gewijzigd door jpgview op 28-11-2020 22:19 ]

[Raven]

"Allow defining clients by their MAC address "
Daar zat ik al een tijdje op te wachten

[tdn135]

Ze moeten alleen hun docker images van hun officiële repo nog updaten naar de nieuwe versie. Die komen vast komende dagen beschikbaar.

[ Voor 8% gewijzigd door tdn135 op 29-11-2020 10:35 ]

[Dracula]

Kopernikus.1979 schreef op zondag 1 november 2020 @ 09:35:
[...]
ik zelf gebruik de "ticked" lijsten van de "Firebog" de whitelist van "Anudeep" en de regex blacklist van "mmotti"' die dan automatisch geüpdatet worden via deze (https://github.com/jacklul/pihole-updatelists).

Vraagje, ik heb de updatelist pihole nu ook draaien op mijn pi alleen snap ik even niet hoe het zit het schedule.

By default, the script runs at random time (between 03:00 and 04:00) on Saturday, to change it you'll have to override timer unit file:

sudo systemctl edit pihole-updatelists.timer

[Timer]
RandomizedDelaySec=5m
OnCalendar=
OnCalendar=Sat *-*-* 00:00:00

Echter als ik sudo systemctl edit pihole-updatelists.timer run krijg ik een foutmelding dat pihole-updatelists.timer niet gevonden kan worden.

Ik doe vast ergens iets fout aleen ik snap even niet wat.

Ow heb het in een docker container draaien....

[Freee!!]

tdn135 schreef op zondag 29 november 2020 @ 10:34:
Ze moeten alleen hun docker images van hun officiële repo nog updaten naar de nieuwe versie. Die komen vast komende dagen beschikbaar.

Die is nu beschikbaar, kreeg net een e-mail van de Watchtower-container, dat Pi-Hole bijgewerkt is op mijn RPi3B+, op mijn RPi4B zal dan ook wel zo komen.

[Wachten...]

Is iemand hier toevallig bekend met deze YouTube blocklijst ?

Ik weet dat het blocken van YouTube ads niet makkelijk is en er diverse mensen scripts voor hebben draaien. Echter is het importen van een lijst natuurlijk wel heel makkelijk en is deze lijst redelijk recent.

Ik wordt ondertussen flink gek op mijn Nvidia shield en YouTube ads!

[Webgnome]

@Wachten... Je weet dat het blokkeren van adds die je voor een video krijgt niet meer te doen is via Pihole/Addguard etc? De adds zitten in de videostream of worden via dezelfde server als de videostream gestuurd waardoor je een brakke Youtube ervaring hebt. Je kunt beter kijken naar alternatieven voor youtube adds te blokkeren.

[Wachten...]

Webgnome schreef op maandag 30 november 2020 @ 11:10:
@Wachten... Je weet dat het blokkeren van adds die je voor een video krijgt niet meer te doen is via Pihole/Addguard etc? De adds zitten in de videostream of worden via dezelfde server als de videostream gestuurd waardoor je een brakke Youtube ervaring hebt. Je kunt beter kijken naar alternatieven voor youtube adds te blokkeren.

Dit had ik al vernomen, vandaar mijn vraag aangezien deze titel is geüpdate naar september en dus zou pretenderen dat dit werkt.

Maar bedankt voor de heads-up. Ik gebruik Newpipe op mijn telefoon, maar vindt het echt niet lekker werken op de shield. Zeker mijn vriendin kan er niet lekker mee overweg!

[Quad]

@Wachten... voor YouTube op Android gebruik ik YouTube Vanced, werkt prima.

[ Voor 7% gewijzigd door Quad op 30-11-2020 11:35 ]

[Webgnome]

offtopic:
Je kunt natuurlijk een abonnementje afsluiten

[Videopac]

Webgnome schreef op maandag 30 november 2020 @ 11:38:

offtopic:
Je kunt natuurlijk een abonnementje afsluiten

Ik ben zeker wel bereid te betalen voor inhoud, maar niet als de makers vrijwel niets krijgen en het verdienmodel het verzamelen van en handelen in persoonlijke data is.

In mijn ideale wereld zou daar een gedistribueerde open-source oplossing voor zijn, maar dat is weer een hele andere discussie.

[prutser001]

Is er ergens een overzicht met 'blocklists' ?

Heb nu zelf deze in gebruik :
https://raw.githubusercon...nBlack/hosts/master/hosts
https://mirror1.malwaredomains.com/files/justdomains
https://s3.amazonaws.com/...ct.me/simple_tracking.txt
https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt
https://dbl.oisd.nl/
https://www.sunshine.it/blacklist.txt

En deze : https://discourse.pi-hole...ve-dns-servers-2019/13620

Zit nu op 1.188.670 domains blocked.

Draai nu laatste PiHole + OpenVPN en werkt heerlijk, gewoon VPN en adds geblokkeerd... echt een genot!

[GieltjE]

https://firebog.net/

Heb nog als extra:
https://hblock.molinero.dev/hosts_domains.txt
https://www.stopforumspam...s/toxic_domains_whole.txt
https://gitlab.com/ZeroDo...Lists/raw/master/list.txt
https://blocklistproject.github.io/Lists/ransomware.txt
https://blocklistproject.github.io/Lists/tracking.txt
https://blocklistproject.github.io/Lists/scam.txt
https://blocklistproject.github.io/Lists/phishing.txt
https://blocklistproject.github.io/Lists/malware.txt
https://blocklistproject.github.io/Lists/fraud.txt
https://blocklistproject.github.io/Lists/ads.txt
https://blocklistproject.github.io/Lists/crypto.txt
https://codeberg.org/spoo...anch/master/blocklist.txt

Wel altijd goed opletten dat de lijsten die je gebruikt af en toe geupdate worden

[ Voor 5% gewijzigd door GieltjE op 30-11-2020 14:50 ]

[prutser001]

GieltjE schreef op maandag 30 november 2020 @ 14:46:
https://firebog.net/

Heb nog als extra:
https://hblock.molinero.dev/hosts_domains.txt
https://www.stopforumspam...s/toxic_domains_whole.txt
https://gitlab.com/ZeroDo...Lists/raw/master/list.txt
https://blocklistproject.github.io/Lists/ransomware.txt
https://blocklistproject.github.io/Lists/tracking.txt
https://blocklistproject.github.io/Lists/scam.txt
https://blocklistproject.github.io/Lists/phishing.txt
https://blocklistproject.github.io/Lists/malware.txt
https://blocklistproject.github.io/Lists/fraud.txt
https://blocklistproject.github.io/Lists/ads.txt
https://blocklistproject.github.io/Lists/crypto.txt
https://codeberg.org/spoo...anch/master/blocklist.txt

Wel altijd goed opletten dat de lijsten die je gebruikt af en toe geupdate worden

Danku, misschien handig dat er zo'n overzichtje in de startpost komt?

[GieltjE]

Dat is nog best lastig denk ik, zelfs firebog heeft een aantal lijsten die niet meer geupdate worden en sommigen zijn weer combinaties van anderen.

Nog een paar mooie:
https://raw.githubusercon...nBlack/hosts/master/hosts
https://raw.githubusercon...s/fakenews-gambling/hosts
https://phishing.army/dow...my_blocklist_extended.txt
https://winhelp2002.mvps.org/hosts.txt
https://adaway.org/hosts.txt
https://codeberg.org/spoo...anch/master/blocklist.txt
https://urlhaus.abuse.ch/downloads/hostfile/

Zit zelf zonder veel problemen (10 whitelist entries om office/ms tevreden te houden) op de 2,2m blocked items. Heb dan ook wel iets krachtigere hardware dan een rpi

[ Voor 11% gewijzigd door GieltjE op 30-11-2020 15:21 ]

[Videopac]

GieltjE schreef op maandag 30 november 2020 @ 15:20:
Dat is nog best lastig denk ik, zelfs firebog heeft een aantal lijsten die niet meer geupdate worden en sommigen zijn weer combinaties van anderen.

Nog een paar mooie:
https://raw.githubusercon...nBlack/hosts/master/hosts
https://raw.githubusercon...s/fakenews-gambling/hosts
https://phishing.army/dow...my_blocklist_extended.txt
https://winhelp2002.mvps.org/hosts.txt
https://adaway.org/hosts.txt
https://codeberg.org/spoo...anch/master/blocklist.txt
https://urlhaus.abuse.ch/downloads/hostfile/

Zit zelf zonder veel problemen (10 whitelist entries om office/ms tevreden te houden) op de 2,2m blockeditems. Heb dan ook wel iets krachtigere hardware dan een rpi

Pi-Hole wordt toch niet trager als je blokkeerlijst erg lang is?

[dss58]

Videopac schreef op maandag 30 november 2020 @ 18:51:
[...]

Pi-Hole wordt toch niet trager als blokkeerlijst erg lang is?

Ik heb wel is 8 miljoen domais geblokt gewoon voor de leuk omdat het kan, maar is niet merkbaar.

[GieltjE]

Inderdaad het is veel sneller geworden, en misschien heb ik altijd net iets teveel gedraaid op de rpi'tjes

[Church of Noise]

Er is een zeer handige script die berekent in welke mate lists effectief zijn: https://github.com/yubiuser/pihole_adlist_tool
Aanradertje om eens te draaien, en te zien welke lists nu echt bijdragen.

Zoals je wel kan vermoeden, ben ik geen fan van de "OMG 500 million domains on blocklist" approach. Less is more. Daarnaast ben ik een grote voorstander van transparantie, en ik huiver dan ook van blocklists die bestaande blocklists verzamelen en er nadien een en ander uithalen. Vandaar dat ik zelf de basis-blocklists kies en enkel waar ik dat wil, whitelist.
Dat zou ik ook eenieder aanraden: begin met de basis en kijk dan, bvb in je query log, of er zaken zijn die moeten geblokt worden. Na wat zoeken vind je dan misschien lists die daarop focussen.

Ter info, op een Pi Zero kan het aantal domains op de blocklists wel degelijk impact hebben op de performantie - ik spreek uit ervaring.

[ Voor 0% gewijzigd door Church of Noise op 07-02-2021 09:19 . Reden: schrijffoutje ]

[Webgnome]

@Church of Noise wat betreft pi zero. Is het daar dan niet het probleem dat het aantal requests naar geblokkeerde domeinen te hoog ligt en niet zo zeer de omvang van je blocklist? Ik draai hier namelijk pihole al jaar en dag op een zero en heb eigenlijk nooit performance issues gehad?

[Church of Noise]

@Webgnome Ik draai nog steeds een Pi Zero met Pi-Hole en unbound, met ongeveer een half miljoen blocked domains en dat loopt erg vlot. Ik vermoed dat het een gevolg was van de beperkte hoeveelheid RAM (ik had toen ik denk 5 miljoen domains staan, toen ik aan het testen was wat nu best werkte). Dat was ook met een oudere versie van Pi-Hole, die een stuk minder efficiënt omging met geheugen (gravity db).
Hoeveel blocked domains heb jij?

[MdO82]

Het is ongetwijfeld heel simpel, maar ik kan het niet meer vinden
Ik heb tijdens mijn installatie van Pihole de port veranderd van port 80 naar 89

Draait allemaal prima.
Echter tot de update
Default port is weer op 80 gezet.

En ik weet toch echt even niet meer waar ik dat gedaan heb

Ik gebruik geen lighttpd maar apache op mijn rasp.
Iemand een tip of hint

[nero355]

Church of Noise schreef op dinsdag 1 december 2020 @ 11:31:
Er is een zeer handige script die berekent in welke mate lists effectief zijn: https://github.com/yubiuser/pihole_adlist_tool
Aanradertje om eens te draaien, en te zien welke lists nu echt bijdragen.

Volgens mij heeft @jpgview zoiets al eerder gepost, maar goed... "the more the merry" en zo

Zoals je wel kan vermoeden, ben ik geen fan van de "OMG 500 million domains on blocklist" approach. Less is more. Daarnaast ben ik een grote voorstander van transparantie, en ik huiver dan ook van blocklists die bestaande blocklists verzamelen en er nadien een en ander uithalen. Vandaar dat ik zelf de basis-blocklists kies en enkel waar ik dat wil, whitelist.
Dat zou ik ook eenieder aanraden: begin met de basis en kijk den, bvb in je query log, of er zaken zijn die moeten geblokt worden. Na wat zoeken vind je dan misschien lists die daarop focussen.

Helemaal mee eens!

MdO82 schreef op dinsdag 1 december 2020 @ 14:28:
Het is ongetwijfeld heel simpel, maar ik kan het niet meer vinden

Gevalletje "Ik heb de oplossing ergens gezien, maar kan hem niet meer terugvinden..." toevallig ?

Ik heb daar ook steeds vaker last van!

Ik heb tijdens mijn installatie van Pihole de port veranderd van port 80 naar 89

Draait allemaal prima.
Echter tot de update
Default port is weer op 80 gezet.

En ik weet toch echt even niet meer waar ik dat gedaan heb

Documenteren en je config files backuppen!

Ik gebruik geen lighttpd maar apache op mijn rasp.
Iemand een tip of hint

In welke opzet :
- Puur Apache die alles doet ?
- Apache die richting LigHTTPd als Reverse Proxy functioneert ?

In principe kan je beiden configureren zoals je wilt, maar dan moet ik wel weten wat je hebt gedaan!

Misschien dat het volgende wat bij je triggert :
- Pjotrofsky in "[Pi-Hole] Ervaringen & discussie"
- djoelzz in "[Pi-Hole] Ervaringen & discussie"
- nero355 in "[Pi-Hole] Ervaringen & discussie"

[MarcoC]

Ik heb mijn Pi-hole bijgewerkt naar v5.2, alleen is de GUI nu erg sloom via Docker. Heb een nieuwe container gemaakt met nieuwe config en ook die is direct sloom. v5.1.2 gaat als de brandweer. Erg vreemd. Ik wacht nog even tot dit gefixt is.

[dss58]

MarcoC schreef op woensdag 2 december 2020 @ 00:24:
Ik heb mijn Pi-hole bijgewerkt naar v5.2, alleen is de GUI nu erg sloom via Docker. Heb een nieuwe container gemaakt met nieuwe config en ook die is direct sloom. v5.1.2 gaat als de brandweer. Erg vreemd. Ik wacht nog even tot dit gefixt is.

plemp je vraag op https://discourse.pi-hole.net/ zou ik zeggen

[GieltjE]

Church of Noise schreef op dinsdag 1 december 2020 @ 11:31:
Er is een zeer handige script die berekent in welke mate lists effectief zijn: https://github.com/yubiuser/pihole_adlist_tool
Aanradertje om eens te draaien, en te zien welke lists nu echt bijdragen.

Zoals je wel kan vermoeden, ben ik geen fan van de "OMG 500 million domains on blocklist" approach. Less is more. Daarnaast ben ik een grote voorstander van transparantie, en ik huiver dan ook van blocklists die bestaande blocklists verzamelen en er nadien een en ander uithalen. Vandaar dat ik zelf de basis-blocklists kies en enkel waar ik dat wil, whitelist.
Dat zou ik ook eenieder aanraden: begin met de basis en kijk den, bvb in je query log, of er zaken zijn die moeten geblokt worden. Na wat zoeken vind je dan misschien lists die daarop focussen.

Ter info, op een Pi Zero kan het aantal domains op de blocklists wel degelijk impact hebben op de performantie - ik spreek uit ervaring.

Een aantal van mijn extra lijsten worden inderdaad niet geraakt, dat zijn dan ook de fraud/scam/mining lists.
Dat deze niet geraakt zijn is meer een goed teken, ga ze ook niet verwijderen.
Wel absurd dat er eigenlijk maar ~150 unieke domeinen geblocked zijn, maar deze wel goed zijn voor ~1m hits (en dat met enkel 2 volwassenen in huis).

[TheCeet]

En hopa. Alweer nieuwe versie:
Pi-hole Core/Web v5.2.1 and FTL v5.3.2 released!

https://pi-hole.net/2020/...-and-ftl-v5-3-2-released/

[Church of Noise]

GieltjE schreef op woensdag 2 december 2020 @ 21:36:
[...]


Een aantal van mijn extra lijsten worden inderdaad niet geraakt, dat zijn dan ook de fraud/scam/mining lists.
Dat deze niet geraakt zijn is meer een goed teken, ga ze ook niet verwijderen.

Dat klinkt zinnig inderdaad, heb er zo ook een aantal. Dit is een voorbeeld van goed weten welke lists je hebt voor welke toepassing (in tegenstelling tot mega-lists die op zich bewerkte compilaties van... zijn).

GieltjE schreef op woensdag 2 december 2020 @ 21:36:
[...]Wel absurd dat er eigenlijk maar ~150 unieke domeinen geblocked zijn, maar deze wel goed zijn voor ~1m hits (en dat met enkel 2 volwassenen in huis).

Exact, en dat is waarom meer blocked domains niet noodzakelijk leiden tot betere resultaten.

[JanPedaal]

Wachten... schreef op maandag 30 november 2020 @ 10:46:
Is iemand hier toevallig bekend met deze YouTube blocklijst ?

Ik weet dat het blocken van YouTube ads niet makkelijk is en er diverse mensen scripts voor hebben draaien. Echter is het importen van een lijst natuurlijk wel heel makkelijk en is deze lijst redelijk recent.

Ik wordt ondertussen flink gek op mijn Nvidia shield en YouTube ads!

Ik had deze lijst per ongeluk opgenomen in mijn blocklists. Geen Youtube ads meer! Ook geen Youtube video's meer!
Geen aanrader.

[Wachten...]

JanPedaal schreef op donderdag 3 december 2020 @ 09:32:
[...]

Ik had deze lijst per ongeluk opgenomen in mijn blocklists. Geen Youtube ads meer! Ook geen Youtube video's meer!
Geen aanrader.

Haha, doet me denken aan het ultieme apparaat die je jaren geleden kon kopen. Het was een apparaat waarmee je tot wel 50 procent minder benzine verbruikte met je auto....

Het apparaat werd massaal gekocht en bleek een stuk hout te zijn die je onder je gaspedaal moest doen

Edit; past trouwens goed bij je naam zie ik nu, die had ik oprecht nog niet gezien!

[ Voor 9% gewijzigd door Wachten... op 03-12-2020 09:58 ]

[Raven]

Weet iemand toevallig of de pagina /admin/settings.php een caching issue heeft m.b.t. PiHole's IPv6 adres? Of beter gezegd het IPv6 adres van de host (RPi)?

Gisteren heb ik een dagje geen IPv6 gebruikt, radvd was ook niet actief, sinds vanmorgen heb ik een /48 waarbij elk (virtueel) netwerk zijn eigen subnet heeft, net als bij IPv4 al het geval was. Voorheen gebruikte ik 1 /64 voor het hele netwerk.

PiHole geeft op /admin/settings.php nog steeds het IPv6 adres met oude subnet aan, terwijl ip addr show eth0 netjes het nieuwe adres, uit een andere /64 dan voorheen, weergeeft.

[Videopac]

GieltjE schreef op woensdag 2 december 2020 @ 21:36:
[...]


Een aantal van mijn extra lijsten worden inderdaad niet geraakt, dat zijn dan ook de fraud/scam/mining lists.
Dat deze niet geraakt zijn is meer een goed teken, ga ze ook niet verwijderen.
Wel absurd dat er eigenlijk maar ~150 unieke domeinen geblocked zijn, maar deze wel goed zijn voor ~1m hits (en dat met enkel 2 volwassenen in huis).

Ik snap je punt en ben het grotendeels ook wel met je eens. Alleen hangt het aantal unieke domeinen dat geblokt wel af van de diveristeit van het internetgebruik in je huishouden. Als er, al dan niet tijdelijk (bijvoorbeeld voor het boeken van een vakantie) naar een andere verzameling sites gesurft wordt is het wel fijn als ook daar geblokkeerd wordt wat je geblokkeerd wil hebben.

[jpgview]

Raven schreef op donderdag 3 december 2020 @ 12:39:
PiHole geeft op /admin/settings.php nog steeds het IPv6 adres met oude subnet aan, terwijl ip addr show eth0 netjes het nieuwe adres, uit een andere /64 dan voorheen, weergeeft.

het address dat in settings word getoond komt uit /etc/pihole/SetupVars.conf. Het word alleen aangepast als je pihole -r uitvoerd. Je kan het natuurlijk ook manueel aanpassen, refresh settings en klaar.

[Raven]

jpgview schreef op donderdag 3 december 2020 @ 16:56:
[...]


het address dat in settings word getoond komt uit /etc/pihole/SetupVars.conf. Het word alleen aangepast als je pihole -r uitvoerd. Je kan het natuurlijk ook manueel aanpassen, refresh settings en klaar.

Ah, daar staat ie, thanks . Overigens, het is setupVars.conf, niet SetupVars.conf, hoofdlettergevoelig

[Wachten...]

Ik probeer mijn Pihole in een unifi systeem te verwerken, maar ik krijg het tot op heden nog niet voor elkaar.

Mijn PiHole heeft hier altijd tussen mijn standaard Tmobile (Zyxel) modem/router gezeten, daarin heb ik toen simpelweg de DHCP uitgezet, en verwezen naar de PiHole DNS die op zijn beurt weer de DHCP regelde.

Bij Unifi kom ik erachter, dat als ik bij mij LAN netwerk (die standaard is aangemaakt) de DHCP uitzet, dat ik dan geen DNS meer aan kan geven.

Heeft iemand enig idee hoe dit werkt bij Unifi?

[Leipo]

Ik laat mijn USG de DHCP doen en verwijs alleen de DNS naar mijn Pi-hole (bij de WAN interface, niet bij de LAN). Dat werkt prima

[ Voor 18% gewijzigd door Leipo op 06-12-2020 12:50 ]

[nero355]

Leipo schreef op zondag 6 december 2020 @ 12:48:
Ik laat mijn USG de DHCP doen en verwijs alleen de DNS naar mijn Pi-hole (bij de WAN interface, niet bij de LAN). Dat werkt prima.

Dat is eigenlijk niet de bedoeling, want dan zie je constant alleen de USG als Client en verder helemaal niks...

Wachten... schreef op zondag 6 december 2020 @ 12:39:
Ik probeer mijn Pihole in een unifi systeem te verwerken, maar ik krijg het tot op heden nog niet voor elkaar.

Mijn PiHole heeft hier altijd tussen mijn standaard Tmobile (Zyxel) modem/router gezeten, daarin heb ik toen simpelweg de DHCP uitgezet, en verwezen naar de PiHole DNS die op zijn beurt weer de DHCP regelde.

Bij Unifi kom ik erachter, dat als ik bij mij LAN netwerk (die standaard is aangemaakt) de DHCP uitzet, dat ik dan geen DNS meer aan kan geven.

Heeft iemand enig idee hoe dit werkt bij Unifi?

Zie wat ik hier al had gepost : nero355 in "[Pi-Hole] Ervaringen & discussie"

[ed1703]

nero355 schreef op zondag 6 december 2020 @ 18:00:
[...]

Dat is eigenlijk niet de bedoeling, want dan zie je constant alleen de USG als Client en verder helemaal niks...

En ook nog eens inefficiënt.
Client lookup==> USG, weet vraag niet===> vraagt aan pihole terug het lan in, gaat vervolgens vragen aan weet ik veel welke dnsserver op internet, stuurt antwoord terug, terug naar USG, terug naar client.

Niet doen.

[Freee!!]

Ik heb een DHCP-server op mijn RPi4B draaien en die geeft gewoon de IP-adressen van de Pi-Holes mee, dus de clients kunnen die direct benaderen.

[Leipo]

vanwege de comments hierboven ben ik het bij mij ook maar verder aan gaan passen. efficient netwerk is wel zo fijn natuurlijk

liep alleen tegen een bug aan: kon de DHCP name server niet op manual zetten want hij sprong steeds terug naar auto

kwam dit tegen: https://www.reddit.com/r/...ver_to_manual_in_network/

controller UI terug gezet naar oude menu structuur en nu pakt hij hem wel als ik hem op manual zet
(versie 6.0.36)

[Kalentum]

https://labzilla.io/blog/force-dns-pihole

Komt dit veel voor? Apparatuur die gewoon de DNS setting in de dhcp negeren en zelfs een DNS server configureren...

[Crahsystor]

Kalentum schreef op zondag 6 december 2020 @ 22:18:
https://labzilla.io/blog/force-dns-pihole

Komt dit veel voor? Apparatuur die gewoon de DNS setting in de dhcp negeren en zelfs een DNS server configureren...

Komt regelmatig voor ja. De oplossing is in je firewall poort 53 blokkeren voor alles behalve je pi-hole. Excacte config is wel te vinden als je zoekt op DNS block port 53.


Wat @ed1703 hieronder aangeeft klopt. (ik had het artikel niet geopend) Onder "Force all DNS queries through PiHole" vind je de uitleg over hoe NAT regels aan te maken .

[ Voor 16% gewijzigd door Crahsystor op 06-12-2020 22:42 ]

[ed1703]

Crahsystor schreef op zondag 6 december 2020 @ 22:30:
[...]

Komt regelmatig voor ja. De oplossing is in je firewall poort 53 blokkeren voor alles behalve je pi-hole. Excacte config is wel te vinden als je zoekt op DNS block port 53.

Hier moet ik toch even op reageren. Blocken van DNS-verkeer maakt je netwerk traag (als de apparatuur al een fallback naar de dhcp dnsservers heeft) een DNAT regel is veel beter en dit staat ook in het artikel. Heb je geen mogelijkheden voor DNAT dan is blocken van dnsverkeer erg nasty en zou ik zeker niet toepassen.

Ik ga er vanuit dat je ook DNAT bedoelde.

[ Voor 12% gewijzigd door ed1703 op 06-12-2020 22:41 ]

[LoeWn]

(misschien) even een noobvraagje:

Ik heb gisteren pi-hole geinstalleerd voor de eerste keer. Nu werkt het in mijn gehele netwerk op een aantal Android devices na. Bij wifi-instellingen staat gewoon netjes als gateway mijn router en als DNS de IP van mijn pi-hole. Toch komen quieres vanuit de browser op Android niet binnen op Pi-hole. Ik krijg wel quieries zoals onderstaande:
- nl.tmobile.rcs.telephony.goog
- nl.tmobile.rcs.telephony.goog
- SRV_sips._tcp.nl.tmobile.rcs.telephony.goog
- epdg.epc.mnc016.mcc204.pub.3gppnetwork.org
- play.googleapis.com
- mtalk.google.com
- connectivitycheck.gstatic.com
- www.google.com

Klopt het dat dan dat de browser de gekozen DNS van het systeem negeert? Eigenlijk hetzelfde als de posts hierboven?

[JeroenE]

Kalentum schreef op zondag 6 december 2020 @ 22:18:
Komt dit veel voor? Apparatuur die gewoon de DNS setting in de dhcp negeren en zelfs een DNS server configureren...

Schijnt ook bij apps (of malware) te gebeuren of dat men met DNS-over-HTTPS bij hun 'eigen' server informatie opvraagt om die te gebruiken ipv de lokale DNS server.

[nero355]

@LoeWn

Er zijn meerdere mogelijke redenen dat je problemen ervaart dus hoe heb je alles geconfigureerd en heb je about:config en chrome://flags doorgebladerd en aangepast

Tegenwoordig zijn vooral telefoons en hun apps een zooitje aan het worden!

[switchboy]

Crahsystor schreef op zondag 6 december 2020 @ 22:30:
[...]

Komt regelmatig voor ja. De oplossing is in je firewall poort 53 blokkeren voor alles behalve je pi-hole. Excacte config is wel te vinden als je zoekt op DNS block port 53.


Wat @ed1703 hieronder aangeeft klopt. (ik had het artikel niet geopend) Onder "Force all DNS queries through PiHole" vind je de uitleg over hoe NAT regels aan te maken .

Of beter versleutelde DNS via cloudflared gebruiken. Dan kan je poort 53 op je router dichttimmeren en weet je zeker dat al de DNS queries die je netwerk afgaan versleuteld zijn!

Nu is het natuurlijk wachten tot de 'slimme' speakers chromecasts en smartTV's dit trucje ook doorhebben en hun DNS ook op een willekeurige poort versleuteld laten lopen.

Er zijn nu ook docker stacks waarmee je ze beide gecombineerd draait:
https://github.com/cjk/docker-pihole

NB: als je op een oude portainer zit (als je bijvoorbeeld Open Media Vault draait) dan even version 3 in version 2 verranderen en dan parsed het composer script zonder problemen.

[ Voor 18% gewijzigd door switchboy op 07-12-2020 22:02 ]

[Verwijderd]

https://www.security.nl/p...+van+hardcoded+dns-server


Smart apparaten omzeilen Pi-hole door middel van hardcoded dns-server

[deHakkelaar]

Verwijderd schreef op maandag 7 december 2020 @ 22:41:
https://www.security.nl/p...+van+hardcoded+dns-server


Smart apparaten omzeilen Pi-hole door middel van hardcoded dns-server

Soms toch niet zo hardcoded:

https://discourse.pi-hole...sing-pi-hole-dhcp/40435/8

https://github.com/pi-hole/pi-hole/pull/3846

[ Voor 5% gewijzigd door deHakkelaar op 07-12-2020 22:54 ]

[nero355]

Dat heb ik inderdaad wel vaker gepost als oplossing : Vul gewoon meerdere DNS Servers in als je de kans hebt en vaak is dat genoeg om in ieder geval de omschreven OnePlus achtige problemen te fixen!

Zie mijn recente reactie met de link naar de originele reactie : nero355 in "[Pi-Hole] Ervaringen & discussie"

[deHakkelaar]

Misschien is de logica dat als er maar één DNS server wordt aangeleverd via DHCP, dat dan automatisch een tweede of mischien zelfs derde hardcoded DNS server wordt toegevoegd voor redundancy.
Zogenaamde smart devices waarvan je niet weet wat ze doen en waarom vanwege ontbrekende source code

[nero355]

deHakkelaar schreef op dinsdag 8 december 2020 @ 00:24:
Misschien is de logica dat als er maar één DNS server wordt aangeleverd via DHCP, dat dan automatisch een tweede of mischien zelfs derde hardcoded DNS server wordt toegevoegd voor redundancy.

Mja, wat de reden ook is : Ik heb liever dat ze dat NIET DOEN!!!

Zogenaamde smart devices waarvan je niet weet wat ze doen en waarom vanwege ontbrekende source code

Ik snap eerlijk gezegd niet waarom we na al die jaren al die "Smart" apparaten überhaupt smart noemen, want als ik heel eerlijk ben zijn ze nog steeds net zo dom als voordat de "Smart Hype" begon!

[deHakkelaar]

Idd, records op de DNS servers moeten identiek zijn of je krijgt inconsistente antwoorden.
Ééne keer wel blocken en de ander keer niet.
Soms kun je wel lokale namen resolven en soms niet.
Bagger dus.