[Pi-Hole] Ervaringen & discussie

[Verwijderd]

Pierre schreef op donderdag 1 oktober 2020 @ 18:47:
Ik verbaas me iedere keer weer dat men geen originele power supply er gewoon standaard bij koopt.

Voorheen kreeg je bij elke product wat je kocht een power supply. Daardoor hebben veel mensen een hoop thuis liggen. Dan wil je toch gewoon proberen om die te gebruiken. En voor mij werkt de telefoonlader nu prima. Zonder crashes. Is ook nog eens beter voor het milieu dan elke keer nieuw kopen. Dat is ook de reden dat er nu wetgeving is omtrent power supplies in Europa. Hergebruik stuurt Europa nou juist op.

[ Voor 10% gewijzigd door Verwijderd op 01-10-2020 19:28 ]

[JayOne]

Verwijderd schreef op donderdag 1 oktober 2020 @ 19:27:
[...]


Voorheen kreeg je bij elke product wat je kocht een power supply. Daardoor hebben veel mensen een hoop thuis liggen. Dan wil je toch gewoon proberen om die te gebruiken. En voor mij werkt de telefoonlader nu prima. Zonder crashes. Is ook nog eens beter voor het milieu dan elke keer nieuw kopen. Dat is ook de reden dat er nu wetgeving is omtrent power supplies in Europa. Hergebruik stuurt Europa nou juist op.

Het gaat erom dat de apparatuur de juiste (continue) voeding krijgt. Dat jij geen crashes ervaart, betekent nog niet dat er geen kleine verstoringen in het circuit zijn, wat op den duur leidt tot een situatie waar kortsluiting ontstaat. Maar prima als het voor jouw zo werkt, maar sommige specs zijn er niet voor niks.

[nero355]

Raven schreef op donderdag 1 oktober 2020 @ 18:51:
Of doe zoals ik en bestel
[Afbeelding]

Ik heb een shitload aan voedingen liggen, voedingen die geschikt zijn voor RPi's.... not so much, meeste heeft de uitgangsspanning te hoog. Met een oplossing zoals dat kan ik er een uit mijn voorraad gebruiken. Niet echt een nette oplossing, maar in mijn geval hangt die aan passieve PoE (19V) en dan komt zo'n ding van pas

Leuk ding, maar dan moet je hem wel kwijt kunnen

[Jazco2nd]

never mind.

[ Voor 92% gewijzigd door Jazco2nd op 02-10-2020 20:24 ]

[Jazco2nd]

nero355 schreef op donderdag 24 september 2020 @ 14:47:
Wat dat betreft is dit:

deHakkelaar schreef op donderdag 24 september 2020 @ 01:32:
[...]

Dit is veel minder veilig dan als je twee vershillende subnets hanteerdt voor je LAN en VPN gebruikers.
Als boefjes je VPN kunnen binnendringen, zitten ze meteen op je LAN.
Met twee subnets en juiste firewall regels kun je juist goed scheiden voor extra veiligheid.
En port-forward / NAT je alleen die services naar het VPN subnet welke je beschikbaar wilt maken voor de VPN gebruikers.

Aangezien de meesten Pi-hole en de VPN server op de zelfde host draaien, hoef je voor DNS niets te NAT-en aangezien de VPN gebruikers de VPN server IP kunnen gebruiken voor DNS.
Je kan dan Pi-hole configureren, via de web GUI, om op alle interfaces te luisteren (inclusief "wg0" voor Wireguard en "tun0" voor OpenVPN).
En zorgen dat op de Pi-hole host, er geen "interface=" regels zijn gedefinieerd in de config bestanden in de folder "/etc/dnsmasq.d/".

code:

sudo grep -i 'interface=' -R /etc/dnsmasq.*

nero355 schreef op donderdag 24 september 2020 @ 14:47:
The way to go!

Ik heb dat ook geprobeerd. Werkt niet. LAN blijft werken, Wireguard VPN niet.
Heb ook geprobeerd met luisteren naar de locale interface en volgens wel een bestandje in die map met interface=wg0 geplaatst. Geen succes. Linksom, rechtsom..

nero355 schreef op woensdag 23 september 2020 @ 14:54:
[...]

Maar je kan toch gewoon de boel Bridgen met je eigen LAN i.p.v. een /28 te definiëren

- Bridge je Docker Container Network met je LAN.
- Bridge OpenVPN/Wireguard met het LAN waar die aan hangt.

En gaan met die banaan

Daarnaast hoeft mijn Raspberry Pi of de Host waarop Docket draait niet met de Containers te communiceren : Zolang mijn netwerk dat kan dan vind ik het allemaal best

@Jazco2nd : Zou je zoiets kunnen proberen

Het is redelijk abradacabra voor mij. Ik weet hier niks van.. en ga het dus niet werkend krijgen.


Los hiervan. Wat biedt Pi-Hole nu eigenlijk?
Ik lees dat adblocking net zo goed via Unbound kan. en caching ook (dat was een eerst argument om PiHole icm Unbound te gebruiken). Unbound gebruik ik toch al als recursive DNS.

De PiHole webUI biedt mij niks nuttigs, instellen gaat al via mijn docker-compose.
Ik gebruik het thuis, niet voor een klein bedrijf en ga echt niet groepen zitten maken. Zie niet in waarom ik onderscheid moet maken in groepen. De statistieken vind ik een security/privacy issue dus ik heb logging uitgeschakeld. Ik wil niet van de mensen in huis een database met alle sites die ze bezoeken en wanneer verzamelen (en hidden stats zijn helemaal nutteloos).

Daarnaast is het ook wel gek dat PiHole ad requests niet netjes naar een pixelserver stuurt (waardoor je af en toe lelijke foutmeldingen ziet). En zie ik geen ontwikkeling in de richting van eenvoudig per device eventjes adblocking uitschakelen.

Dan kan ik net zo goed adblocking via Unbound werkend krijgen en daar uitzoeken hoe je Wireguard VPN ook werkend krijgt.. Of zie ik een gruwelijk mooie feature van PiHole over het hoofd?

[ Voor 8% gewijzigd door Jazco2nd op 02-10-2020 21:10 ]

[JayOne]

Jazco2nd schreef op vrijdag 2 oktober 2020 @ 20:47:
Ik gebruik het thuis, niet voor een klein bedrijf en ga echt niet groepen zitten maken. Zie niet in waarom ik onderscheid moet maken in groepen.

Heb hier in huis wel groepen aangemaakt, zodat ik afwijkende whitelists kan maken voor bijvoorbeeld mijn vriendin (die bijvoorbeeld toch heel graag de googleshop-ads wil aanklikken).

[grote_oever]

JayOne schreef op vrijdag 2 oktober 2020 @ 21:13:
[...]

Heb hier in huis wel groepen aangemaakt, zodat ik afwijkende whitelists kan maken voor bijvoorbeeld mijn vriendin (die bijvoorbeeld toch heel graag de googleshop-ads wil aanklikken).

ik zie dan eerlijk gezegd het nut niet in voor thuis gebruik. Als je, in mijn geval, 50% van de gebruikers whitelist geeft. Kun je net zo goed jou ook toegang geven. Is flink wat frustratie minder bij google.

Ik snap dat je bij kleine bedrijven zoiets wilt toepassen (alhoewel ik me afvraag of je dat via pihole wilt doen). En misschien met opgroeiende pubers is het ook wel handig.

[nero355]

Jazco2nd schreef op vrijdag 2 oktober 2020 @ 20:47:
Het is redelijk abradacabra voor mij. Ik weet hier niks van.. en ga het dus niet werkend krijgen.

Dan houdt het op

Los hiervan. Wat biedt Pi-Hole nu eigenlijk?
Ik lees dat adblocking net zo goed via Unbound kan. en caching ook (dat was een eerst argument om PiHole icm Unbound te gebruiken). Unbound gebruik ik toch al als recursive DNS.

De PiHole webUI biedt mij niks nuttigs, instellen gaat al via mijn docker-compose.
Ik gebruik het thuis, niet voor een klein bedrijf en ga echt niet groepen zitten maken. Zie niet in waarom ik onderscheid moet maken in groepen. De statistieken vind ik een security/privacy issue dus ik heb logging uitgeschakeld. Ik wil niet van de mensen in huis een database met alle sites die ze bezoeken en wanneer verzamelen (en hidden stats zijn helemaal nutteloos).

Dan kan ik net zo goed adblocking via Unbound werkend krijgen en daar uitzoeken hoe je Wireguard VPN ook werkend krijgt.. Of zie ik een gruwelijk mooie feature van PiHole over het hoofd?

NOFI, maar dit klinkt een beetje als "Ik krijg Pi-Hole niet werkend zoals ik wil dus ga ik het maar helemaal als nutteloos afschilderen!"

Daarnaast is het ook wel gek dat PiHole ad requests niet netjes naar een pixelserver stuurt (waardoor je af en toe lelijke foutmeldingen ziet).

Wat bedoel je precies met een pixelserver

Je kan wel degelijk terug naar de oude manier van adblocking overstappen : https://docs.pi-hole.net/ftldns/blockingmode/

En zie ik geen ontwikkeling in de richting van eenvoudig per device eventjes adblocking uitschakelen.

Wordt aan gewerkt geloof ik, maar het is lang geleden dat ik daar iets over heb gelezen dus kan het mis hebben...

grote_oever schreef op vrijdag 2 oktober 2020 @ 21:30:
ik zie dan eerlijk gezegd het nut niet in voor thuis gebruik. Als je, in mijn geval, 50% van de gebruikers whitelist geeft. Kun je net zo goed jou ook toegang geven. Is flink wat frustratie minder bij google.

Google kan de pot op!

Zoiets zou ik dus echt NOOIT doen!

Ik snap dat je bij kleine bedrijven zoiets wilt toepassen (alhoewel ik me afvraag of je dat via pihole wilt doen). En misschien met opgroeiende pubers is het ook wel handig.

Tja, je kan ook pfSense gebruiken voor hetzelfde doel onder andere dus het is maar net waar je zin in hebt

[JayOne]

grote_oever schreef op vrijdag 2 oktober 2020 @ 21:30:
[...]

ik zie dan eerlijk gezegd het nut niet in voor thuis gebruik. Als je, in mijn geval, 50% van de gebruikers whitelist geeft. Kun je net zo goed jou ook toegang geven. Is flink wat frustratie minder bij google.

Ik snap dat je bij kleine bedrijven zoiets wilt toepassen (alhoewel ik me afvraag of je dat via pihole wilt doen). En misschien met opgroeiende pubers is het ook wel handig.

Uh het is een optie hè, je hoeft het niet te gebruiken. Persoonlijk vind ik het wel prettig om zo weinig mogelijk ads in mijn browsers te hebben, zonder daarvoor allemaal apps/programma's op allerlei telefoons/laptop te draaien. Centraal geregeld zonder dat de mensen in huis er echt heel veel last van hebben (af en toe een domein wat gewhitelist moet worden, maar dat is mondjesmaat het geval).

[grote_oever]

JayOne schreef op zaterdag 3 oktober 2020 @ 08:20:
[...]

Uh het is een optie hè, je hoeft het niet te gebruiken. Persoonlijk vind ik het wel prettig om zo weinig mogelijk ads in mijn browsers te hebben, zonder daarvoor allemaal apps/programma's op allerlei telefoons/laptop te draaien. Centraal geregeld zonder dat de mensen in huis er echt heel veel last van hebben (af en toe een domein wat gewhitelist moet worden, maar dat is mondjesmaat het geval).

Ads ben ik met je eens. Google wordt met name voor tracking geblokkeerd. Ik heb het echt geprobeerd, maar ik kom altijd weer terug op Google. De combinatie met shopping, maps en het zoeken is voor mij perfect.

Maar goed, das misschien een andere discussie.

[westlym]

Eerst pi hole gebruikt, daarna overgestapt naar PfSense, en nu weer terug naar Pihole samen met Unbound. Ik was eerst bij telfort, en nu overgestapt naar Tweak met een Fritsboz..hopelijk biedt het laatste mij genoeg veiligheid online samen met Pihole.

Pfsense is wel goed, maar dan moet ik met vlan's gaan werken terwijl ik geen knowhow heb over vlan's. Maar pc met pfsense staat er nog, dus wie weet...

[Lizard]

nero355 schreef op zaterdag 3 oktober 2020 @ 00:06:
[...]

Wat bedoel je precies met een pixelserver

[...]

https://www.snbforums.com...server-for-adblock.26114/
https://github.com/kvic-z...91tls-for-Pi%E2%80%91Hole

[ Voor 12% gewijzigd door Lizard op 03-10-2020 12:53 ]

[nero355]

westlym schreef op zaterdag 3 oktober 2020 @ 11:12:
Eerst pi hole gebruikt, daarna overgestapt naar PfSense, en nu weer terug naar Pihole samen met Unbound. Ik was eerst bij telfort, en nu overgestapt naar Tweak met een Fritsboz..hopelijk biedt het laatste mij genoeg veiligheid online samen met Pihole.

Pfsense is wel goed, maar dan moet ik met vlan's gaan werken terwijl ik geen knowhow heb over vlan's. Maar pc met pfsense staat er nog, dus wie weet...

pfSense kan je gewoon achter een "modem" neerzetten en gebruiken alsof het elke willekeurige router zonder VLAN support is dus dat mag geen probleem zijn

Lizard schreef op zaterdag 3 oktober 2020 @ 12:53:
https://www.snbforums.com...server-for-adblock.26114/
https://github.com/kvic-z...91tls-for-Pi%E2%80%91Hole

Nou... dan is dat probleem ook weer opgelost!

Ik zie alleen nergens zo gauw wat zij anders doen dan Pi-Hole wat betreft de blocking mode, maar goed... het is een optie voor degenen die dat willen!

[Lizard]

nero355 schreef op zaterdag 3 oktober 2020 @ 14:29:
[...]

Nou... dan is dat probleem ook weer opgelost!

