Skip to main content

Wil je om wat voor een reden dan ook af van de Experia Box, vervang deze dan door een eigen router. Dat is mogelijk, al kan het best een uitdaging zijn om een eigen router zo te configureren dat deze goed overweg kan met het iTV platform van KPN.

 

Wijzigingen in configuratie scripts voor EdgeRouters (22 juli 2022).

Edit (22 juli 2022): Wijziging van 21 juli 2022 teruggedraaid. De scripts voor te EdgeRouter X met vlan zijn bedoeld om op de corresponderende poort een switch aan te sluiten en niet een TV ontvanger. 

Edit (21 juli 2022): Scripts voor EdgeRouter-X (SFP) aangepast zodat vlan 4 niet als vid maar als pvid op de eerste poort van de switch geactiveerd wordt.

Edit (12 maart 2022): Scripts voor EdgeRouter-X (SFP) aangepast zodat vlan 4 op de eerste poort van de switch geactiveerd wordt.

Edit (10 maart 2022): Scripts toegevoegd voor het gebruik van vlan 4 voor TV.

Edit (21 december 2021): Foutje in het script voor de EdgeRouter 4-SFP met TV ontvanger(s) op eth0 en eth1 hersteld

Edit (18 oktober 2021): Scripts toegevoegd voor de EdgeRouter 4 met TV ontvanger(s) op aparte poorten.

Edit (4 september 2021): Firewall inkomend toegevoegd op vlan 4 (IPTV). Overbodige global options op DHCP server verwijderd. Foutje in configuratie van IGMP proxy server in configuratiescripts voor EdgeRouters met SFP gecorrigeerd. 

Edit (3 augustus 2021): Het configuratiescript voor de EdgeRouter Lite 3 is hernoemd naar de EdgeRouter 4.

Configuratiescripts toegevoegd voor de EdgeRouter 4 waarbij de SFP poort gebruikt wordt als WAN poort.

De configuratiescripts voor de EdgeRouter X SFP zijn nu voor gebruik van de SFP poort als WAN poort. Als de SFP poort niet gebruikt wordt dan kan het configuratiescript voor de EdgeRouter X gebruikt worden.

Kleine optimalisaties doorgevoerd in configuratiescripts voor de EdgeRouter X met TV ontvangers op aparte poorten.

 

Edit (1 augustus 2021): Configuratiescripts voor Telfort verwijderd en configuratiescript voor EdgeRouter X met 2 TV ontvangers toegevoegd.

 

Edit (22 februari 2021): De config.boot in het configuratiescript voor de EdgeRouter X KPN met telefonie via Experia Box bleek voor de Telfort variant van de EdgeRouter Lite 3 te zijn.

 

Edit (20 februari 2021): De config.boot bleek te missen in het Telfort script voor de EdgeRouter Lite 3 zonder telefonie via de Experia Box. Tevens bleek de verkeerde readme.txt opgenomen te zijn in de Telfort configuratiescripts voor de EdgeRouter Lite 3. 

 

Edit (14 februari 2021): Kleine aanpassing zodat het plaatsen van de TV ontvangers op een eigen subnet iets eenvoudiger wordt.

 

Edit (15 januari 2021): Het lijkt er op, als de technische migratie gestart wordt, dat ex Telfort abonnees hun Experia Box tijdelijk zullen moeten aansluiten om overgezet te kunnen worden van de Telfort architectuur naar de KPN architectuur. Daarna kan je direct de eigen router weer gebruiken mits de configuratie daarvan ook omgezet is van Telfort naar KPN.

 

Edit (14 januari 2021): Foutje gecorrigeerd in de configuratiescripts voor de EdgeRouter X met TV op eth1.

 

Edit (19 december 2020): KPN heeft op 14 december een nieuwe dienst geïntroduceerd zijnde een malwarefilter. Feitelijk is dit niets anders dan het gebruik van andere DNS servers.

De anti-malware DNS servers van KPN hebben de onderstaande IP adressen:

  • 195.121.97.202
  • 195.121.97.203
  • 2a02:a47f:ac::210
  • 2a02:a47f:ac::212

