Sticky

Gebruik een eigen router i.p.v. de Experia Box

  • 8 September 2018
  • 8565 reacties
  • 562938 keer bekeken
Gebruik een eigen router i.p.v. de Experia Box

Toon eerste bericht

8565 reacties

Reputatie 1

en jij laat bij RAs de 'name-server’ nu ook leeg zie ik?

Die is bij mij nooit gevuld geweest, de RDNSS option zorgt er immers voor dat de IPv6 DNS servers aan de cliënts doorgegeven worden.

PS. puur om de kennisgeving, in de 'boot.config’ stonden de name-servers wel ingevuld (Edgerouter 😵.

Zal geen drama zijn maar dacht ik merk het even op om de eventuele kennisgeving, mocht het handig zijn toevallig.

 

Reputatie 7

Het heeft dus niet echt een voordeel om een radvd naar mij  Edgerouter te doen dus bijvoorbeeld?

Als jij jouw lokale machines ook m.b.v. een domeinnaam wilt kunnen benaderen dan is het gebruik van de EdgeRouter als DNS server te prefereren.

In dat geval zet ik dan bij de 'radvd-options’=`RDNSS ???? {};` het Switch0 ipv6 adres? èn handhaaf ik dan wèl de DNS-forwarding (inclusief: options listen-address=192.168.2.254) en/of bij de ‘DHCP-Server thuis’ de DNS1 verwijzen naar de Edgerouter op .2.254 …

OF snap ik het dan toch nog niet helemaal?

Klopt helemaal.

Reputatie 2

Klopt en dat is bewust gedaan omdat anders je Pihole in een loop komt te zitten als het gaat om DNS verkeer, ...

Dat is natuurlijk niet zo mits je de DNS forwarder in jouw PiHole / AdGuard server maar naar de externe DNS servers laat verwijzen die je daarvoor wilt gebruiken.

 

Als je overigens wilt dat al het DNS verkeer via jouw PiHole loopt, vergeet dan niet verkeer rechtstreeks gericht aan een externe DNS server naar jouw PiHole te redirecten. Er zijn nogal wat apps op Android maar ook op andere platforms (zelfs op de TV ontvangers van KPN) die DNS requests rechtstreeks (hardcoded) naar de DNS servers van Google sturen.

Ik heb daarvoor de onderstaande natting rule opgenomen...

...waarbij de address-group Blocked-DNS er als onderstaand uitziet.

 

DNS requests rechtstreeks gericht aan één van de DNS servers van google worden dus geredirect naar de EdgeRouter zelf en lopen dus uiteindelijk via de DNS forwarder naar de DNS servers van CloudFlare en KPN.

Ik denk dat we langs elkaar heen praten of je begrijpt niet wat de implicaties zijn van jouw keuzes, heb jezelf ervaring met het draaien van PiHole of Adguard achter een Edgerouter? 

Op het moment namelijk dat je op WAN niveau de DNS servers gaat toewijzen naar je PiHole of Adguard Home server dan creëer je een loop wat je heel eenvoudig kunt herleiden door een diagram te maken. Het aantal PTR verzoeken zal namelijk significant gaan toenemen in het voorstel wat je doet en heel onwenselijk is laat staan dat je je server buitenom laat lopen met een IPV6 global link. Dit moet je geheel niet willen ivm privacy, je maakt jezelf daardoor enorm kwetsbaar.

Daarnaast is het ook niet nodig om een firewall rule te maken voor poort 53 als je mijn methode zou aanhouden. Al het lokale verkeer wordt namelijk al omgeleid naar pihole of Adguard server, je kunt de DNS controle namelijk zo nalopen in je apparaten en dan zul je zien dat ze de PiHole dan wel Adguard Home server zullen aanhouden. 

Reputatie 7

Op het moment namelijk dat je op WAN niveau de DNS servers gaat toewijzen naar je PiHole of Adguard Home server dan creëer je een loop wat je heel eenvoudig kunt herleiden door een diagram te maken. Het aantal PTR verzoeken zal namelijk significant gaan toenemen in het voorstel wat je doet en heel onwenselijk is laat staan dat je je server buitenom laat lopen met een IPV6 global link. Dit moet je geheel niet willen ivm privacy, je maakt jezelf daardoor enorm kwetsbaar.

Er wordt helermaal geen loop gecreëerd, zolang jouw PiHole maar forward naar een externe DNS server en niet terug naar de EdgeRouter.

 