Ik zie alleen nergens zo gauw wat zij anders doen dan Pi-Hole wat betreft de blocking mode, maar goed... het is een optie voor degenen die dat willen!

Pixelserv vervangt de plaatjes van de ads door een met 1 pixel. waardoor je geen broken imageholders meer hebt. Wel zul je het certificaat van pixelserv op je device moeten accepteren.

[deHakkelaar]

Jazco2nd schreef op vrijdag 2 oktober 2020 @ 20:47:
Daarnaast is het ook wel gek dat PiHole ad requests niet netjes naar een pixelserver stuurt (waardoor je af en toe lelijke foutmeldingen ziet).

Een pixelserver gebruiken voor de geblokkeerde domeinen is hoe Pi-hole was begonnen oorspronkelijk maar inmiddels zijn vanaf gestapt.
De meeste ads etc komen via HTTPS binnen.
Je kan niet de TLS certificaten omzeilen/afvangen behalve als je de pixelserver onwenselijk als MITM configureerd met je eigen signed cert.
Dit cert moet je dan op al je clients (en gasten) installeren.
Daarom is Pi-hole overgestapt op NULL blocking wat inhoud dat lookups voor alle domeinen op de block/adlists worden beantwoord met 0.0.0.0 ipv het IP van de pixelserver.
Maar je kan nog steeds terug naar de oude manier met een pixelserver zoals @nero355 al had aangegeven:

nero355 schreef op zaterdag 3 oktober 2020 @ 00:06:
Je kan wel degelijk terug naar de oude manier van adblocking overstappen : https://docs.pi-hole.net/ftldns/blockingmode/

[Jazco2nd]

@Lizard @Verwijderd thanks voor de info, dat wist ik niet.
@nero355 ik was idd behoorlijk gefrusteerd om dit werkend te krijgen. Afgelopen weekend veel trial & error gedaan. Hier wat bevindingen.

Situatie LAN:

code:

router: 192.168.88.1
LAN network: 192.168.88.0/24
host (Ubuntu 20.04): 192.168.88.10

Situatie Docker netwerk:

code:

networks:
  DNS-network:
    driver: macvlan
    driver_opts:
      parent: eno1
    ipam:
      config:
        - subnet: 192.168.88.0/24
          gateway: 192.168.88.1
          ip_range: 192.168.88.96/29  # gekozen subrange van LAN subnet
          aux_addresses:          # addressen die ik via Docker-Compose zet, dus hier reserveer
            host-macvlan: 192.168.88.96 #  gereserveerd voor de host macvlan (zie uitleg)
            Unbound: 192.168.88.98
            PiHole: 192.168.88.99
            Unifi: 192.168.88.100

PiVPN (Wireguard) geinstalleerd op de host direct, en 1.1.1.1 (Cloudflare) als DNS gekozen. Verder ingesteld dat alleen 192.168.88.0/24 via de tunnel gaat voor clients. Dit werkt. Vervolgens heb ik in de client.conf het DNS aangepast naar die van PiHole. Daarna kan de client helaas geen site meer bereiken.

PiVPN Wireguard config:

code:

::::  Server configuration shown below   ::::
[Interface]
PrivateKey = server_priv
Address = 10.6.0.1/24
ListenPort = 51822
### begin Pixel-phone ###
[Peer]
PublicKey = Pixel-phone_pub
PresharedKey = Pixel-phone_psk
AllowedIPs = 10.6.0.2/32
### end Pixel-Phone ###
=============================================
::::  Client configuration shown below   ::::
[Interface]
PrivateKey = Pixel-phone_priv
Address = 10.6.0.2/24
DNS = 192.168.88.99

[Peer]
PublicKey = server_pub
PresharedKey = Pixel-phone_psk
Endpoint = REDACTED:51822
AllowedIPs = 192.168.88.0/24, ::0/0
===============================

Het probleem ligt volgens mij niet bij PiHole. De client kan namelijk zelfs niet pingen naar het IP van de PiHole. Dus moeten we een oplossing vinden in het bridgen (zoals Nero355 aangaf).

Om dit op te lossen en ook direct ervoor te zorgen dat de host zelf websites kan bezoeken (ik gebruik mijn server ook als workstation), heb ik een macvlan op de host zelf ingesteld, zoals ik eerder hier omschreef.

Nu heb ik ontdekt dat dat onhandig is, je moet dan voor elk docker macvlan IP adres een extra route toevoegen. Dit kan simpeler, door de macvlan aan te passen. Ik snap zelf niet waarom dit werkt btw:

code:

sudo ip link add mynet-shim link eno1 type macvlan mode bridge
sudo ip addr add 192.168.88.96/32 dev mynet-shim
sudo ip link set mynet-shim up
sudo ip route add 192.168.88.96/29 dev mynet-shim

Dit zorgt ervoor dat 1 adres is (namelijk het via Compose gereserveerde IP adres 192.168.88.96) wordt gebridged en daaraan hang je het hele bereik van je docker macvlan (met /32 heb je alleen dat ene IP, met /29 het bereik).

Middels deze truc kan de host nu bij alle macvlan IP adressen inclusief die van PiHole. Ik heb 2 sites (fora) gevonden waar dit ook de uitleg was om PiVPN-Wireguard werkend te krijgen.
Helaas bleek dit geen effect te hebben.

Later ontdekte ik dat de Wireguard client config niet het IP van de PiHole moeten gebruiken bij "DNS=" maar juist het eerste adres in de range van het Wireguard network, in dit geval (zie hierboven)

code:

DNS = 10.6.0.1

Ook dit heeft helaas geen effect.
Ik heb ook dit geprobeerd, een 2e macvlan aanmaken maar dat kan nie:

code:

sudo ip link add mynet-shim link wg0 type macvlan mode bridge

Waarbij wg0 de interface is van Wireguard (gecheckt met ifconfig) maar dit commando krijg ik niet uitgevoerd, kreeg een melding van ongeldig argument ofzo.

Dus flink gepuzzeld maar niks brengt me in de juiste richting. Alleen een upstream/extern DNS zoals 1.1.1.1 werkt.

[ Voor 12% gewijzigd door Jazco2nd op 05-10-2020 19:14 ]

[deHakkelaar]

@Jazco2nd ik denk niet dat dit draadje bedoeld is om ingewikkelde problemen op te lossen.
Ik denk dat niemand hier zit te wachten op een muur van configuraties en probleem omschrijvingen.
De Pi-hole support forums zijn daar de juiste plek voor:

https://discourse.pi-hole.net/

Kans is ook groter dat je daar een juist antwoord krijgt omdat het publiek vele malen groter is als hier.

[nero355]

deHakkelaar schreef op maandag 5 oktober 2020 @ 19:38:
@Jazco2nd ik denk niet dat dit draadje bedoeld is om ingewikkelde problemen op te lossen.
Ik denk dat niemand hier zit te wachten op een muur van configuraties en probleem omschrijvingen.
De Pi-hole support forums zijn daar de juiste plek voor:

https://discourse.pi-hole.net/

Kans is ook groter dat je daar een juist antwoord krijgt omdat het publiek vele malen groter is als hier.

@Jazco2nd Het Docker Topic zou opzich ook nog wel kunnen denk ik : [Docker] [alle OS] Het grote Docker ervaringen en tips topic

[Verwijderd]

@Jazco2nd: uit jouw verhaal is mij niet geheel duidelijk geworden of de Pi-Hole wel of niet luistert naar de adressen van je VPN, en of daarop ook antwoorden gegeven worden.

In de webinterface zit dat in Settings / DNS / Interface listening behavior - dat moet op Listen on all interfaces, permit all origins staan. Anders blijf je aan het configureren maar komt er nooit antwoord retour van de Pi-Hole.

[Chrisje1983]

Ik word geloof ik gek hier,

Kan het wezen dat bijvoorbeeld de netflix app op android 10 (telefoon) een eigen dns server gebruikt dan wel pushed?

Of dat misschien android 10 zelf eigen dns servers pushed, zelfs als je in je telefoon statisch een ip adres en dns server invoert?

Ik kan in mijn thuis netwerk met geen mogelijkheid mijn telefoon netflix ontzeggen.

Ik zie een aantal dingen in pihole langskomen wat betreft netfllix van mijn telefoon ip, daarna wordt pihole helemaal niet meer gebruik zo lijkt het. Alsof de telefoon de broadcast of statisch ingegeven dns server scant en vervolgens lekker een eigen dns server pusht/gebruikt.

Ik heb op de telefoon zelf al mijn wifi netwerk statisch toegevoegd (ipv in de router) en hem dus ook het dns adres van pihole gegeven maar geen resultaat / verschil met de router het werk laten doen.

Als ik wifi op de telefoon uitzet, en VPN inlog naar mijn synology server en dus mijn netwerk en dns broadcast eigenlijk forceer, dan pas krijg ik het wel voor elkaar om het gebruik van netflix te blocken. Maar, ik kan dan gek genoeg nog steeds inloggen in netflix en ik zie niks langskomen in pihole op dat moment.

Heb dit nog nooit meegemaakt eigenlijk. Het gaat erom dat ik dus netflix en of andere apps in mijn netwerk wil blocken voor bepaalde apparaten, dit test ik dus op mijn telefoon. Op de andere apparaten werkt het overigens wel, mijn telefoon is dus niet echt handig test materiaal zo blijkt

Websites blocken en met de browser op de telefoon testen geeft ook echt een block.

Ik had trouwens even mijn pihole uit de lucht, en het valt mij op dat mijn telefoon eerst nergens komt zoals het hoort, maar op een gegeven moment kan hij zich prima kan redden zonder dns server in de lucht en dus een ander dns adres lijkt te gebruiken. Ook hierin is mijn telefoon het enige apparaat dat dat voor elkaar krijgt in mijn netwerk.

In mijn netwerk gebruik ik maar een dns server adres, dat is het adres van pihole, dat heb ik in de dnsmasq.conf staan en dus word dat ip adres ook gebroadcast over mijn netwerk.

Het is dus met toeval dat ik tegen dit probleem aanloop, en eigenlijk lijkt alleen mijn telefoon er last van te hebben.

(sim kaart eruit halen maakt geen verschil)

Iemand?


Edit> ik heb pihole (synology docker) uit de lucht gehaald, en de backup pihole op een raspberry weer in de lucht gegooid. De dns ip van de raspberry heb ik in de routers en dnsmasq.conf aangepast zodat alles in het netwerk de raspberry pihole gebruikt ipv synology docker, natuurlijk alle routers gereboot en helaas precies hetzelfde probleem.

Ik blijf erbij dat mijn telefoon (een huawei p30) zelf dns servers pushed als de aangeboden dns server hem niet zint...

Ook vreemd dat als ik de dns server in mijn netwerk offline haal, ik nog steeds kan blijven browsen op mijn telefoon.
Dat browsen op mijn telefoon is dan wel met een vertraging van 2 seconden voordat een website laad (alsof hij na 2 seconden proberen een ander dns voorgeschoteld krijgt), is mijn dns server weer in de lucht, dan laden de websites weer instant.

Edit>

Ook amazon prime en disney kan ik bereiken op mijn telefoon, alle overige apparaten worden wel geblockt.

Eerst maakt mijn telefoon gebruik van pihole, en zie ik allerlei disney en amazon requests langskomen. Zodra ik in pihole alles wat met amazon en disney te maken heeft block, dan stopt mijn telefoon met sturen van dns requests naar pihole en gaat vrolijk verder.

[ Voor 21% gewijzigd door Chrisje1983 op 06-10-2020 03:55 ]

[heeten12]

@Chrisje1983

Van Netflix weet ik zeker dat die terugvalt op een bepaalde DNS server. Heb daarvan alle telemetrie geblokkeerd en dan "denkt" hij dat jouw ingestelde DNS server down is. Gelukkig via OPNSense router alle dns verzoeken die niet naar de pihole gaan weer gerouteerd naar de pihole. Daarin zag ik ze na een bepaalde update dus als zijnde verzoeken van de router IPV Netflix device.

Als je een router hebt die dit ondersteunt dan kun je het makkelijk oplossen

[The Druid]

Chrisje1983 schreef op dinsdag 6 oktober 2020 @ 02:04:
Ik word geloof ik gek hier,

Kan het wezen dat bijvoorbeeld de netflix app op android 10 (telefoon) een eigen dns server gebruikt dan wel pushed?

Klopt, lees dit verhaal maar eens over apparaten die je Pihole bewust negeren.

[Xenir]

Een reden dat ik enkel DNS verkeer toesta naar de Pihole, de rest wordt geblokkeerd door de firewall. Ik heb geen redirect toegepast zoals het artikel voorstelt, tot nu toe gaat dat wel goed.

[Jazco2nd]

Verwijderd schreef op dinsdag 6 oktober 2020 @ 01:10:
@Jazco2nd: uit jouw verhaal is mij niet geheel duidelijk geworden of de Pi-Hole wel of niet luistert naar de adressen van je VPN, en of daarop ook antwoorden gegeven worden.

In de webinterface zit dat in Settings / DNS / Interface listening behavior - dat moet op Listen on all interfaces, permit all origins staan. Anders blijf je aan het configureren maar komt er nooit antwoord retour van de Pi-Hole.

Dat had ik in een eerdere post omschreven. Dat is het eerste wat ik deed. Maar het probleem ligt elders omdat ik via VPN nieteens kan pingen naar het PiHole adres.

[Toet3r]

Chrisje1983 schreef op dinsdag 6 oktober 2020 @ 02:04:
*knip*

Wat voor router heb je? Op de een beetje gevanceerde routers kan je doormiddel van NAT regels al het dns verkeer dat niet naar het ip van je pi-hole gaat alsnog daar heen sturen.
Ik heb dit zelf ook gedaan op mij Edgerouter X sfp.

[beerns]

The Druid schreef op dinsdag 6 oktober 2020 @ 07:52:
[...]


Klopt, lees dit verhaal maar eens over apparaten die je Pihole bewust negeren.