Wil je gebruik maken van deze dienst dan zal je de DNS servers moeten overnemen.

 

Edit (27 november 2020): Ik heb de configuratiescripts voor Telfort met telefonie via de Experia Box aangepast. 

 

Edit (21 november 2020): Ik heb een foutje in de bootstrap hersteld die er voor zou moeten zorgen dat na een reboot van de EdgeRouter de IGMP proxy server wel automatisch opgestart gaat worden. Ik raad bestaande gebruikers, die hun EdgeRouter met een configuratiescript van voor 21 november 2020 geconfigureerd hebben, aan de fix (EdgeRouter-KPN-Bootstrap-Fix (zip 21 november 10:13) te downloaden en de wijzigingen op hun router door te voeren.

 

Edit (7 november 2020): Ik heb de configuratiescripts voor onze Telfort broeders toegevoegd.

 

Edit (6 november 2020): Ik heb in de configuratiescripts de bootstrap voor de EdgeRouter aangepast zodat standaard geconfigureerd wordt dat de IGMP proxy server pas gestart wordt nadat het netwerk geactiveerd is. Hierdoor is een herstart van de IGMP proxy server na een reboot niet meer nodig. Bestaande EdgeRouter gebruikers kunnen het script EdgeRouter-KPN-Bootstrap-Fix (zip 6 november 17:40) downloaden om de wijzigingen op hun router door te voeren.

 

Edit (25 maart 2020): De vrije (modem)routerkeuze is vanaf vandaag een feit😀 Daarmee is het nu ook mogelijk een eigen router te gebruiken als je vaste telefonie bij KPN hebt ondergebracht.Als je een EdgeRouter gaat gebruiken met een eigen VoIP ATA voor telefonie dan kan je kiezen voor de configuratiescripts zonder telefonie. Zet hierbij wel de SIP functionaliteit uit op de EdgeRouter.

Edit (4 september 2019): Sinds 12 augustus is dit ook voor VDSL abonnees -zonder vaste telefoon abonnement van KPN- mogelijk nu in OS 7.13 van de Fritz!Box routers een configuratie wizard voor de KPN netwerken is opgenomen. Overigens is de Fritz!Box met OS 7.13 ook inzetbaar op glasvezelaansluitingen. Gebruik de Fritz!Box vergelijker om een voor jouw aansluiting geschikt model te selecteren. Laat je hierbij overigens niet misleiden door de filter "glasvezel". Het lijkt er dan op dat alleen de 5490 geschikt zou zijn maar dat is niet zo. Elke Fritz!Box met een WAN poort kan op de NTU aangesloten worden. Let er ook goed op dat OS 7.13 of nieuwer beschikbaar is op die Fritz!Box.


Met dit topic hoop ik dat wij als abonnees van KPN elkaar kunnen helpen met het configureren van een eigen router.

LET OP: Het onderstaande zal waarschijnlijk al snel een vrij hoog technisch gehalte gaan krijgen waardoor het voor velen best lastig te volgen zou kunnen zijn. Toch hoop ik dat uiteindelijk in dit topic goede en begrijpelijke handleidingen zullen ontstaan waardoor ook de minder technisch aangelegde abonnee in staat zal zijn zijn/haar eigen router te gebruiken. Mocht je denken ... dit gaat me toch echt mijn pet te boven ... dan is wellicht het volgende topic iets voor jou: Gebruik een eigen router achter de Experia Box.

Wees je er overigens terdege van bewust dat lang niet elke router geschikt is om de Experia Box te vervangen. Met name de configuratie van het IPTV gedeelte kan nog wel eens een spelbreker blijken te zijn. Zo zie je bijvoorbeeld op TP-Link en Asus routers functionaliteit voor het inrichten van IPTV maar dat is bridged-IPTV waarbij een LAN poort van de router gebridged wordt op het IPTV vlan van KPN (vlan 4). KPN maakt echter gebruik van routed-IPTV waarbij de TV ontvangers, net als alle andere apparatuur, gewoon met Internet (vlan 6) verbonden worden en een IGMP proxy server op de router er voor zorgt dat de TV streams van vlan 4 betrokken worden. Gelukkig zijn er ook routers te vinden waarmee de Experia Box wel succesvol vervangen kan worden maar het is wel cruciaal dat je bij de aanschaf van een router goed kijkt of deze geschikt is voor routed IPTV van KPN.

Bron.

Onderaan dit topic staat een lijst met routers die tot op heden succesvol op een KPN aansluiting met IPTV in gebruik genomen zijn.

 

KPN zal je geen support meer kunnen bieden bij eventuele storingen en dus ben je dan op jezelf aangewezen om zo'n storing te verhelpen. Daarnaast zullen de KPN servicetools niet meer werken.

Zelf heb ik een Ubiquiti EdgeRouter 4 ingezet om de Experia Box te vervangen. Deze router heeft geen ingebouwde wifi, maar daarvoor gebruik ik losse WiFi accesspoints zoals de EDIMAX CAP1200, de KPN WiFi "versterker", de Experia WiFi of bijvoorbeeld de Ubiquiti Unifi AP AC PRO.

Onderstaand een screenshot van het dashboard van mijn EdgeRouter 4 waarin zichtbaar is dat deze een (pppoe) verbinding opgebouwd heeft met het KPN netwerk op vlan 6 en dat het IPTV op vlan 4 operationeel is.

Ik hoop dat voor een aantal geschikte routers configuratie scripts geschreven gaan worden die we dan hier op kunnen nemen.

Configuratie scripts (downloads)

Let op: De onderstaande scripts zetten de login en wachtwoord op de standaard die Ubiquiti zelf ook gebruikt (ubnt). Men doet er zeer verstandig deze na de configuratie te wijzigen.

 

EdgeRouter 4

Met telefonie via Experia Box (zip 4 september 2021 16:45). Werkt niet i.c.m. V12 en V14.

Zonder telefonie via Experia Box (zip 18 oktober 2021 15:17).

Als je de TV ontvanger(s) op een apart vlan wilt plaatsen dan kan je één van de onderstaande scripts gebruiken.

Met telefonie via Experia Box en TV via vlan 4 (zip 10 maart 2022 13:47). Werkt niet i.c.m. V12 en V14.

Zonder telefonie via Experia Box en TV via vlan 4 (zip 10 maart 2022 13:47).

Als je één TV ontvanger gebruikt en deze rechtstreeks op de EdgeRouter aan kunt sluiten, gebruik dan het onderstaande script.

Zonder telefonie via Experia Box en eth1 voor TV ontvanger (zip 18 oktober 2021 15:17).

 

De configuratiescripts voor de EdgeRouter 4 zijn ook geschikt voor de EdgeRouter Lite 3 en EdgeRouter 6P. De SFP poort alsmede eth3 en hoger worden in deze scripts niet geconfigureerd, dat kan dan eventueel achteraf handmatig gedaan worden.

 

EdgeRouter 4 - SFP

De onderstaande scripts zijn specifiek voor het gebruik van de SFP poort als WAN poort.

Met telefonie via Experia Box (zip 4 september 2021 18:04). Werkt niet i.c.m. V12 en V14.

Zonder telefonie via Experia Box (zip 4 september 2021 18:04).

Als je de TV ontvanger(s) op een apart vlan wilt plaatsen dan kan je één van de onderstaande scripts gebruiken.

Met telefonie via Experia Box en TV via vlan 4 (zip 10 maart 2022 13:47). Werkt niet i.c.m. V12 en V14.

Zonder telefonie via Experia Box en TV via vlan 4 (zip 10 maart 2022 13:47).

Als je één TV ontvanger gebruikt en deze rechtstreeks op de EdgeRouter aan kunt sluiten, gebruik dan het onderstaande script.

Zonder telefonie via Experia Box en eth1 voor TV ontvanger (zip 18 oktober 2021 15:17).

Als je twee TV ontvangers gebruikt en deze rechtstreeks op de EdgeRouter aan kunt sluiten, gebruik dan het onderstaande script.

Zonder telefonie via Experia Box en eth0/1 voor TV ontvangers (zip 21 december 2021 17:22).

 

De SFP poort zal voorzien moeten zijn van een RJ45 module voor aansluiting op de NTU, ONT of VDSL modem danwel een Fiber module voor een rechtstreekse aansluiting op de FTU.

Let op: De EdgeRouter kan niet rechtstreeks op de FTU aangesloten worden bij XGS-PON aansluitingen. 

 

EdgeRouter X
Met telefonie via Experia Box (zip 4 september 2021 16:45). Werkt niet i.c.m. V12 en V14.

Zonder telefonie via Experia Box (zip 4 september 2021 16:45).

Als je de TV ontvanger(s) op een apart vlan wilt plaatsen dan kan je één van de onderstaande scripts gebruiken.

Met telefonie via Experia Box en TV via vlan 4 op eth2 (zip 22 juli 2022 11:55). Werkt niet i.c.m. V12 en V14.

Zonder telefonie via Experia Box en TV via vlan 4 op eth1 (zip 22 juli 2022 11:55).

Als je één TV ontvanger gebruikt en deze rechtstreeks op de EdgeRouter aan kunt sluiten, gebruik dan de onderstaande scripts.

Met telefonie via Experia Box en eth1 voor TV ontvanger (zip 4 september 2021 16:45). Werkt niet i.c.m. V12 en V14.

Zonder telefonie via Experia Box en eth1 voor TV ontvanger (zip 4 september 2021 16:45).

Als je twee TV ontvangers gebruikt en deze rechtstreeks op de EdgeRouter aan kunt sluiten, gebruik dan het onderstaande script.

Zonder telefonie via Experia Box en eth1/2 voor TV ontvangers (zip 4 september 2021 16:45).

 

De configuratiescripts voor de EdgeRouter X werken ook voor de EdgeRouter 10X, 12 en 12P waarbij eth3 en hoger achteraf handmatig geconfigureerd moeten worden.

 

EdgeRouter X - SFP

De onderstaande scripts zijn specifiek voor het gebruik van de SFP poort als WAN poort.

Met telefonie via Experia Box (zip 4 september 2021 18:06). Werkt niet i.c.m. V12 en V14.

Zonder telefonie via Experia Box (zip 4 september 2021 18:06).

Als je de TV ontvanger(s) op een apart vlan wilt plaatsen dan kan je één van de onderstaande scripts gebruiken.

Met telefonie via Experia Box en TV via vlan 4 op eth1 (zip 22 juli 2022 11:55). Werkt niet i.c.m. V12 en V14.

Zonder telefonie via Experia Box en TV via vlan 4 op eth0 (zip 22 juli 2022 11:55).

 

De SFP poort zal dan dus voorzien moeten zijn van een RJ45 module voor aansluiting op de NTU, ONT of VDSL modem danwel een Fiber module voor een rechtstreekse aansluiting op de FTU.

Let op: De EdgeRouter kan niet rechtstreeks op de FTU aangesloten worden bij XGS-PON aansluitingen. 

 

Heb je vaste telefonie van KPN en wil je jouw Experia Box blijven gebruiken voor telefonie, kies dan voor een configuratiescript "met telefonie via Experia Box". Let op, de V12 is hier niet voor geschikt.

Heb je vaste telefonie van KPN en laat je die via een eigen VoIP ATA lopen, kies dan voor een configuratiescript "zonder telefonie via Experia Box".

Het wachtwoord voor jouw SIP account van je via de SIP service tool instellen.

Zorg er dan tevens voor dat de SIP module op de EdgeRouter gedisabled is.

 

De bovenstaande configuraties zetten IPv6 op de EdgeRouter aan. Mocht het zijn dat op jouw aansluiting IPv6 nog niet volledig operationeel is, dan kan je op de EdgeRouter IPv6 eenvoudig uitzetten (disablen) via de Config Tree -> System -> ipv6.
Druk daartoe op het plusteken naast disable en vervolgens op Preview en Apply.

5072ea1a-b210-40bf-9353-e00794843939.png

Let op: Het uit (of aan) zetten van IPv6 vereist wel dat de EdgeRouter gereboot wordt.

 

Heb je services draaien die je vanaf Internet moet kunnen benaderen, configureer dan de port-forwarding als onderstaand...

...en voeg daarna de benodigde poorten toe met de verwijzing naar het LAN IP adres van het apparaat dat die service levert.

In het onderstaande voorbeeld forward ik OpenVPN naar mijn Synology NAS.


Ubiquiti UniFi Security Gateway: Zie https://www.vanachterberg.org/usg-kpn-ftth/posts/unifi-security-gateway-kpn-ftth-iptv-ipv6/

 

UniFi Dream Machine (Pro), Unifi Gateway Lite/Max en Unfi Cloud Gateway Ultra/Max: Zie https://github.com/fabianishere/udm-iptv

 

OPNsense & pfSense: Zie https://gathering.tweakers.net/forum/list_message/67694326#67694326


DrayTek Vigor: Zie dit bericht.
De DrayTek Vigor brengt het gebruik van een eigen router binnen bereik van de VDSL abonnee en dat is een zeer grote stap voorwaarts, waarvoor dank aan @Pipo10.

 

Synology RT1900ac / RT2600ac / RT6600ax / MR2200ac / WRX560: Zie dit topic

 

TP-Link ER605 v2.0: Zie dit topic.

 

Juniper SRX: Zie dit topic

 

Ik heb mijn EdgeRouter 4 voorzien van een Let's Encrypt SSL certificaat waardoor ik een https verbinding kan opzetten en de uitwisseling van informatie dus encrypted is.

Hiervoor heb ik de github van j-c-m gebruikt en een taak in de task-scheduler geplaatst die om de 14 dagen opgestart wordt om het SSL certificaat te vernieuwen mocht dit nodig zijn.

 

Je hebt wel een url nodig die naar jouw publieke IP adres wijst.

 

Lijst met (modem)routers die succesvol op een KPN aansluiting i.c.m. IPTV in gebruik genomen zijn.

  • EdgeRouter (verschillende typen)
  • UniFi Dream Machine (Pro) / Unifi Dream Router
  • Unifi Gateway Lite
  • FRITZ!Box voorzien van FRITZ!OS 7.13 of hoger
  • Draytek Vigor 2760n, 2865 en 3910 en vast en zeker ook andere (nieuwere) modellen
  • Synology RT1900ac / RT2600ac / RT6600ax / MR2200ac / WRX560
  • TP-Link AX10 hardware versie 1.0. Andere modellen uit de AX serie zouden ook geschikt moeten zijn maar helaas worden er veel problemen gemeld. 
  • TP-Link ER605 v2.0
  • Routers/PC's op basis van RouterOS van Mikrotik
  • Routers/PC's op basis van OPNsense of pfSense

Lijst met modems die op een KPN aansluiting gebruikt kunnen worden.

  • Draytek Vigor 130 of 165/167 in full-bridge-mode. Let op: De Vigor 130 en 165/167 ondersteunen (nog) geen bonding. De Vigor 165 en 167 ondersteunen wel VPlus.
  • Zyxel VMG4005-B50A. Dit modem ondersteunt zowel bonding als VPlus.
  • ZTE H186 DSL NT. Ook dit modem ondersteunt zowel bonding als Vplus.

Ik hoop dat deze lijst steeds langer zal gaan worden, maar staat jouw (modem)router er niet tussen Google dan eerst of er al iemand is die dat apparaat succesvol in gebruik genomen heeft.

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.

 


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.


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. 


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.


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…

 


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?


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. 


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

Die is in ieder geval correct.


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).


...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.


...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.


...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.


...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 ✅


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: ⬇️

 


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.


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). 


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.


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)


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.


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. 


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 :/


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