Daarnaast is het ook niet nodig om een firewall rule te maken voor poort 53 als je mijn methode zou aanhouden. Al het lokale verkeer wordt namelijk al omgeleid naar pihole of Adguard server, je kunt de DNS controle namelijk zo nalopen in je apparaten en dan zul je zien dat ze de PiHole dan wel Adguard Home server zullen aanhouden. 

Nee, DNS requests die door een app rechtstreeks naar een externe DNS server verstuurd worden zullen niet naar jouw PiHole omgeleid worden, die gaan zonder zo'n natting rule rechstreeks naar die externe server. Ook in jouw opzet zal je echt zo'n rule op moeten zetten als je 100% wilt voorkomen dat apps rechtstreeks DNS requests naar bijvoorbeeld de servers van Google sturen.

 

Ik heb ter illustratie even zo'n natting rule opgezet op het vlan waar ik mijn TV ontvangers op heb aangesloten.

Dit vlan is als onderstaand geconfigureerd en maakt geen gebruik van IPv6 omdat het KPN TV platform IPv4 only is.

De DNS servers voor dit vlan zijn ook ingesteld op de standaard DNS servers van KPN.

 

Toch zien we de counter op de nat rule direct al oplopen omdat één van die vier TV ontvangers DNS requests rechtstreeks naar 8.8.8.8 verstuurt en niet naar de via DHCP aangeboden DNS servers voor het vlan.

En dat betekent dus dat deze rule in heeft moeten grijpen om te voorkomen dat er een DNS request naar Google gestuurd zou worden.

Reputatie 1

ik

Het heeft dus niet echt een voordeel om een radvd naar mij  Edgerouter te doen dus bijvoorbeeld?

Als jij jouw lokale machines ook m.b.v. een domeinnaam wilt kunnen benaderen dan is het gebruik van de EdgeRouter als DNS server te prefereren.

In dat geval zet ik dan bij de 'radvd-options’=`RDNSS ???? {};` het Switch0 ipv6 adres? èn handhaaf ik dan wèl de DNS-forwarding (inclusief: options listen-address=192.168.2.254) en/of bij de ‘DHCP-Server thuis’ de DNS1 verwijzen naar de Edgerouter op .2.254 …

OF snap ik het dan toch nog niet helemaal?

Klopt helemaal.

ik zal dan wel een denkfout maken want zo werkt het dan niet, bij mij dan pfff hahaha

ik heb ipv6 voor bij radvd het adres uit de edgerouter dashboard overgenomen bij 'thuis netwerk’

dhcp terug op dns v/d edgerouter

bij advert (RAs) dus ipv6 vanuit dashboard Edgerouter

switch0 ‘as is’

en de dns-forward de 'options listen-address=192.168.2.254’ terug en hier de ipv4+ipv6 name-servers van mijn Pihole

...maar zo werkt het niet meer dan, geen internet op diverse devices *PS*=> heb tikfout in listen-address ontdekt, waarschijnlijk was dat het…

 

Reputatie 7

De listen-address=192.168.2.254 bij de DNS forwarder kan je weghalen.

Wat is de volledige tekst bij de radvd option?

Naar welk(e) IP adres(sen) zal de Pihole op 192.168.2.10 DNS requests forwarden?

Reputatie 1

De listen-address=192.168.2.254 bij de DNS forwarder kan je weghalen.

Wat is de volledige tekst bij de radvd option?

Naar welk(e) IP adres(sen) zal de Pihole op 192.168.2.10 DNS requests forwarden?

die haal ik weg, daarin zat ook een verkeerde extra spatie zag ik net, ik vermoed dat die het gedoe gaf, maar die ga ik nu dus ook sowieso leeg maken en opnieuw testen

radvd-options = RDNSS 2a02:a444:c67a:1::1 {};

EDiT: lijkt echt die dubbele spatie te zijn geweest bij de dns-forward bij options 'listen-address', want nu op uw aanraden verwijderd en alles werkt wel weer. 

Reputatie 7

radvd-options = RDNSS 2a02:a444:c67a:1::1 {};

Die is in ieder geval correct.

Reputatie 1

radvd-options = RDNSS 2a02:a444:c67a:1::1 {};

Die is in ieder geval correct.

werkt nu weer, doordat u zei verwijder die listen regel bij dns-forward option zag ik ook dat ik dar een typo had. ter test had ik overigens extra de ipv6 name-server van mijn pihole opgenomen bij`Router-advert (RAs) name-server. Die kan ik in principe toch ook weg halen toch? (ik laat dus natuurlijk wèl de ipv6 van mijn edgerouter thuis netwerk staan bij radvd zoals we hadden dubbel checked).

Reputatie 7

...ter test had ik overigens extra de ipv6 name-server van mijn pihole opgenomen bij`Router-advert (RAs) name-server. Die kan ik in principe toch ook weg halen toch?