En ik heb het een aantal maanden geleden ingericht net zoals dit artikel (oa) uit legt. Dus Pihole ism een USG.
Dat ging met vallen en opstaan, maar uiteindelijk gelukt en ik zie mn chomecasts etc netjes het verkeer via de pi hole laten (ver)lopen en niet een eigenhandige weg naar buiten zoeken.
Heb ook wat chinese smartplugs en ook die gaan eerst mn pi hole door ondertussen.
Kortom: dit is een werkwijze die wel degelijk werkt.

[Yucko]

mijn Asus AC68U heeft ook de optie om alle DNS requests naar een specifiek IP om te leidend maar wanneer ik dan al het DNS verkeer naar mijn Pi-Hole probeer om te leiden dan ligt mijn internet plat en zie ik in de Pi-Hole logs 40K+ requests op notime voorbij komen

Binnenkort maar eens uitzoeken wat daar precies misgaat

[ Voor 3% gewijzigd door Yucko op 06-10-2020 12:25 ]

[roeleboel]

Yucko schreef op dinsdag 6 oktober 2020 @ 12:25:
mijn Asus AC68U heeft ook de optie om alle DNS requests naar een specifiek IP om te leidend maar wanneer ik dan al het DNS verkeer naar mijn Pi-Hole probeer om te leiden dan ligt mijn internet plat en zie ik in de Pi-Hole logs 40K+ requests op notime voorbij komen

Binnenkort maar eens uitzoeken wat daar precies misgaat

Dat lijkt me dat de requests die pihole zelf uitstuurt (omdat hij ze lokaal niet kan resolven) ook worden omgeleid naar... je pihole. Oftewel: je hebt een loop gecreerd. Je moet een uitzondering geven voor het ip van de pihole zelf, of wanneer dat niet kan overwegen je pihole extern te draaien.

[Raven]

Yucko schreef op dinsdag 6 oktober 2020 @ 12:25:
mijn Asus AC68U heeft ook de optie om alle DNS requests naar een specifiek IP om te leidend maar wanneer ik dan al het DNS verkeer naar mijn Pi-Hole probeer om te leiden dan ligt mijn internet plat en zie ik in de Pi-Hole logs 40K+ requests op notime voorbij komen

Binnenkort maar eens uitzoeken wat daar precies misgaat

Je hebt toch wel aangegeven (als dat kan) om het ip van PiHole te excluden voor die optie?

edit: Zie hierboven, note to self: Eerst replies kijken, dan pas quoten

[ Voor 6% gewijzigd door Raven op 06-10-2020 12:51 ]

[Yucko]

@roeleboel en @Raven :
omg
inderdaad, zonder uitzondering wordt verkeer van de Pi-Hole naar de upstream DNS server natuurlijk ook weer omgeleidt naar de Pi-Hole zelf.

uitzondering toegevoegd en het lijkt nu te werken.

Ben nu wel benieuwd of ik een toename in geblokkeerde DNS requests ga zien doordat er apps/devices waren die de via DHCP server aangegeven DNS server negeerden

[ Voor 11% gewijzigd door Yucko op 06-10-2020 14:25 ]

[Cyberpope]

Yucko schreef op dinsdag 6 oktober 2020 @ 14:08:
@roeleboel en @Raven :
omg
inderdaad, zonder uitzondering wordt verkeer van de Pi-Hole naar de upstream DNS server natuurlijk ook weer omgeleidt naar de Pi-Hole zelf.

uitzondering toegevoegd en het lijkt nu te werken.

Ben nu wel benieuwd of ik een toename in geblokkeerde DNS requests ga zien doordat er apps/devices waren die de via DHCP server aangegeven DNS server negeerden

Heb je hier ergens een how-to van?

[Quad]

Chrisje1983 schreef op dinsdag 6 oktober 2020 @ 02:04:

Ik blijf erbij dat mijn telefoon (een huawei p30) zelf dns servers pushed als de aangeboden dns server hem niet zint...

Ik had met mijn Huawei P30 idem dat ads nog steeds aangeboden werden. Gelukkig gaan deze via Google DNS, daarom heb ik een blackhole op mijn UniFi firewall gemaakt voor 8.8.8.8 en 8.8.4.4.



Sindsdien loopt via mijn Huawei P30 alles via de Pihole DNS.

[Luc45]

Als je dat volledig dicht wilt zetten, is het makkelijker om DNS (port 53 tcp en udp) outbound te blokkeren in de firewall, uitgezonderd voor je pihole host. Er zijn best veel DNS servers die gebruikt kunnen worden en je weet nooit of een fabrikant met een firmware update deze service aanpast.

[ Voor 3% gewijzigd door Luc45 op 06-10-2020 16:00 ]

[Yucko]

Cyberpope schreef op dinsdag 6 oktober 2020 @ 15:09:
[...]

Heb je hier ergens een how-to van?

Zie DM

[nero355]

Chrisje1983 schreef op dinsdag 6 oktober 2020 @ 02:04:
Ik word geloof ik gek hier

Jij wordt niet gek : De apparaten zijn gek geworden!

Kan het wezen dat bijvoorbeeld de netflix app op android 10 (telefoon) een eigen dns server gebruikt dan wel pushed?

Dat doen heel veel Google Android gerelateerde apparaten en apps :
- Google Chrome zonder de juiste chrome://flags aanpassingen
- Chromecast ondingen...
- Steeds meer op Google Android gebaseerde telefoons!

Of dat misschien android 10 zelf eigen dns servers pushed, zelfs als je in je telefoon statisch een ip adres en dns server invoert?

Dat kan inderdaad heel goed!

- Amazon/Disney/Netflix knip -

Wat ook nog roet in het eten kan gooien is de hele DNS over HTTPS en soortgelijken trend : Sommige apps hebben een eigen DNS Server die ze aanspreken en pas als je die blokkeert stappen ze over op jouw DNS Server!

Wat je ook nog kan doen tegen al deze ellende naast de al gegeven tips :
Vul gewoon het IP van je Pi-Hole DNS Server meerdere keren in bij de DHCP DNS Settings als dat wordt geaccepteerd door de Router die je gebruikt!

Sommige apparaten gebruiken namelijk naast de server die je invoert ook nog eens een andere :
- Één van de WAN DNS Servers in het geval van sommige Routers die stiekem dat 2de/3de/4de veldje voor je invullen!
- Android telefoons en dergelijken die dan dus naast je eigen server ook nog eens 8.8.8.8 en 8.8.4.4 aanspreken

[deHakkelaar]

Wat ook vaak voorkomt is dat apparaten via IPv6 route discovery, als je ISP dat support upstream, een DNS server vinden van je ISP en deze gebruikt ipv de IPv4 DNS servers opgegeven via je eigen DHCP.
Ik heb alles IPv6 gerelateerd aan de LAN zijde uitgeschakeld om dit te voorkomen.
IPv4 is nog prima voor thuis gebruik en meer intuitief/traditioneel kwa opzetten dan IPv6 met z'n discovery.
Ook heb ik geen zin om alles dubbel te doen voor zowel IPv4 als IPv6.

[Kopernikus.1979]

nero355 schreef op donderdag 31 januari 2019 @ 19:04:
Ik heb vandaag zitten stoeien met Pi-Hole op twee netwerken tegelijk werkend krijgen en het geheel als volgt opgelost :

Om te beginnen installeer je de VLAN package voor 802.1q support :

code:

apt install vlan

Daarna moet je ervoor zorgen dat de desbetreffende module elke keer wordt ingeladen tijdens het opstarten :

code:

echo "8021q" >> /etc/modules

En om deze gelijk te activeren :

code:

modprobe 8021q

Daarna het netwerk gedeelte in /etc/dhcpcd.conf :

code:

#eth0 VLAN 10 voor DNS in dat VLAN :
interface eth0.10
static ip_address=10.0.0.139/24

Om ervoor te zorgen dat je VLAN interface UP komt tijdens het opstarten heb ik een bestand "vlans" gemaakt in de directory /etc/network/interfaces.d omdat het niet meer de bedoeling is om op de oude manier /etc/network/interfaces direkt aan te passen :

code:

auto eth0.10
iface eth0.10 inet manual
    vlan-raw-device eth0

Dit was de enige redelijk normale nieuwe manier die ik heb gevonden dus als iemand een beter alternatief heeft dat hoort bij de nieuwe dhcpcd.conf manier van configureren dan hoor ik dat graag!

En dan nog het laatste gedeelte, zodat Pi-Hole weet dat er ook op die interface geluisterd moet worden!
In de map /etc/dnsmasq.d/ heb ik een bestand "101-mijn.settings" aangemaakt met daarin alleen het volgende :

code:

interface=eth0.10

Om alles te activeren zonder te rebooten :

code:

systemctl restart networking
pihole restartdns

That's it!


_{Dit is een verkapte "Documentatie voor mezelf" post, maar er zal vast wel ooit iemand hier langskomen die er wat aan heeft!}

@nero355 of iemand die mij kan helpen....

Beste,

Ik heb dus bovenstaande stappen uitgevoerd op mijn RasPi.

Even kort schetsen mijn systeem bestaat uit een Ubiquiti USG + Ubiquiti POE switch daarop heb ik diverse vlans, op de vlan server zit mijn Raspi die zit op een trunk poort die dus native de vlan server heeft en getaged is voor de andere netwerken die ik op mijn Raspi wil.

Alle static interfaces gedefinieerd in de vlans file zijn bereikbaar en verbindbaar vanuit al mijn VLANS, echter... probeer ik de interface op eth0 te bereiken lukt dit niet, ik kan er wel naartoe pings sturen en ze worden beantwoord maar verbinden lukt niet. Als ik omheteven toestel in de server vlan plaats dan kan ik wel verbinden... dus dacht ik firewall probleem, echter... alle block regels heb ik uitgezet, verkeer tussen alle VLANS is mogelijk, trouwens ik kan vanuit elke VLAN pingen en connectie maken met de server vlan. Ook heb ik vandaag voor testen een andere RasPi geinstalleerd met enkel de vlan package zonder Pihole echter identiek zelfde probleem. Heb reeds vanalles geprobeerd echter zonder resultaat. Op Pihole forum staat er al een hele thread over (voor wie mocht interesse hebben): https://discourse.pi-hole...ine-vlan-interfaces/38982

[Chrisje1983]

heeten12 schreef op dinsdag 6 oktober 2020 @ 07:30:
@Chrisje1983

Van Netflix weet ik zeker dat die terugvalt op een bepaalde DNS server. Heb daarvan alle telemetrie geblokkeerd en dan "denkt" hij dat jouw ingestelde DNS server down is. Gelukkig via OPNSense router alle dns verzoeken die niet naar de pihole gaan weer gerouteerd naar de pihole. Daarin zag ik ze na een bepaalde update dus als zijnde verzoeken van de router IPV Netflix device.

Als je een router hebt die dit ondersteunt dan kun je het makkelijk oplossen

Ik gebruik alleen tp-link routers met gargoyle erop. Ik denk dat het tijd word om over te stappen op open-wrt.

The Druid schreef op dinsdag 6 oktober 2020 @ 07:52:
[...]


Klopt, lees dit verhaal maar eens over apparaten die je Pihole bewust negeren.

oke leesvoer!

Toet3r schreef op dinsdag 6 oktober 2020 @ 10:32:
[...]

Wat voor router heb je? Op de een beetje gevanceerde routers kan je doormiddel van NAT regels al het dns verkeer dat niet naar het ip van je pi-hole gaat alsnog daar heen sturen.
Ik heb dit zelf ook gedaan op mij Edgerouter X sfp.

Alle routers zijn tp-links, allen draaien ze gargoyle. Het fijne van gargoyle vond ik altijd het gemak. Helaas kan ik niet heel ver de diepte in gaan. Dit soort dingen gaat niet werken helaas. Open-wrt dus

Quad schreef op dinsdag 6 oktober 2020 @ 15:19:
[...]

Ik had met mijn Huawei P30 idem dat ads nog steeds aangeboden werden. Gelukkig gaan deze via Google DNS, daarom heb ik een blackhole op mijn UniFi firewall gemaakt voor 8.8.8.8 en 8.8.4.4.

[Afbeelding]

Sindsdien loopt via mijn Huawei P30 alles via de Pihole DNS.

Oke die ken ik niet, een hardware firewall! Maar weer een apparaat in mijn netwerk wordt misschien een beetje te, ik houd hem in mijn achterhoofd voor ooit.

nero355 schreef op dinsdag 6 oktober 2020 @ 17:12:
[...]

Jij wordt niet gek : De apparaten zijn gek geworden!


[...]

Dat doen heel veel Google Android gerelateerde apparaten en apps :
- Google Chrome zonder de juiste chrome://flags aanpassingen
- Chromecast ondingen...
- Steeds meer op Google Android gebaseerde telefoons!


[...]

Dat kan inderdaad heel goed!


[...]

Wat ook nog roet in het eten kan gooien is de hele DNS over HTTPS en soortgelijken trend : Sommige apps hebben een eigen DNS Server die ze aanspreken en pas als je die blokkeert stappen ze over op jouw DNS Server!

Wat je ook nog kan doen tegen al deze ellende naast de al gegeven tips :
Vul gewoon het IP van je Pi-Hole DNS Server meerdere keren in bij de DHCP DNS Settings als dat wordt geaccepteerd door de Router die je gebruikt!

Sommige apparaten gebruiken namelijk naast de server die je invoert ook nog eens een andere :
- Één van de WAN DNS Servers in het geval van sommige Routers die stiekem dat 2de/3de/4de veldje voor je invullen!
- Android telefoons en dergelijken die dan dus naast je eigen server ook nog eens 8.8.8.8 en 8.8.4.4 aanspreken

Oke meerdere malen mijn dns server toegevoegd in dnsmasq.conf, ook beide tegelijk (pihole op pi en pihole op docker synology) en inderdaad bij meerdere apparaten zie ik nu dat beide dns servers worden aangeboden, maar op mijn telefoon geen verschil.

Het stomme is, alles wat ik block werkt prima, laptops, android tablets, ios tablet, telefoons etc. Alleen mijn telefoon welke ik toch gebruik als test device valt er net buiten.

Ik ga hier een keer mee verder, open-wrt wordt het volgende projectje. Het blocken van poorten en uitzonderingen maken in gargoyle gaat hem niet worden.

Dank allemaal, ik ben een stuk wijzer.

[icecreamfarmer]

Jazco2nd schreef op maandag 5 oktober 2020 @ 14:03:
@Lizard @Verwijderd thanks voor de info, dat wist ik niet.
@nero355 ik was idd behoorlijk gefrusteerd om dit werkend te krijgen. Afgelopen weekend veel trial & error gedaan. Hier wat bevindingen.

Situatie LAN:

code:

router: 192.168.88.1
LAN network: 192.168.88.0/24
host (Ubuntu 20.04): 192.168.88.10

Situatie Docker netwerk:

code:

networks:
  DNS-network:
    driver: macvlan
    driver_opts:
      parent: eno1
    ipam:
      config:
        - subnet: 192.168.88.0/24
          gateway: 192.168.88.1
          ip_range: 192.168.88.96/29  # gekozen subrange van LAN subnet
          aux_addresses:          # addressen die ik via Docker-Compose zet, dus hier reserveer
            host-macvlan: 192.168.88.96 #  gereserveerd voor de host macvlan (zie uitleg)
            Unbound: 192.168.88.98
            PiHole: 192.168.88.99
            Unifi: 192.168.88.100

PiVPN (Wireguard) geinstalleerd op de host direct, en 1.1.1.1 (Cloudflare) als DNS gekozen. Verder ingesteld dat alleen 192.168.88.0/24 via de tunnel gaat voor clients. Dit werkt. Vervolgens heb ik in de client.conf het DNS aangepast naar die van PiHole. Daarna kan de client helaas geen site meer bereiken.

PiVPN Wireguard config:

code:

::::  Server configuration shown below   ::::
[Interface]
PrivateKey = server_priv
Address = 10.6.0.1/24
ListenPort = 51822
### begin Pixel-phone ###
[Peer]
PublicKey = Pixel-phone_pub
PresharedKey = Pixel-phone_psk
AllowedIPs = 10.6.0.2/32
### end Pixel-Phone ###
=============================================
::::  Client configuration shown below   ::::
[Interface]
PrivateKey = Pixel-phone_priv
Address = 10.6.0.2/24
DNS = 192.168.88.99

[Peer]
PublicKey = server_pub
PresharedKey = Pixel-phone_psk
Endpoint = REDACTED:51822
AllowedIPs = 192.168.88.0/24, ::0/0
===============================

Het probleem ligt volgens mij niet bij PiHole. De client kan namelijk zelfs niet pingen naar het IP van de PiHole. Dus moeten we een oplossing vinden in het bridgen (zoals Nero355 aangaf).

Om dit op te lossen en ook direct ervoor te zorgen dat de host zelf websites kan bezoeken (ik gebruik mijn server ook als workstation), heb ik een macvlan op de host zelf ingesteld, zoals ik eerder hier omschreef.

Nu heb ik ontdekt dat dat onhandig is, je moet dan voor elk docker macvlan IP adres een extra route toevoegen. Dit kan simpeler, door de macvlan aan te passen. Ik snap zelf niet waarom dit werkt btw:

code:

sudo ip link add mynet-shim link eno1 type macvlan mode bridge
sudo ip addr add 192.168.88.96/32 dev mynet-shim
sudo ip link set mynet-shim up
sudo ip route add 192.168.88.96/29 dev mynet-shim

Dit zorgt ervoor dat 1 adres is (namelijk het via Compose gereserveerde IP adres 192.168.88.96) wordt gebridged en daaraan hang je het hele bereik van je docker macvlan (met /32 heb je alleen dat ene IP, met /29 het bereik).

Middels deze truc kan de host nu bij alle macvlan IP adressen inclusief die van PiHole. Ik heb 2 sites (fora) gevonden waar dit ook de uitleg was om PiVPN-Wireguard werkend te krijgen.
Helaas bleek dit geen effect te hebben.

Later ontdekte ik dat de Wireguard client config niet het IP van de PiHole moeten gebruiken bij "DNS=" maar juist het eerste adres in de range van het Wireguard network, in dit geval (zie hierboven)

code:

DNS = 10.6.0.1

Ook dit heeft helaas geen effect.
Ik heb ook dit geprobeerd, een 2e macvlan aanmaken maar dat kan nie:

code:

sudo ip link add mynet-shim link wg0 type macvlan mode bridge

Waarbij wg0 de interface is van Wireguard (gecheckt met ifconfig) maar dit commando krijg ik niet uitgevoerd, kreeg een melding van ongeldig argument ofzo.

Dus flink gepuzzeld maar niks brengt me in de juiste richting. Alleen een upstream/extern DNS zoals 1.1.1.1 werkt.

Ik heb exact hetzelfde met wireguard en gebruik geen docker maar een RPI. Via cloudflare DNS werkt het. Gebruik ik de Pihole dan werkt het niet meer en kan hij met geen website meer verbinden.

[nero355]

Kopernikus.1979 schreef op dinsdag 6 oktober 2020 @ 21:12:
@nero355 of iemand die mij kan helpen....

Uiteraard

Even kort schetsen mijn systeem bestaat uit een Ubiquiti USG + Ubiquiti POE switch daarop heb ik diverse vlans, op de vlan server zit mijn Raspi die zit op een trunk poort die dus native de vlan server heeft en getaged is voor de andere netwerken die ik op mijn Raspi wil.

Alle static interfaces gedefinieerd in de vlans file zijn bereikbaar en verbindbaar vanuit al mijn VLANS, echter... probeer ik de interface op eth0 te bereiken lukt dit niet, ik kan er wel naartoe pings sturen en ze worden beantwoord maar verbinden lukt niet. Als ik omheteven toestel in de server vlan plaats dan kan ik wel verbinden... dus dacht ik firewall probleem, echter... alle block regels heb ik uitgezet, verkeer tussen alle VLANS is mogelijk, trouwens ik kan vanuit elke VLAN pingen en connectie maken met de server vlan. Ook heb ik vandaag voor testen een andere RasPi geinstalleerd met enkel de vlan package zonder Pihole echter identiek zelfde probleem. Heb reeds vanalles geprobeerd echter zonder resultaat. Op Pihole forum staat er al een hele thread over (voor wie mocht interesse hebben): https://discourse.pi-hole...ine-vlan-interfaces/38982

Ik heb dat topic daar effe doorgelezen en ik denk dat je tegen een bug bent aangelopen waar ik ook last van kreeg : Na een reboot gaat er iets mis in de opstart volgorde van het netwerk en de verschillende daemons, waardoor je geen SSH toegang meer hebt onder andere

Wat ik al had gedaan, maar nog steeds de bug had :
- SSH aan het eth0 adres gebind.
- LigHTTPd en daarmee dus de WebGUI van Pi-Hole aan eth0 gebind.

Dat doe je zo voor de WebGUI :

root@unipi:/home/pi# cat /etc/lighttpd/external.conf 
server.bind = "192.168.1.2"
root@unipi:/home/pi#

Daarna effe de service herstarten uiteraard :

systemctl status lighttpd
systemctl restart lighttpd
systemctl status lighttpd

_{Ik check altijd ervoor en erna of alles goed draait voor de zekerheid}

En SSH wilde om de een of ander reden alleen zo goed binden :

root@unipi:/home/pi# cat /etc/ssh/sshd_config | grep ListenAddress
ListenAddress 192.168.1.2:22
root@unipi:/home/pi#

Wat betreft de opstart volgorde moet je dus zien te voorkomen dat SSH eerder opstart dan alle netwerk interfaces :

systemctl edit sshd

Die zo eruit moet zien :

code:

[Unit]
After=network-online.target

Dit wordt apart weggeschreven in :

root@unipi:/home/pi# cat /etc/systemd/system/sshd.service.d/override.conf 
[Unit]
After=network-online.target
root@unipi:/home/pi#

Daarna laat je alles reloaden :

systemctl daemon-reload

Dan enable je nog wat hulp voor de desbetreffende functie :

systemctl is-enabled systemd-networkd-wait-online
systemctl enable systemd-networkd-wait-online

En mocht je het nog nodig hebben :

cat /etc/systemd/system/sshd.service

Zo ziet die van mij eruit :

code:

[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify

[Install]
WantedBy=multi-user.target
Alias=sshd.service

Als je nu de boel een reboot geeft zou alles correct online moeten komen!

_{Disclaimer : Dit is zo gauw effe wat ik me allemaal nog herinner en via het prachtige commando history nog kon terugvinden dus als er iets nog steeds niet werkt dan hoor ik het vanzelf wel...}

[Kopernikus.1979]

Ik heb dat topic daar effe doorgelezen en ik denk dat je tegen een bug bent aangelopen waar ik ook last van kreeg : Na een reboot gaat er iets mis in de opstart volgorde van het netwerk en de verschillende daemons, waardoor je geen SSH toegang meer hebt onder andere

Super, ik ga dat eens testen

Op hetzelfde draadje op het Pi-Hole discourse foum, stelt een forumlid (yubiuser) voor om de Pi-Hole server upstream te gebruiken en in de dnsmasq de opties add-mac en add-subnet toe te voegen (gezien Pi-Hole dit nu zou ondersteunen). Wil je die post eens lezen en ook mijn reply erop? WIl graag eens je mening.

Alvast bedankt!

[nero355]

Kopernikus.1979 schreef op woensdag 7 oktober 2020 @ 16:39:
Super, ik ga dat eens testen

Wat ik nog was vergeten te vermelden : Het grootste gedeelte is dus in feite een OpenSSH bug

Op hetzelfde draadje op het Pi-Hole discourse foum, stelt een forumlid (yubiuser) voor om de Pi-Hole server upstream te gebruiken en in de dnsmasq de opties add-mac en add-subnet toe te voegen (gezien Pi-Hole dit nu zou ondersteunen). Wil je die post eens lezen en ook mijn reply erop? WIl graag eens je mening.

Alvast bedankt!

Heb ik gelezen nadat ik je reactie hier op GoT las, maar ik zou het persoonlijk nooit doen, omdat het verkeer elke keer langs je Firewall moet, terwijl de meeste Routers zoals de USG het al druk genoeg hebben en voor de meeste dingen zwaar afhankelijk zijn van allerlei offload chips

Heb je echter iets als een DIY pfSense/SonicWall/enz. doosje draaien op een x86-64 systeem of hele flinke ARM SoC dan kan het een optie zijn...

Zolang je trouwens elke daemon/service op de juiste manieren op de correcte interfaces bind hoef je ook weinig te firewallen met IPTables dus bespaar je op je Pi-Hole systeem ook een stukje resources

[Kopernikus.1979]

Als je nu de boel een reboot geeft zou alles correct online moeten komen!

Helaas.... nog steeds zelfde probleem.
En nu ik erover denk kan het niet hetzelfde probleem zijn.
Gezien als ik met mijn pc/laptop mij verbind in dezelfde native vlan als waar de RasPi opzit ik wel een SSH verbinding kan maken met eth0. Doe ik dit uit een andere VLAN lukt dit niet, alhoewel ik er pings naartoe kan sturen en ze beantwoord worden. Ook is vanuit elke VLAN inclusief de native vlan waarop de RasPi de statisch gedefinieerde adressen bereikbaar en connecteerbaar. Wat zoals ik ook reeds geschreven heb mij doet denken aan een firewall issue, nochtans zijn er geen block rules actief en kan ik vanuit omheteven welke vlan verbinden met devices die zich bevinden in de native vlan van de Pi-Hole.

[nero355]

Kopernikus.1979 schreef op woensdag 7 oktober 2020 @ 19:07:
Helaas.... nog steeds zelfde probleem.

Is het een optie om helemaal overnieuw te beginnen

Ik denk echt dat je ergens een config fout hebt gemaakt...

Hoe zien je Profiles voor de Switchpoorten eruit ?
Hoe zijn de VLAN's aangemaakt in je UniFi Controller ?
Niet stiekem IPTables of UFW of zo die draait en iets blokkeert ?!

[Kopernikus.1979]

nero355 schreef op woensdag 7 oktober 2020 @ 19:16:
[...]

Is het een optie om helemaal overnieuw te beginnen

Ik denk echt dat je ergens een config fout hebt gemaakt...

Hoe zien je Profiles voor de Switchpoorten eruit ?
Hoe zijn de VLAN's aangemaakt in je UniFi Controller ?
Niet stiekem IPTables of UFW of zo die draait en iets blokkeert ?!

Heb ik ook gedaan, nieuwe sd kaartje ingestopt en fresh install.

VLANS:



VLAN Profile:



Firewall LAN IN:



In de config.gateway.json staat momenteel enkel MDNS repeater gedefinieerd en en static host mappings verder niets.

Als er IPTABLES staan zouden deze dan niet verdwijnen naar reboot of provisioning?

[ed1703]

Kopernikus.1979 schreef op woensdag 7 oktober 2020 @ 19:23:
[...]

Heb ik ook gedaan, nieuwe sd kaartje ingestopt en fresh install.

Al getest of je vanaf de USG kunt SSH' en naar je PI?

Als er IPTABLES staan zouden deze dan niet verdwijnen naar reboot of provisioning?

Firewall USG = IPtables.

Kopernikus.1979 schreef op woensdag 7 oktober 2020 @ 19:07:
[...]

Helaas.... nog steeds zelfde probleem.
En nu ik erover denk kan het niet hetzelfde probleem zijn.
Gezien als ik met mijn pc/laptop mij verbind in dezelfde native vlan als waar de RasPi opzit ik wel een SSH verbinding kan maken met eth0. Doe ik dit uit een andere VLAN lukt dit niet, alhoewel ik er pings naartoe kan sturen en ze beantwoord worden.

Als de rest van je services wel werken is dat bijna 100% garantie een firewall zaak.
Geen andere devices in dat netwerk met SSH? Dat sluit nogal wat uit.

[ Voor 53% gewijzigd door ed1703 op 07-10-2020 19:48 ]

[deHakkelaar]

nero355 schreef op woensdag 7 oktober 2020 @ 15:52:
Ik heb dat topic daar effe doorgelezen en ik denk dat je tegen een bug bent aangelopen waar ik ook last van kreeg : Na een reboot gaat er iets mis in de opstart volgorde van het netwerk en de verschillende daemons, waardoor je geen SSH toegang meer hebt onder andere

Wat ik al had gedaan, maar nog steeds de bug had :
- SSH aan het eth0 adres gebind.
- LigHTTPd en daarmee dus de WebGUI van Pi-Hole aan eth0 gebind.

Één kanttekening hierover.
Als je de sshd of lighttpd daemon bind aan een IP kun je juist problemen ondervinden omdat een interface nog niet UP is.
Laat je dit gewoon default, zal sshd en lighttpd op alle IP's luisteren/binden ("Local Address" 0.0.0.0 in onderstaande netstat).
En is dan niet afhankelijk ofdat een interface UP of DOWN is.
Interfaces met IP's kunnen dan komen en gaan.

code:

pi@ph5:~ $ sudo netstat -4nltp | grep 'Proto\|lighttpd\|sshd'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      484/lighttpd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      465/sshd

[Kopernikus.1979]

[quote]ed1703 schreef op woensdag 7 oktober 2020 @ 19:32:
[Al getest of je vanaf de USG kunt SSH' en naar je PI?]


Ja, net geprobeerd en dat lukt zonder problemen.

Momenteel als test heb ik nu een RasPi draaien enkel met de laatste Pi OS Lite daarop de vlan package geïnstalleerd en de 8021q module geactiveerd, dan de vlans gedefinieerd.

En zoals gewoonte.. alle statische vlan adressen op de RasPi zijn bereikbaar vanuit elke VLAN, enkel eth0 is enkel connecteerbaar (kan niet zegge niet bereikbaar want ping werkt wel) als men in dezelfde vlan zit.

Zou er iets mis kunnen zijn met mijn USG?

[ Voor 53% gewijzigd door Kopernikus.1979 op 07-10-2020 19:58 ]

[ed1703]

Kopernikus.1979 schreef op woensdag 7 oktober 2020 @ 19:48:
[quote]ed1703 schreef op woensdag 7 oktober 2020 @ 19:32:
[...]

Al getest of je vanaf de USG kunt SSH' en naar je PI?

Ja, net geprobeerd en dat lukt zonder problemen.

Momenteel als test heb ik nu een RasPi draaien enkel met de laatste Pi OS Lite daarop de vlan package geïnstalleerd en de 8021q module geactiveerd, dan de vlans gedefinieerd.

Maar wacht even? Je hebt een Extra VLAN aangemaakt?
En je probeert vanuit dat Extra VLAN te connecten op het Native VLAN?

Dat kan niet. Je PI kan het verkeer nooit terugsturen via je USG omdat hij zelf al in dat Extra VLAN zit.

Dus SSH gebruiken op het Extra VLAN, niet op het Native VLAN..
Hetzelfde trouwens voor andere services.. dat is ook direct het nadeel van extra vlan-interfaces.

En zoals gewoonte.. alle statische vlan adressen op de RasPi zijn bereikbaar vanuit elke VLAN, enkel eth0 is enkel connecteerbaar (kan niet zegge niet bereikbaar want ping werkt wel) als men in dezelfde vlan zit.

Dat klopt dus ook. Want hoe moet je PI verkeer van VLAN50 terugsturen naar het VLAN waar jij in zit als hij zelf ook een poortje actief heeft in dat VLAN??

Voorbeeld: PI heeft 2 vlans:

10.0.2.10 native
10.0.3.10

Jij zit op 10.0.3.11
Je probeert te connecten op 10.0.2.10, de PI ziet verkeer komen vanaf 10.0.3.11, hoe denk je dat hij het verkeer gaat terugsturen?

[ Voor 30% gewijzigd door ed1703 op 07-10-2020 20:09 ]

[deHakkelaar]

Kopernikus.1979 schreef op woensdag 7 oktober 2020 @ 19:23:
Heb ik ook gedaan, nieuwe sd kaartje ingestopt en fresh install.

VLANS:
.
.
.

Wat is onderstaande "Native" tag ? Heb jij deze zelf aangemaakt ?
Moet die ook niet ge-tagged zijn ?
Geen idee

[Kopernikus.1979]

ed1703 schreef op woensdag 7 oktober 2020 @ 19:59:
[...]

Maar wacht even? Je hebt een Extra VLAN aangemaakt?
En je probeert vanuit dat Extra VLAN te connecten op het Native VLAN?

Dat kan niet. Je PI kan het verkeer nooit terugsturen via je USG omdat hij zelf al in dat Extra VLAN zit.

Dus SSH gebruiken op het Extra VLAN, niet op het Native VLAN..

Dit is het poortprofiel dat actief is voor de RasPi:



Zoals je ziet is de native poort VLAN50 (Server) dus de RasPi krijgt op zijn eth0 aan adres uit die pool, daarnaast zijn de andere VLAN's (10/20/30) tagged en deze zijn dus bereikbaar overal, enkel dus VLAN50 die de RasPï als native ziet niet tenzij men de pc zelf verbind in VLAN50, maar ping lukt dus wel en dat snap ik niet...

[Kopernikus.1979]

deHakkelaar schreef op woensdag 7 oktober 2020 @ 20:03:
[...]


Wat is onderstaande "Native" tag ? Heb jij deze zelf aangemaakt ?
Moet die ook niet ge-tagged zijn ?
Geen idee

[Afbeelding]

Nee, heb ik niet zelfgemaakt dat is de eth1 van de USG dus untaged, daar zit enkel de USG op (omdat er tot op heden nog altijd geen mogelijkheid is deze in management te plaatsen). Ik wil deze gerust een taggen om te zien als dat een verschil maakt...

[deHakkelaar]

Kopernikus.1979 schreef op woensdag 7 oktober 2020 @ 20:05:
maar ping lukt dus wel en dat snap ik niet...

Ping is het ICMP protocol welke door elk willekeurig apparaat tussen SOURCE en DESTINATION kan worden beantwoord.
Je router kan bv deze ping beantwoorden ipv de Pi-hole host.
Ping is geen garantie dat de ping reply daadwerkelijk van het doel apparaat komt.

[Kopernikus.1979]

deHakkelaar schreef op woensdag 7 oktober 2020 @ 20:10:
[...]


Ping is het ICMP protocol welke door elk willekeurig apparaat tussen SOURCE en DESTINATION kan worden beantwoord.
Je router kan bv deze ping beantwoorden ipv de Pi-hole host.
Ping is geen garantie dat de ping reply daadwerkelijk van het doel apparaat komt.

Correct... had beter moeten opletten tijdens de CCNA...

[ed1703]

Kopernikus.1979 schreef op woensdag 7 oktober 2020 @ 20:05:
[...]


Dit is het poortprofiel dat actief is voor de RasPi:

[Afbeelding]

Zoals je ziet is de native poort VLAN50 (Server) dus de RasPi krijgt op zijn eth0 aan adres uit die pool, daarnaast zijn de andere VLAN's (10/20/30) tagged en deze zijn dus bereikbaar overal, enkel dus VLAN50 die de RasPï als native ziet niet tenzij men de pc zelf verbind in VLAN50, maar ping lukt dus wel en dat snap ik niet...

Ik herhaal mijn aangepaste post even:

ed1703 schreef op woensdag 7 oktober 2020 @ 19:59:

Dat klopt dus ook. Want hoe moet je PI verkeer van VLAN50 terugsturen naar het VLAN waar jij in zit als hij zelf ook een poortje actief heeft in dat VLAN??

Voorbeeld: PI heeft 2 vlans:

10.0.2.10 native
10.0.3.10

Jij zit op 10.0.3.11
Je probeert te connecten op 10.0.2.10, de PI ziet verkeer komen vanaf 10.0.3.11, hoe denk je dat hij het verkeer gaat terugsturen?

Multi-homed is voor routing met bepaalde services een draak van een oplossing. Overigens werkt het voor Pi-Hole prima.

[ Voor 4% gewijzigd door ed1703 op 07-10-2020 20:15 ]

[deHakkelaar]

Je zou tcpdump op Pi-hole kunnen gebruiken om te zien ofdat de ping daadwerkelijk aankomt:

code:

sudo tcpdump -lnqtX -i eth0 icmp

[Kopernikus.1979]

ed1703 schreef op woensdag 7 oktober 2020 @ 20:13:
[...]


Ik herhaal mijn aangepaste post even:


[...]

Multi-homed is voor routing met bepaalde services een draak van een oplossing. Overigens werkt het voor Pi-Hole prima.

Wow... dat zou het inderdaad wel eens kunnen zijn, raar dat er niemand anders hier last van heeft?
Of verbind iedereen zijn eth0 op de pihole met hun native netwerk van de router?
Welke oplossing stel je voor? (indien die er is...)

[Kopernikus.1979]

deHakkelaar schreef op woensdag 7 oktober 2020 @ 20:13:
Je zou tcpdump op Pi-hole kunnen gebruiken om te zien ofdat de ping daadwerkelijk aankomt:

code:

sudo tcpdump -lnqtX -i eth0 icmp

Net de tcpdump uitgevoerd op de RasPi en de ping uitgevoerd naar eth0 vanuit VLAN10 deze komt wel degelijk aan.

[ed1703]

Kopernikus.1979 schreef op woensdag 7 oktober 2020 @ 20:20:
[...]


Wow... dat zou het inderdaad wel eens kunnen zijn, raar dat er niemand anders hier last van heeft?
Of verbind iedereen zijn eth0 op de pihole met hun native netwerk van de router?
Welke oplossing stel je voor? (indien die er is...)

Goed.. niet echt het topic waar dit over moet gaan, maar toch:
RPI4, heb de laatste release vanaf raspberrypi.org op SD'tje geplempt.

Geinstalleerd: vlan package

ETH0: Server vlan Native: Op DHCP
ETH0.13 Client vlan: Static.

Aangemaakt:

pi@raspberrypi:~ $ cat /etc/network/interfaces.d/vlans
auto eth0.13
iface eth0.13 inet manual
vlan-raw-device eth0

Aangepast: /etc/dhcpcd.conf

interface eth0.13
static ip_address=10.0.3.213/24
static routers=10.0.3.254
static domain_name_servers=10.0.2.53

ip route table:

pi@raspberrypi:~ $ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.2.254 0.0.0.0 UG 202 0 0 eth0
0.0.0.0 10.0.3.254 0.0.0.0 UG 204 0 0 eth0.13
10.0.2.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
10.0.3.0 0.0.0.0 255.255.255.0 U 204 0 0 eth0.13

Putty sessie vanaf 10.0.3.5 werkt:

pi@raspberrypi:~ $ netstat -tn
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.0.2.8:22 10.0.2.30:57038 ESTABLISHED
tcp 0 240 10.0.2.8:22 10.0.3.5:50024 ESTABLISHED

Ik had dus GEEN GELIJK Maar ergens mis je een stap.
Loop alles na.
Succes.

Ik mis hier dus zaken (routes (al zou dat niet mogen uitmaken), check je dhcpcd.conf en je had het vlan package verwijderd, de rest is bij mij default): https://discourse.pi-hole...e-vlan-interfaces/38982/6
Er staan bij mij geen iptables-filters tussen het vlan van eth0 en eth0.13.
Geen firewall op de clients.

[ Voor 5% gewijzigd door ed1703 op 08-10-2020 13:52 ]

[nero355]

Kopernikus.1979 schreef op woensdag 7 oktober 2020 @ 20:20:
Wow... dat zou het inderdaad wel eens kunnen zijn, raar dat er niemand anders hier last van heeft?
Of verbind iedereen zijn eth0 op de pihole met hun native netwerk van de router?
Welke oplossing stel je voor? (indien die er is...)

In mijn geval is dat dus zo

VLAN 1 = Management VLAN = Aan eth0 gebonden als Native VLAN en dus Untagged.
VLAN 10 = Regulier VLAN = Aan eth0.10 gebonden als Tagged VLAN.
En alle andere VLAN's ook...

deHakkelaar schreef op woensdag 7 oktober 2020 @ 19:42:
Één kanttekening hierover.
Als je de sshd of lighttpd daemon bind aan een IP kun je juist problemen ondervinden omdat een interface nog niet UP is.
Laat je dit gewoon default, zal sshd en lighttpd op alle IP's luisteren/binden ("Local Address" 0.0.0.0 in onderstaande netstat).
En is dan niet afhankelijk ofdat een interface UP of DOWN is.
Interfaces met IP's kunnen dan komen en gaan.

code:

pi@ph5:~ $ sudo netstat -4nltp | grep 'Proto\|lighttpd\|sshd'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      484/lighttpd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      465/sshd

Indien dat dus gebeurt is de service/daemon niet goed geconfigureerd en heb ik de oplossing voor de OpenSSH bug al gepost

ed1703 schreef op woensdag 7 oktober 2020 @ 19:32:
Al getest of je vanaf de USG kunt SSH' en naar je PI?

Dat is inderdaad ook wel een leuke, want de USG moet tenslotte alles kunnen bereiken, tenzij VLAN Only netwerk

Firewall USG = IPtables.

Ik bedoelde die van de Pi zelf, maar zo te zien zou het probleem ergens anders kunnen zitten

De Firewall van de USG gebruik ik zo goed als niet dus daar kan ik effe niks over zeggen...

ed1703 schreef op woensdag 7 oktober 2020 @ 20:13:
Multi-homed is voor routing met bepaalde services een draak van een oplossing. Overigens werkt het voor Pi-Hole prima.

Wat vind jij daar zo erg aan dan

Ik heb zat grote professionele netwerken gezien die een dergelijke opzet gebruiken op bepaalde servers...

[ Voor 8% gewijzigd door nero355 op 08-10-2020 17:00 ]

[ed1703]

nero355 schreef op donderdag 8 oktober 2020 @ 16:58:
[...]

Wat vind jij daar zo erg aan dan

Ik heb zat grote professionele netwerken gezien die een dergelijke opzet gebruiken op bepaalde servers...

Het is een verschrikkelijke oplossing.

1. Security. Voor thuis gaat dit nog wel. Doe dit bij een bedrijf met een Datacenter met 1200 vlans en je firewall gaat een enorme zooi worden.
2. Hetzelfde device meerdere keren in de ARP / Mac address table. Ja, dat kan je allemaal oplossen met mac-vlan of een extra NIC (dat is voor mij nog de minst slechte oplossing), maar nee, ik ben er geen fan van en al helemaal niet in omgevingen met duizenden vm's en servers.
Ik ben zelf verantwoordelijk voor een IP Office met meer dan 8k aan vlan's binnen de overheid en je krijgt hoofdpijn van dat soort "oplossingen". Daarom zijn VLANS mede daardoor ook niet veilig.
Zet ip forwarding aan en hoppa.. we hebben een lek.

Maar we gaan wel erg offtopic zo.

[nero355]

ed1703 schreef op donderdag 8 oktober 2020 @ 17:28:
Het is een verschrikkelijke oplossing.

Nou...

1. Security. Voor thuis gaat dit nog wel. Doe dit bij een bedrijf met een Datacenter met 1200 vlans en je firewall gaat een enorme zooi worden.

Je zal het toch moeten firewallen op de een of andere manier dus die regels komen er toch wel...

2. Hetzelfde device meerdere keren in de ARP / Mac address table.

Dat is wel minder inderdaad zonder

Ja, dat kan je allemaal oplossen met mac-vlan of een of meerdere extra NIC's (dat is voor mij nog de minst slechte oplossing), maar nee, ik ben er geen fan van en al helemaal niet in omgevingen met duizenden vm's en servers.

Ik ben zelf verantwoordelijk voor een IP Office met meer dan 8k aan vlan's binnen de overheid en je krijgt hoofdpijn van dat soort "oplossingen". Daarom zijn VLANS mede daardoor ook niet veilig.
Zet ip forwarding aan en hoppa.. we hebben een lek.

Dan hebben ze bij de afdeling van de overheid waar ik heb gezeten ook een zooitje ervan gemaakt

Maar we gaan wel erg offtopic zo.

Mwa, een voordelen/nadelen discussie is opzich niet verkeerd

[Raven]

ed1703 schreef op donderdag 8 oktober 2020 @ 17:28:
met 1200 vlans en je firewall gaat een enorme zooi worden.

offtopic:
In iptables opvolger nftables kun je een hele boel combineren in één regel, bijv. meerdere VLAN-interfaces in dezelfde regel zodat je niet voor elke VLAN-interface afzonderlijk regels moet schrijven. Of mocht elk VLAN net iets andere regels nodig hebben, dan kun je voor de overzichtelijkheid per VLAN een apart bestand met regels aanmaken en includen: https://wiki.nftables.org...Scripting#Including_files

ed1703 schreef op donderdag 8 oktober 2020 @ 17:28:
Daarom zijn VLANS mede daardoor ook niet veilig.
Zet ip forwarding aan en hoppa.. we hebben een lek.

offtopic:
* Raven zet default policy altijd op drop

[ Voor 18% gewijzigd door Raven op 08-10-2020 18:28 ]

[ed1703]

Raven schreef op donderdag 8 oktober 2020 @ 18:26:
[...]

offtopic:
In iptables opvolger nftables kun je een hele boel combineren in één regel, bijv. meerdere VLAN-interfaces in dezelfde regel zodat je niet voor elke VLAN-interface afzonderlijk regels moet schrijven. Of mocht elk VLAN net iets andere regels nodig hebben, dan kun je voor de overzichtelijkheid per VLAN een apart bestand met regels aanmaken en includen: https://wiki.nftables.org...Scripting#Including_files

Tja, @nero355 vroeg waarom. Dit ging mij ook niet om een thuiswerkje, daar werkt het prima.
Maar beroepsmatig keur ik het met zoveel vlans en ook nog eens 10+ VRF's af.
Je schiet gaten in je beveiliging. Daarom doen we dit ook liever niet meer.

[...]

offtopic:
* Raven zet default policy altijd op drop

Ik op elke linux/bsd-variant ook

[Kopernikus.1979]

@nero355
@ed1703

Help... nog steeds zelfde probleem (enkel verbinden indien verbonden zelfde VLAN)
Deze keer fresh install, alle updates gedaan + vlan package.
Poort aangesloten op Raspi --> Native LAN (VLAN1) aan eth0 + VLAN 10/20/30 tagged

cat /etc/network/interfaces.d/vlans

code:

auto eth0.10
iface eth0.10 inet manual
  vlan-raw-device eth0

auto eth0.20
iface eth0.20 inet manual
  vlan-raw-device eth0

auto eth0.30
iface eth0.30 inet manual
  vlan-raw-device eth0

cat /etc/dhcpcd.conf

code:

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0

interface eth0.10
static ip_address=10.10.10.5/24
static routers=10.10.10.1
static domain_name_servers=1.1.1.1

interface eth0.20
static ip_address=10.10.20.5/24
static routers=10.10.20.1
static domain_name_servers=1.1.1.1

interface eth0.30
static ip_address=10.10.30.5/24
static routers=10.10.30.1
static domain_name_servers=1.1.1.1

ip route table:

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.1.1       0.0.0.0         UG    202    0        0 eth0
0.0.0.0         10.10.10.1      0.0.0.0         UG    204    0        0 eth0.10
0.0.0.0         10.10.20.1      0.0.0.0         UG    205    0        0 eth0.20
0.0.0.0         10.10.30.1      0.0.0.0         UG    206    0        0 eth0.30
10.10.1.0       0.0.0.0         255.255.255.0   U     202    0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     204    0        0 eth0.10
10.10.20.0      0.0.0.0         255.255.255.0   U     205    0        0 eth0.20
10.10.30.0      0.0.0.0         255.255.255.0   U     206    0        0 eth0.30

[deHakkelaar]

nero355 schreef op donderdag 8 oktober 2020 @ 16:58:
Indien dat dus gebeurt is de service/daemon niet goed geconfigureerd en heb ik de oplossing voor de OpenSSH bug al gepost

Ik heb nog nooit meegemaakt dat de sshd daemon verkeerd was geconfigureerd out of the box.
Dan praat ik uit ervaring met Debian, RedHat, CentOS, Fedora en SUSE.
sshd is in mijn ervaring altijd geconfigureerd om default te binden met alle IP's 0.0.0.0 zodat je niet afhankelijk bent ofdat interfaces UP of DOWN zijn.
Binden van sshd met een specifiek IP zoals jij aangeeft maakt sshd extra afhankelijk van je interface status.
Ik zie jou oplossing niet echt als een fix maar eerder een verergering door die extra afhankelijkheid.

ed1703 schreef op donderdag 8 oktober 2020 @ 17:28:
maar nee, ik ben er geen fan van en al helemaal niet in omgevingen met duizenden vm's en servers.

Hoe doe je dat dan met die hypervisors en vlan's ?
Daar tag je die hypervisor toch ook in verschillende vlan's.
Of douw je die bak vol met NIC's voor ieder vlan

Kopernikus.1979 schreef op donderdag 8 oktober 2020 @ 20:47:
Help... nog steeds zelfde probleem (enkel verbinden indien verbonden zelfde VLAN)

Dat is toch logisch lijkt mij ?
Je maakt toch niet voor niets zoveel aliased IP's aan zodat alles lekker geissoleerd in eigen vlan blijft.
Als je een apparaat uit vlan1 wilt laten praten met een apparaat uit vlan2 zal je weer terug moeten vallen op routeren of port-forwarding/NATten.

[ Voor 5% gewijzigd door deHakkelaar op 08-10-2020 21:18 ]

[ed1703]

deHakkelaar schreef op donderdag 8 oktober 2020 @ 21:16:
[...]

Hoe doe je dat dan met die hypervisors en vlan's ?
Daar tag je die hypervisor toch ook in verschillende vlan's.
Of douw je die bak vol met NIC's voor ieder vlan

Onze vsphere dozen hebben inderdaad meerdere nics met de vmkernel in een apart vlan en vrf.
De vms hebben alleen tagging en dus maar 1 poortje per vm in een vlan, dus dat vergelijk gaat niet echt op? De hypervisor is dus ook niet bereikbaar via die vlans, want die heeft geen vmkernelpoort. VM’s die binnen een ander VRF vallen, hosten we op een fysiek andere systemen.

Kopernikus.1979 schreef op donderdag 8 oktober 2020 @ 20:47:
@nero355
@ed1703

Help... nog steeds zelfde probleem (enkel verbinden indien verbonden zelfde VLAN)
Deze keer fresh install, alle updates gedaan + vlan package.
Poort aangesloten op Raspi --> Native LAN (VLAN1) aan eth0 + VLAN 10/20/30 tagged

- Welke systemen heb je nog meer in Vlan1? Kun je daar wel bij?
- doe een ifconfig eth0.10 down, werkt vlan1 vanaf je client dan wel?

[ Voor 27% gewijzigd door ed1703 op 08-10-2020 22:18 ]

[nero355]

Kopernikus.1979 schreef op donderdag 8 oktober 2020 @ 20:47:
cat /etc/dhcpcd.conf

code:

interface eth0.10
static ip_address=10.10.10.5/24
static routers=10.10.10.1
static domain_name_servers=1.1.1.1

interface eth0.20
static ip_address=10.10.20.5/24
static routers=10.10.20.1
static domain_name_servers=1.1.1.1

interface eth0.30
static ip_address=10.10.30.5/24
static routers=10.10.30.1
static domain_name_servers=1.1.1.1

ip route table:

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.1.1       0.0.0.0         UG    202    0        0 eth0
0.0.0.0         10.10.10.1      0.0.0.0         UG    204    0        0 eth0.10
0.0.0.0         10.10.20.1      0.0.0.0         UG    205    0        0 eth0.20
0.0.0.0         10.10.30.1      0.0.0.0         UG    206    0        0 eth0.30
10.10.1.0       0.0.0.0         255.255.255.0   U     202    0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     204    0        0 eth0.10
10.10.20.0      0.0.0.0         255.255.255.0   U     205    0        0 eth0.20
10.10.30.0      0.0.0.0         255.255.255.0   U     206    0        0 eth0.30

Dat is niet zo handig wat je nu hebt gedaan : Het systeem heeft meerdere Gateways met dezelfde Metric en daardoor is er dus geen Primary/Beste Route naar buiten (0.0.0.0) toe!
/EDIT :
Maar dan nog... Niet handig!

Ik gebruik alleen een Gateway in het Management VLAN en de rest is "Gateway-loos"

Verder moet je effe goed erbij zetten wat je nou allemaal hebt getest, want in principe moet je resultaat het volgende zijn :
- Elke Interface in elk VLAN bereikbaar via Ping of DNS door een Client in dat VLAN.
- SSH en de WebGUI alleen in en via het Management VLAN bereikbaar.
- Een werkende Internet verbinding voor de Raspberry Pi via het Management VLAN.

Dus ik weet niet wat er nu wel of niet werkt

deHakkelaar schreef op donderdag 8 oktober 2020 @ 21:16:
Ik heb nog nooit meegemaakt dat de sshd daemon verkeerd was geconfigureerd out of the box.
Dan praat ik uit ervaring met Debian, RedHat, CentOS, Fedora en SUSE.
sshd is in mijn ervaring altijd geconfigureerd om default te binden met alle IP's 0.0.0.0 zodat je niet afhankelijk bent ofdat interfaces UP of DOWN zijn.
Binden van sshd met een specifiek IP zoals jij aangeeft maakt sshd extra afhankelijk van je interface status.
Ik zie jou oplossing niet echt als een fix maar eerder een verergering door die extra afhankelijkheid.

Tijdens mijn zoektocht werd er toch echt aangegeven dat het iets is wat men in de toekomst gaat fixen onder RaspBian of Raspberry Pi OS of hoe dat ook tegenwoordig heet, want ook als je OpenSSHd aan een bepaald IP of Interface bind moet die correct opstarten!

[ed1703]

nero355 schreef op vrijdag 9 oktober 2020 @ 19:42:
[...]

Dat is niet zo handig wat je nu hebt gedaan : Het systeem heeft meerdere Gateways met dezelfde Metric en daardoor is er dus geen Primary/Beste Route naar buiten (0.0.0.0) toe!

???

Waar heb je het over?

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.1.1       0.0.0.0         UG    202    0        0 eth0
0.0.0.0         10.10.10.1      0.0.0.0         UG    204    0        0 eth0.10
0.0.0.0         10.10.20.1      0.0.0.0         UG    205    0        0 eth0.20
0.0.0.0         10.10.30.1      0.0.0.0         UG    206    0        0 eth0.30
10.10.1.0       0.0.0.0         255.255.255.0   U     202    0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     204    0        0 eth0.10
10.10.20.0      0.0.0.0         255.255.255.0   U     205    0        0 eth0.20
10.10.30.0      0.0.0.0         255.255.255.0   U     206    0        0 eth0.30

Met verschillende metrics werkt prima, die staan er ook op.

[nero355]

ed1703 schreef op vrijdag 9 oktober 2020 @ 19:45:
???

Waar heb je het over?

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.1.1       0.0.0.0         UG    202    0        0 eth0
0.0.0.0         10.10.10.1      0.0.0.0         UG    204    0        0 eth0.10
0.0.0.0         10.10.20.1      0.0.0.0         UG    205    0        0 eth0.20
0.0.0.0         10.10.30.1      0.0.0.0         UG    206    0        0 eth0.30
10.10.1.0       0.0.0.0         255.255.255.0   U     202    0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     204    0        0 eth0.10
10.10.20.0      0.0.0.0         255.255.255.0   U     205    0        0 eth0.20
10.10.30.0      0.0.0.0         255.255.255.0   U     206    0        0 eth0.30

Met verschillende metrics werkt prima, die staan er ook op.

Verkeerd gekeken! My bad... Iets met moe en zo...

[Kopernikus.1979]

@nero355
@deHakkelaar
@ed1703

Goedemorgen :-)

Alles werkt

Het lag aan mijn Ubiquiti Switch grrr
Had eerst USG reset gedaan, zelfde probleem.
Dan switch reset dan terug geprovisioned (met zelfde settings als voordien)... en alles werkt!
Dus nu heb ik het zoals ik het wil RasPi --> VLAN50 (Server VLAN) untagged en al mijn andere VLANS tagged

Gezien ik nu toch verse start genomen heb, graag jullie advies over de topology die ik gebruik:

VLAN1 (native LAN1 van mijn netwerk)
--> hier zit enkel mijn Ubiquiti USG op (gezien er tot op heden geen mogelijkheid is om de USG in management te plaatsen) gebruikt de DNS van de USG

VLAN10 (trusted)
--> voor desktop/laptop/smartphones gebruikt Pi-Hole als DNS

VLAN20 (IoT)
--> voor printers, smart devices, enz.. en gebruikt zeker Pi-Hole als DNS

VLAN40 (Camera)
--> volledig geisoleerde VLAN voor mijn camera's als DNS ook de USG

VLAN50 (Servers)
--> voor mijn NAS/Pi-Hole en Ubiquiti Cloud key gen 2 (controller + NVR) gebruikt ook PiHole als DNS

VLAN90 (gasten)
--> voor mijn gasten met captive portal en ook met Pihole als DNS

VLAN100 (management)
--> voor mijn switches en AP --> gebruikt USG als DNS

Enige opmerkingen of dingen die ik beter kan doen?

[Rozz]

vraagje, ik draai al geruime tijd pi-hole naar alle tevredenheid maar hoe ga ik te werk als ik de ads op volgende website wil blokken?!?

CoinCodex

Ik heb de diverse linkaddressen in de blacklist gezet en alles geflushed, maar nog steeds komen ze door.

[ Voor 22% gewijzigd door Rozz op 10-10-2020 13:03 ]

[Webgnome]

Rozz schreef op zaterdag 10 oktober 2020 @ 13:02:
vraagje, ik draai al geruime tijd pi-hole naar alle tevredenheid maar hoe ga ik te werk als ik de ads op volgende website wil blokken?!?

CoinCodex

Ik zie geen ads? Kijk in de querylog en blokkeer die je niet wil.

[Rozz]

das juist het probleem, ik zie overal ads, maar ze komen niet overeen in mn query....

Als ik linkadres kopieer en dat invul in de blacklist komen ze nog steeds door, en dit adres zie ik dan ook niet in mn query.

Dus mijn vraag, hoe ga ik dan te werk om uit te zoeken welke adressen het zijn?

[ Voor 61% gewijzigd door Rozz op 10-10-2020 13:14 . Reden: typo en meer ]

[Webgnome]

1. Weet je zeker dat het device pihole gebruikt?
2. Gaat het toevallig over doh?
3. Zo ja is pihole zo ingesteld dat die dat ook doet?
4. sluit je browser eens en doe een flush dns

[ed1703]

Kopernikus.1979 schreef op zaterdag 10 oktober 2020 @ 11:45:

Alles werkt

Mooi

VLAN1 (native LAN1 van mijn netwerk)
--> hier zit enkel mijn Ubiquiti USG op (gezien er tot op heden geen mogelijkheid is om de USG in management te plaatsen) gebruikt de DNS van de USG

Als je USG defect gaat is dit dus je netwerk waarop je met een wat dommere router nog wel connectiviteit kunt krijgen.

VLAN10 (trusted)
--> voor desktop/laptop/smartphones gebruikt Pi-Hole als DNS

VLAN20 (IoT)
--> voor printers, smart devices, enz.. en gebruikt zeker Pi-Hole als DNS

VLAN40 (Camera)
--> volledig geisoleerde VLAN voor mijn camera's als DNS ook de USG

VLAN50 (Servers)
--> voor mijn NAS/Pi-Hole en Ubiquiti Cloud key gen 2 (controller + NVR) gebruikt ook PiHole als DNS

VLAN90 (gasten)
--> voor mijn gasten met captive portal en ook met Pihole als DNS

VLAN100 (management)
--> voor mijn switches en AP --> gebruikt USG als DNS

Enige opmerkingen of dingen die ik beter kan doen?

Dit is misschien meer iets voor het ubiquiti topic.
- Denk na waar wat mee mag communiceren. Ben je daar uit en tevreden mee dan ooit een keer als laatste regel een drop naar een RFC1918-group is te overwegen.
- Een vlan is een vlan, weinig bijzonders aan. Gastenlan ook echt via de controller inrichten als guest-vlan.
- Een IOT vlan is handig als het niet naar trusted kan, maar vanuit trusted wel naar het IOT-vlan.
- Voor MDNS smartphone/iot dien je het eea te configureren op de USG mbt een stabiele MDNS-config. De reflector is dat meestal niet, de repeater wel. ==> config.gateway.json.
- Het is te overwegen je CK in hetzelfde VLAN te hangen als je switches/aps, vooral als je ooit nog een flex mini als desktopswitchje gaat gebruiken, voorkomt dat wat gedoe.

- mogelijk heeft @nero355 nog wat aanvullingen.

[Rozz]

@Webgnome pihole wordt gebruikt omdat ik al mn clients zie en cloudflared is ook ingesteld via handleiding Pihole Doc DOH

[ Voor 3% gewijzigd door Rozz op 10-10-2020 13:37 . Reden: typo ]

[nero355]

Rozz schreef op zaterdag 10 oktober 2020 @ 13:02:
vraagje, ik draai al geruime tijd pi-hole naar alle tevredenheid maar hoe ga ik te werk als ik de ads op volgende website wil blokken?!?

CoinCodex

Ik heb de diverse linkaddressen in de blacklist gezet en alles geflushed, maar nog steeds komen ze door.

Volgens mij zijn dit ads die het gevolg zijn van een directe samenwerking i.p.v. via een ads provider/netwerk zoals je normaal gesproken ziet op de meeste websites, want ik zie ze ook niet terug in mijn Query Log

Webgnome schreef op zaterdag 10 oktober 2020 @ 13:03:
Ik zie geen ads? Kijk in de querylog en blokkeer die je niet wil.

Echt helemaal niks ?! Met een schone browser zonder extra plugins of add-ons

Rozz schreef op zaterdag 10 oktober 2020 @ 13:05:
das juist het probleem, ik zie overal ads, maar ze komen niet overeen in mn query....

Als ik linkadres kopieer en dat invul in de blacklist komen ze nog steeds door, en dit adres zie ik dan ook niet in mn query.

Dus mijn vraag, hoe ga ik dan te werk om uit te zoeken welke adressen het zijn?

Ik denk dus dat je daarvoor toch iets van uBlockOrigin of zo moet gebruiken die elementen van de webpagina kan verwijderen

[Dacuuu]

Rozz schreef op zaterdag 10 oktober 2020 @ 13:02:
vraagje, ik draai al geruime tijd pi-hole naar alle tevredenheid maar hoe ga ik te werk als ik de ads op volgende website wil blokken?!?

CoinCodex

Ik heb de diverse linkaddressen in de blacklist gezet en alles geflushed, maar nog steeds komen ze door.

Ik zie geen reclame.
Pihole + adguard dns ingesteld op pihole.
Adaway android

[Rozz]

nero355 schreef op zaterdag 10 oktober 2020 @ 14:30:
[...]
Volgens mij zijn dit ads die het gevolg zijn van een directe samenwerking i.p.v. via een ads provider/netwerk zoals je normaal gesproken ziet op de meeste websites, want ik zie ze ook niet terug in mijn Query Log
[...]
Ik denk dus dat je daarvoor toch iets van uBlockOrigin of zo moet gebruiken die elementen van de webpagina kan verwijderen

Ahh...dat zou idd alles verklaren, ga ik me verdiepen in ublock, wel reeds geinstalleerd maar na pihole nooit meer naar gekeken.

[Kopernikus.1979]

Dit is misschien meer iets voor het ubiquiti topic.
- Denk na waar wat mee mag communiceren. Ben je daar uit en tevreden mee dan ooit een keer als laatste regel een drop naar een RFC1918-group is te overwegen.
- Een vlan is een vlan, weinig bijzonders aan. Gastenlan ook echt via de controller inrichten als guest-vlan.
- Een IOT vlan is handig als het niet naar trusted kan, maar vanuit trusted wel naar het IOT-vlan.
- Voor MDNS smartphone/iot dien je het eea te configureren op de USG mbt een stabiele MDNS-config. De reflector is dat meestal niet, de repeater wel. ==> config.gateway.json.
- Het is te overwegen je CK in hetzelfde VLAN te hangen als je switches/aps, vooral als je ooit nog een flex mini als desktopswitchje gaat gebruiken, voorkomt dat wat gedoe.

- mogelijk heeft @nero355 nog wat aanvullingen.

Ik doe eigenlijk al alles zoals je beschrijft ook de MDNS reflector in de config.gateway.json (wat ze nu geschrapt hebben met hun Unifi OS grrr...).

Betreft Cloudkey is een moeilijke, je hebt er de controller en de Unifi protect, voor mij is deze ideaal voor in de management lan, helaas hierdoor moet alle traffic van mijn camera vlan over de usg, plaats ik de cloud key in camera vlan dan moet dit niet, tenzij ik een layer 3 switch zou kopen? of vergis ik me hierin?

Waar zou jij je Pihole's plaatsen? (PiHole als topic ) In de server vlan samen met mijn NAS of beter ook in de management vlan? En als laatste vraagje, welke firewall rules gebruik jij voor je management vlan? Normaal isoleer ik deze volledig tenzij men cloudkey er zou opzitten moet ik hiervoor een uitzondering maken.

[deHakkelaar]

Kopernikus.1979 schreef op zaterdag 10 oktober 2020 @ 11:45:
@nero355
@deHakkelaar
@ed1703

Goedemorgen :-)