Klopt, de IPv6 name-server kan je weghalen zolang je de radvd option RDNSS maar laat staan.

Reputatie 1

...ter test had ik overigens extra de ipv6 name-server van mijn pihole opgenomen bij`Router-advert (RAs) name-server. Die kan ik in principe toch ook weg halen toch?

Klopt, de IPv6 name-server kan je weghalen zolang je de radvd option RDNSS maar laat staan.

van deze methode is het wel spijtig dat meerendeel van de queries die ik nu in de connection log zie voorbij komen vanuit .2.254 (=Edgerouter) lijken te komen in plaats van dat ik de individuele IOT-devices zie. Tenminste daar lijkt het nu momenteel nog wel op.

Wie weet wat een herstart van alle apparatuur later vanavond hierin eventueel misschien nog te weeg brengt.

Reputatie 7

...ter test had ik overigens extra de ipv6 name-server van mijn pihole opgenomen bij`Router-advert (RAs) name-server. Die kan ik in principe toch ook weg halen toch?

Klopt, de IPv6 name-server kan je weghalen zolang je de radvd option RDNSS maar laat staan.

van deze methode is het wel spijtig dat meerendeel van de queries die ik nu in de connection log zie voorbij komen vanuit .2.254 (=Edgerouter) lijken te komen in plaats van dat ik de individuele IOT-devices zie. Tenminste daar lijkt het nu momenteel nog wel op.

Wie weet wat een herstart van alle apparatuur later vanavond hierin eventueel misschien nog te weeg brengt.

Dat klopt, als je op jouw Pihole de DNS requests vanaf de individuele apparaten wilt zien dan zal je de instellingen zoals @Miguel_ die noemt moeten gaan gebruiken.

Reputatie 1