Alles werkt
[..]

Das heel mooi.
Één dingetje nog.
Heb je weer die vlan package ge-installeerd en die 8021q mod geladen ?
Volgens mij heb je deze stappen helemaal niet nodig want de Pi-hole host functioneerd zelf niet als een (virtuele) switch.
Er hoeven geen trunks te propageren via de Pi-hole host.

[the mod man]

Sinds kort ben ik verhuisd naar een appartement incl internet en sinds covid zit ik nogal veel thuis

1+1=2 ik zit te kutten met internet en smart home.

Na heel wat geklooi om mn dekstop bedraad internet te geven, philips hue bridge werkend te krijgen (work in progress) ben ik ook toe aan een pi-hole. Voornamelijk voor mn smart tv icm youtube.

Voordat ik meer domme dingen doe en of koop dacht ik om hier maar mijn idee te laten dubbel checken.

Situatie:
ik huur een appartement incl internet. Internet word geleverd als wifi per appartement met als SSID [xxxhuisnummer]. Ik heb 2 routers in het appartement, waarom weet ik niet. Beide hebben 1 netwerk poort. 1 is afhankelijk van POE en de andere niet.

Toen ik hier kwam wonen heb ik een 4 poort switch gekocht zodat mn desktop bedraad aan t internet kon. Hele bevalling gezien ik niet doorhad dat de router POE nodig had waardoor ik nog een POE injector moest regelen.

Anyways, nu was ik bezig een philips hue bridge te installeren kom ik erachter dat mijn WIFI niet van 1 van de 2 routers in mijn appartement lijkt te komen. De HUE bridge is niet te vinden over wifi maar enkel vanaf mn desktop (die dus bedraad is aangesloten) De hue bridge blijkt in een ander ip-range te zitten. (beide routers geprobeerd uiteraard)

In het HUE forum kreeg ik het advies zelf een router te plaatsen. Nu wil ik het graag meteen goed doen en ook een pi-hole erbij te nemen. Dus ik ben van plan een router aan te schaffen in onderstaand schema als TP-link C6

schema gemaakt om het duidelijk te maken wat nu mijn plan is.
onderbroken lijntjes zijn wifi

Klopt het dat ik de pi-hole zo dien aan te sluiten, in de router die ik zelf aanschaf dan de DNS setting moet aanpassen en dat dan alle apparaten die met mijn eigen opgezette wifi automatisch gebruik maken van de pi-hole?

bestaande routers wil ik niet teveel aan zitten want misschien zijn de buren daarvan afhankelijk

[Kopernikus.1979]

deHakkelaar schreef op zaterdag 10 oktober 2020 @ 19:55:
[...]


Das heel mooi.
Één dingetje nog.
Heb je weer die vlan package ge-installeerd en die 8021q mod geladen ?
Volgens mij heb je deze stappen helemaal niet nodig want de Pi-hole host functioneerd zelf niet als een (virtuele) switch.
Er hoeven geen trunks te propageren via de Pi-hole host.

Deze keer enkel vlan package niet de 8021q, moet nog mijn 2de Pi-Hole instellen zal deze eens testen zonder vlan package.

[JayOne]

the mod man schreef op zaterdag 10 oktober 2020 @ 20:09:
Voornamelijk voor mn smart tv icm youtube.

Zou eerst maar eens kijken naar een betere use case voor Pi-Hole, want als je verwachting is dat je YouTube ads gaat blocken met Pi-Hole dat moet ik je helaas teleurstellen.

[the mod man]

JayOne schreef op zaterdag 10 oktober 2020 @ 20:55:
[...]

Zou eerst maar eens kijken naar een betere use case voor Pi-Hole, want als je verwachting is dat je YouTube ads gaat blocken met Pi-Hole dat moet ik je helaas teleurstellen.

Hmmz, ik lees nu inderdaad dat youtube ads lastiger zijn / niet werken. Op reddit zeggen sommigen dat er met wat moeite wel minder/veel minder ads zijn.