...ter test had ik overigens extra de ipv6 name-server van mijn pihole opgenomen bij`Router-advert (RAs) name-server. Die kan ik in principe toch ook weg halen toch?

Klopt, de IPv6 name-server kan je weghalen zolang je de radvd option RDNSS maar laat staan.

van deze methode is het wel spijtig dat meerendeel van de queries die ik nu in de connection log zie voorbij komen vanuit .2.254 (=Edgerouter) lijken te komen in plaats van dat ik de individuele IOT-devices zie. Tenminste daar lijkt het nu momenteel nog wel op.

Wie weet wat een herstart van alle apparatuur later vanavond hierin eventueel misschien nog te weeg brengt.

Dat klopt, als je op jouw Pihole de DNS requests vanaf de individuele apparaten wilt zien dan zal je de instellingen zoals @Miguel_ die noemt moeten gaan gebruiken.

Dank u, dan snap ik nu ook beter het verschil, top!

Vriendelijk dank voor die uitleg, weer een en ander (bij)geleerd ✅

Reputatie 1

Klopt en dat is bewust gedaan omdat anders je Pihole in een loop komt te zitten als het gaat om DNS verkeer, ...

Dat is natuurlijk niet zo mits je de DNS forwarder in jouw PiHole / AdGuard server maar naar de externe DNS servers laat verwijzen die je daarvoor wilt gebruiken.

 

Als je overigens wilt dat al het DNS verkeer via jouw PiHole loopt, vergeet dan niet verkeer rechtstreeks gericht aan een externe DNS server naar jouw PiHole te redirecten. Er zijn nogal wat apps op Android maar ook op andere platforms (zelfs op de TV ontvangers van KPN) die DNS requests rechtstreeks (hardcoded) naar de DNS servers van Google sturen.

Ik heb daarvoor de onderstaande natting rule opgenomen...

...waarbij de address-group Blocked-DNS er als onderstaand uitziet.

 

DNS requests rechtstreeks gericht aan één van de DNS servers van google worden dus geredirect naar de EdgeRouter zelf en lopen dus uiteindelijk via de DNS forwarder naar de DNS servers van CloudFlare en KPN.

Ik heb hem als dusdanig aangepast, waarbij .2.10 dus mijn Pihole is:

Ik stuur hem dan ook door naar Pihole @.2.10 ipv .2.254 (Edgerouter).

Ik heb dus bewust ook wel een 'source' aangegeven met uitzondering van .2.10 (dmv.  !  v/h ip-adres te zetten)

Wat ik me afvraag, heeft het nog noodzaak of voordeel om ook een 'masquerade' regel op te nemen bij 'Source NAT rule', ik zag (eerder al) meerdere voorbeelden online waarbij ze die wel extra opnemen dus extra naast de 'Destination NAT rule). Ter illustratie: ⬇️

 

Reputatie 7

Ik heb hem als dusdanig aangepast, waarbij .2.10 dus mijn Pihole is:

Ik stuur hem dan ook door naar Pihole @.2.10 ipv .2.254 (Edgerouter).

Ik heb dus bewust ook wel een 'source' aangegeven met uitzondering van .2.10 (dmv.  !  v/h ip-adres te zetten)

Dat kan je doen maar feitelijk is dat overbodig immers de DNS forwarder van jouw Pihole zal, neem ik aan, geen forward IP adressen bevatten uit de address-group Blocked DNS servers. Daarnaast neem ik eigenlijk ook aan dat ook het iP adres van jouw EdgeRouter niet opgenomen is in de DNS forwarder van jouw Pihole en dus zullen er nooit DNS requests op de EdgeRouter aankomen afkomstig van jouw Pihole.

Reputatie 1

Ik heb hem als dusdanig aangepast, waarbij .2.10 dus mijn Pihole is:

Ik stuur hem dan ook door naar Pihole @.2.10 ipv .2.254 (Edgerouter).

Ik heb dus bewust ook wel een 'source' aangegeven met uitzondering van .2.10 (dmv.  !  v/h ip-adres te zetten)

Dat kan je doen maar feitelijk is dat overbodig immers de DNS forwarder van jouw Pihole zal, neem ik aan, geen forward IP adressen bevatten uit de address-group Blocked DNS servers. Daarnaast neem ik eigenlijk ook aan dat ook het iP adres van jouw EdgeRouter niet opgenomen is in de DNS forwarder van jouw Pihole en dus zullen er nooit DNS requests op de EdgeRouter aankomen afkomstig van jouw Pihole.

Correct en leek mij idd ook overbodig. Wat was anders het voordeel geweest als je alles op de Edgerouter laat gebeuren. Ik volgde deze extra stap eigenlijk niet zo goed. Heb in een oudere situatie zonder pihole ook zonder die extra masquerade regel die Google-DNS block werkend gehad. Vandaar toch die nieuwsgierigheid naar de meerwaarde dan eigenlijk (als die er is). 

Reputatie 7

Vandaar toch die nieuwsgierigheid naar de meerwaarde dan eigenlijk (als die er is). 

Als jij echt wilt voorkomen dat er ooit een DNS request naar Google gestuurd wordt dan zal je zo'n regel op moeten nemen maar daarbij hoef je de Pihole niet perse uit te sluiten in de source immers er zal toch nooit een DNS request vanaf de Pihole naar de EdgeRouter gestuurd worden.

Je ziet ook dat hij bij jou "al" 6 keer afgegaan is en dat betekent dat er dus "al" 6 keer een poging gedaan is om een DNS request rechtstreeks naar Google te sturen.

Zie ook dit eerdere bericht.

Reputatie 1

Vandaar toch die nieuwsgierigheid naar de meerwaarde dan eigenlijk (als die er is). 

Als jij echt wilt voorkomen dat er ooit een DNS request naar Google gestuurd wordt dan zal je zo'n regel op moeten nemen.

Je ziet ook dat hij bij jou "al" 6 keer afgegaan is en dat betekent dat er dus "al" 6 keer een poging gedaan is om een DNS request rechtstreeks naar Google te sturen.

Zie ook dit eerdere bericht.

Geen verassing want ik heb een chromecast4 (google tv) lol, ook mede daarom ook een block op hardcoded-dns (al is het enkel op ipv4 basis). Heb die extra masquerade aan de 'source nat' zijde nooit zo goed begrepen, of het moet puur om het monitoren zijn?

(het blokkeren gebeurt in dit geval aan de 'destination nat' zijde)

Reputatie 7

Geen verassing want ik heb een chromecast4 (google tv) lol, ook mede daarom ook een block op hardcoded-dns (al is het enkel op ipv4 basis). Heb die extra masquerade aan de 'source nat' zijde nooit zo goed begrepen, of het moet puur om het monitoren zijn?

(het blokkeren gebeurt in dit geval aan de 'destination nat' zijde)

Die natting rule is geen blokkade maar een redirect naar een ander IP adres.

En vergeet alsjeblieft die masquerade want dat doe je in principe alleen in source nat rules richting jouw WAN (PPPoE) interface. Die masquerade betekent feitelijk niets anders dan dat het source IP adres "verborgen" wordt en dat er verder gecommuniceerd wordt met het IP adres van die interface. Bij de pppoe interface is dat dus jouw WAN IP adres.

Reputatie 1

Geen verassing want ik heb een chromecast4 (google tv) lol, ook mede daarom ook een block op hardcoded-dns (al is het enkel op ipv4 basis). Heb die extra masquerade aan de 'source nat' zijde nooit zo goed begrepen, of het moet puur om het monitoren zijn?

(het blokkeren gebeurt in dit geval aan de 'destination nat' zijde)

Die natting rule is geen blokkade maar een redirect naar een ander IP adres.

En vergeet alsjeblieft die masquerade want dat doe je in principe alleen in source nat rules richting jouw WAN (PPPoE) interface. Die masquerade betekent feitelijk niets anders dan dat het source IP adres "verborgen" wordt en dat er verder gecommuniceerd wordt met het IP adres van die interface. Bij de pppoe interface is dat dus jouw WAN IP adres.

Excuus was hier idd redirect (was zelf even in de war met wat anders).

Vriendelijk dank voor de aanvulling vwb de masquerade 👌👍

 

het werkt allemaal toch niet zoals gewenst.

Soms zie ik nu in mijn netwerkinstellingen op mijn computer netjes DNS en gateway staan maar heb ik geen ipv6 verbinding als ik naar een test site ga.

Er viel mij nog iets op. 

mijn computer geeft het fe80 adres van de router maar als ik daar naar toe surf krijg ik een unreachable. Echter wanneer ik naar het 2a02 adres ga kom ik gewoon in de edgerouter.

wanneer ik dan ping naar dit adres krijg ik niks:

ping6: wrote fe80::7683:c2ff:fefc:2915 16 chars, ret=-1
ping6: sendmsg: No route to host

 

Misschien zit hier iets mis?

 

en just to be sure… ik hoef niet de router te herstarten na wijzigingen als de router hier niet om vraagt? ik zie namelijk wel de wijzigingen netjes doorkomen. 

Reputatie 7

Soms zie ik nu in mijn netwerkinstellingen op mijn computer netjes DNS en gateway staan maar heb ik geen ipv6 verbinding als ik naar een test site ga.

Er viel mij nog iets op. 

mijn computer geeft het fe80 adres van de router maar als ik daar naar toe surf krijg ik een unreachable. Echter wanneer ik naar het 2a02 adres ga kom ik gewoon in de edgerouter.

wanneer ik dan ping naar dit adres krijg ik niks:

ping6: wrote fe80::7683:c2ff:fefc:2915 16 chars, ret=-1
ping6: sendmsg: No route to host

 

Misschien zit hier iets mis?

 

Vreemd, ik krijg wel gewoon een route naar de EdgeRouter en responses op ping verzoeken.

 

Wat mij overigens wel opgevallen is, is dat IPv6 stabieler is als ik het 2a02 IP adres van de EdgeRouter in de radvd option RDNSS gebruik i.p.v. het fe80 adres. Vandaar dat je in het bovenstaande screenshot als DNS server het 2a02 IP adres van de EdgeRouter ziet staan.

 

en just to be sure… ik hoef niet de router te herstarten na wijzigingen als de router hier niet om vraagt? ik zie namelijk wel de wijzigingen netjes doorkomen. 

Klopt, je hoeft een EdgeRouter alleen opnieuw te starten als je IPv6 aan of uit zet, niet bij andere wijzigingen van de configuratie.

Ik heb ook het 2a02 adres daar staan nu.

maar ik krijg dus geen route naar de gateway :/

Reputatie 7

Ik heb ook het 2a02 adres daar staan nu.

maar ik krijg dus geen route naar de gateway :/

Is dit op meerdere machines zo of wellicht alleen op die computer (Mac?)?

Kan je hier jouw complete config.boot eens in een spoiler element zetten?

 

ik heb eigenlijk weinig veranderd na de laatste keer .

Heb ook al mijn edgerouter herstart.

Vergeleken met jouw boot file van de entry-post.

 

Het gekke is dat ik via chrome (incl cognito) een unreachable krijg op de gatewat.

Net zoals een ping6 vanuit mn terminal.

 

Maar vanuit safari krijg ik netjes de gui gerserveerd als ik naar het gateway adres navigeer :/ 

 

ik krijg ook geen route to host vanaf mijn iphone. Maar ik kan er wel naartoe navigeren.

Reageer