Via browser op mac en pc heb ik al plugins alla ublock privacybadger ghostery adblock en noscript en dacht (kennelijk verlopen kennis) dat een pi-hole nog een goede zou zijn voor mn smart tv en iphone.

Naja heeft geen haast.

[ed1703]

Kopernikus.1979 schreef op zaterdag 10 oktober 2020 @ 15:19:
[...]

Waar zou jij je Pihole's plaatsen? (PiHole als topic ) In de server vlan samen met mijn NAS of beter ook in de management vlan? En als laatste vraagje, welke firewall rules gebruik jij voor je management vlan? Normaal isoleer ik deze volledig tenzij men cloudkey er zou opzitten moet ik hiervoor een uitzondering maken.

Beheer hoort in een eigen VRF met een vlan, maarja die hebben we met Ubiquity niet
SSH hoort in een management vlan, services in een server vlan.
Verder kan ik alleen vanuit trusted vlans bij m’n management.
Een NAS wat dat betreft zou voor beheer en het serveren van services hetzelfde verhaal zijn.
Pihole is wel een uitzondering, dns werkt wat efficiënter als het een pootje in wat extra te bedienen vlans heeft, zal je waarschijnlijk niet merken, switching is nu eenmaal sneller dan routing.

[ Voor 11% gewijzigd door ed1703 op 10-10-2020 21:27 ]

[Raven]

the mod man schreef op zaterdag 10 oktober 2020 @ 21:09:
[...]


Hmmz, ik lees nu inderdaad dat youtube ads lastiger zijn / niet werken. Op reddit zeggen sommigen dat er met wat moeite wel minder/veel minder ads zijn.

Via browser op mac en pc heb ik al plugins alla ublock privacybadger ghostery adblock en noscript en dacht (kennelijk verlopen kennis) dat een pi-hole nog een goede zou zijn voor mn smart tv en iphone.

Naja heeft geen haast.

Er was een script voor, waarbij ik mij nog altijd afvraag hoe het kan dat die ooit gewerkt heeft, maar die heeft geen effect meer. Het lastige is, is dat ad's van YouTube over dezelfde domeinnaam worden ingeladen, blokkeer je YouTube ads, dan blokkeer je ook de video's. Daarnaast zit je mogelijk nog met het probleem dat sommige apps/devices de DNS-server er hardcoded in hebben zitten, je zou dan firewall regels moeten aanmaken die de DNS-requests redirecten naar PiHole, maar dat is een ander verhaal.

[JakeOfOz]

Hi, ik ben nieuw in dit topic, maar gebruik al tijden een pi-hole. Ben begonnen toen het nog op een rpi2 stond, maar heb inmiddels een model 4 met 4gb RAM. Werkt geweldig, ook als je zelf nog wat aan je block- en allowlist sleutelt.

Maar nu: ik maak sinds kort ook gebruik van een VPN-dienst (private internet access), maar hoe valt dat goed te combineren met een pihole? mijn router (een simpel ASUS model) heeft de DNS op de pihole staan, maar als ik de vpn aanslinger dan werkt dat niet meer (toch?). Ik heb nu de DNS van de vpn op 'use default DNS' staan, dan lijkt 'ie weer m'n pihole te gebruiken. Maar ik las ook ergens dat je door de vpn op de pihole te installeren het ook kan omzeilen.

Is hier iemand met ervaring met VPN-diensten en pihole?

Ik heb helaas weinig eigen kennis van netwerken, maar ik leer het hopelijk snel.

[Toet3r]

JakeOfOz schreef op zondag 11 oktober 2020 @ 10:51:
Hi, ik ben nieuw in dit topic, maar gebruik al tijden een pi-hole. Ben begonnen toen het nog op een rpi2 stond, maar heb inmiddels een model 4 met 4gb RAM. Werkt geweldig, ook als je zelf nog wat aan je block- en allowlist sleutelt.

Maar nu: ik maak sinds kort ook gebruik van een VPN-dienst (private internet access), maar hoe valt dat goed te combineren met een pihole? mijn router (een simpel ASUS model) heeft de DNS op de pihole staan, maar als ik de vpn aanslinger dan werkt dat niet meer (toch?). Ik heb nu de DNS van de vpn op 'use default DNS' staan, dan lijkt 'ie weer m'n pihole te gebruiken. Maar ik las ook ergens dat je door de vpn op de pihole te installeren het ook kan omzeilen.

Is hier iemand met ervaring met VPN-diensten en pihole?

Ik heb helaas weinig eigen kennis van netwerken, maar ik leer het hopelijk snel.

Ik gebruik PiVPN (wireguard) icm met mijn pi-hole. De installatie van pivpn herkent dat je pi-hole draait op je rpi en vraagt of je die ook wil gebruiken voor je vpn clients. Op deze manier kan je ook buitenshuis surfen zonder vervelende ads.

Zie: https://pivpn.io

[Webgnome]

Toet3r schreef op zondag 11 oktober 2020 @ 12:05:
[...]

Ik gebruik PiVPN (wireguard) icm met mijn pi-hole. De installatie van pivpn herkent dat je pi-hole draait op je rpi en vraagt of je die ook wil gebruiken voor je vpn clients. Op deze manier kan je ook buitenshuis surfen zonder vervelende ads.

Zie: https://pivpn.io

Werkt dit ook als je pihole op een andere raspberry draait? Ik heb twee rasperri's. Een RPi 3B en een RPI Zero W. De laatste bevat nu pihole en domoticz en wilde dat eigenlijk zo houden. Dus als ik de RPi 3B de vpn dienst kan laten bedienen zou dat mooi zijn icm pihole

[hp-got]

JakeOfOz schreef op zondag 11 oktober 2020 @ 10:51:
[...]ik maak sinds kort ook gebruik van een VPN-dienst (private internet access), maar hoe valt dat goed te combineren met een pihole?
[...]
Maar ik las ook ergens dat je door de vpn op de pihole te installeren het ook kan omzeilen.

Je wilt een VPN naar PIA, dat is iets voor uitgaand verkeer.
Een VPN op Pi-hole is bedoeld als dienst voor inkomend verkeer.
Het zijn twee verschillende dingen.....

[JakeOfOz]

hp-got schreef op zondag 11 oktober 2020 @ 12:26:
[...]

Je wilt een VPN naar PIA, dat is iets voor uitgaand verkeer.
Een VPN op Pi-hole is bedoeld als dienst voor inkomend verkeer.
Het zijn twee verschillende dingen.....

Ok, maar is het dan mogelijk om het samen te laten werken? En wat is daar dan eventueel de beste methode voor?

Ik heb een tweede rpi 4 die ik ook gewoon kan gebruiken, dus ik zou ook prima pihole op de een kunnen draaien, en een vpn op de andere, maar ik heb dus te weinig kennis van netwerken om te weten of dat effect zal hebben.
EDIT: en hoe ik vervolgens mijn router in moet stellen om dat te gebruiken

[ Voor 5% gewijzigd door JakeOfOz op 11-10-2020 12:34 ]

[hp-got]

JakeOfOz schreef op zondag 11 oktober 2020 @ 12:34:
[...]
Ok, maar is het dan mogelijk om het samen te laten werken? En wat is daar dan eventueel de beste methode voor?
[...]
EDIT: en hoe ik vervolgens mijn router in moet stellen om dat te gebruiken

Zou ik niet weten....

Lang geleden had ik een ASUS router die verbond met PIA VPN.
Ik ben daar mee gestopt omdat het (voor mij) meer nadelen dan voordelen had.

De enkele keer dat ik nu behoefte heb aan een VPN-verbinding gebruik ik de PIA app op een device.
Die app kan je dan meteen advertenties en andere zooi laten blokkeren, daar heb je geen Pi-hole voor nodig

[Toet3r]

Webgnome schreef op zondag 11 oktober 2020 @ 12:22:
[...]


Werkt dit ook als je pihole op een andere raspberry draait? Ik heb twee rasperri's. Een RPi 3B en een RPI Zero W. De laatste bevat nu pihole en domoticz en wilde dat eigenlijk zo houden. Dus als ik de RPi 3B de vpn dienst kan laten bedienen zou dat mooi zijn icm pihole

Ja dat kan. poort mappen naar de rpi waar je pivpn op draait en daar als dns het ip van de pi die pi-hole draait instellen.

[Raven]

hp-got schreef op zondag 11 oktober 2020 @ 12:42:
Lang geleden had ik een ASUS router die verbond met PIA VPN.
Ik ben daar mee gestopt omdat het (voor mij) meer nadelen dan voordelen had.

Gelukkig zijn er manieren om niet alles over VPN te laten gaan , zelf heb ik PIA al lange tijd in een virtuele pc met pfSense draaien. M.b.v. dante proxy server in pfSense verkeer van enkele specifieke apps via VPN laten gaan en de rest laten zoals het is.

[nero355]

JakeOfOz schreef op zondag 11 oktober 2020 @ 10:51:
Ik heb helaas weinig eigen kennis van netwerken, maar ik leer het hopelijk snel.

Dan kan het best wel een heel karwei gaan worden, want eigenlijk wil je het liefst zoiets opzetten :

Raven schreef op zondag 11 oktober 2020 @ 17:32:
Gelukkig zijn er manieren om niet alles over VPN te laten gaan , zelf heb ik PIA al lange tijd in een virtuele pc met pfSense draaien. M.b.v. dante proxy server in pfSense verkeer van enkele specifieke apps via VPN laten gaan en de rest laten zoals het is.

Maar nu: ik maak sinds kort ook gebruik van een VPN-dienst (private internet access), maar hoe valt dat goed te combineren met een pihole?

Er zijn wel een paar opties, maar de vraag is of je dat wel wilt, omdat er bij een verkeerde configuratie data buiten je VPN kan lekken!

mijn router (een simpel ASUS model) heeft de DNS op de pihole staan, maar als ik de vpn aanslinger dan werkt dat niet meer (toch?)

Omdat al je verkeerd standaard over de VPN wordt gestuurd inderdaad

Ik heb nu de DNS van de vpn op 'use default DNS' staan, dan lijkt 'ie weer m'n pihole te gebruiken.

Dat lijkt een soort ingebouwde "Split-Horizon" te zijn dan : Alleen DNS lokaal en de rest over de VPN heen!

Maar ik las ook ergens dat je door de vpn op de pihole te installeren het ook kan omzeilen.

Dan zou je Pi-Hole server ook als Router moeten inzetten

Is hier iemand met ervaring met VPN-diensten en pihole?

Ik zou het in jouw geval hierbij laten :

hp-got schreef op zondag 11 oktober 2020 @ 12:42:
De enkele keer dat ik nu behoefte heb aan een VPN-verbinding gebruik ik de PIA app op een device.
Die app kan je dan meteen advertenties en andere zooi laten blokkeren, daar heb je geen Pi-hole voor nodig

[Kopernikus.1979]

ed1703 schreef op vrijdag 9 oktober 2020 @ 19:45:
[...]

???

Waar heb je het over?

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.1.1       0.0.0.0         UG    202    0        0 eth0
0.0.0.0         10.10.10.1      0.0.0.0         UG    204    0        0 eth0.10
0.0.0.0         10.10.20.1      0.0.0.0         UG    205    0        0 eth0.20
0.0.0.0         10.10.30.1      0.0.0.0         UG    206    0        0 eth0.30
10.10.1.0       0.0.0.0         255.255.255.0   U     202    0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     204    0        0 eth0.10
10.10.20.0      0.0.0.0         255.255.255.0   U     205    0        0 eth0.20
10.10.30.0      0.0.0.0         255.255.255.0   U     206    0        0 eth0.30

Met verschillende metrics werkt prima, die staan er ook op.

Laat ik de config nu zo of is het beter maar 1 "static router" te configureren?
Zo ja, waarom?

De native VLAN & management VLAN gebruiken niet de PiHole dns, heeft het zin om alles op Pi-hole te plaatsen of is het beter deze de dns van de USG te laten gebruiken?

[ed1703]

Kopernikus.1979 schreef op zondag 11 oktober 2020 @ 21:10:
[...]


Laat ik de config nu zo of is het beter maar 1 "static router" te configureren?
Zo ja, waarom?

De native VLAN & management VLAN gebruiken niet de PiHole dns, heeft het zin om alles op Pi-hole te plaatsen of is het beter deze de dns van de USG te laten gebruiken?

Gateway: maakt technisch niet zoveel uit, hij gebruikt altijd de laagste metric. Beetje om het even.

DNS: ik resolve alles via de pihole (met ook weer unbound, sommige free resolvers vind ik verre van betrouwbaar, afgezien van de privacy issue), mijn lokale namen staan ook op de pihole. Als je 2 piholes gaat draaien is keepalived nog handig.

[Kopernikus.1979]

ed1703 schreef op zondag 11 oktober 2020 @ 21:28:
[...]

Gateway: maakt technisch niet zoveel uit, hij gebruikt altijd de laagste metric. Beetje om het even.

DNS: ik resolve alles via de pihole (met ook weer unbound, sommige free resolvers vind ik verre van betrouwbaar, afgezien van de privacy issue), mijn lokale namen staan ook op de pihole. Als je 2 piholes gaat draaien is keepalived nog handig.

Super, ga ik ook eens zo proberen, enkel voor de native vlan (dus lan1) wat vul ik hier in voor dns?
Voor alle andere is het simpel: het statisch IP voor de betreffende vlan gedefinieerd op de RasPi.
Want op mijn pihole kan ik deze niet defenieren? Tenzijn ik de poort aanpas native untaged maar dan zit de Pi niet meer in zijn VLAN maar op de native samen met de USG.
Moet er in de hosts file nog iets speciaal voor de USG?
Unbound gebruikte ik ook al als resolver.
Mijn 2de Pi-hole gebruikte ik als 2de DNS, enig nadeel is dat statistieken verspreid zijn over de 2 Pi-hole's, zou je eerder de HA oplossing aanraden?

[ Voor 5% gewijzigd door Kopernikus.1979 op 11-10-2020 21:50 ]