[KPN Glasvezel] Ervaringen & Discussie - Deel 2 - Internet en hosting

dinsdag 18 september 2018 17:56

Glashart

wimpie007 schreef op dinsdag 18 september 2018 @ 13:15:
[...]

Volgens mij kunnen hackers relatief simpel met mijn externe IP op de inlogpagina van het modem komen
En daarna evt zelf poorten openzetten enzo

Ik verwacht (en mag hopen) dat je standaard alleen van binnenuit op die pagina kan komen, het zou me verbazen als dit via je externe IP mogelijk is.

Dus echt risico heb je niet gelopen denk ik, niet netjes van KPN is het wel om zo even zonder goedkeuring een reset uit te voeren.

Acties:

logix147

wimpie007 schreef op dinsdag 18 september 2018 @ 13:15:
[...]

Volgens mij kunnen hackers relatief simpel met mijn externe IP op de inlogpagina van het modem komen
En daarna evt zelf poorten openzetten enzo

Remote(lees buiten je bestaande netwerk) is in mijn geval, gelukkig voor jou helaas niet zomaar in het modem te komen.

Als je al je hardware aan KPN EB hangt moet je risico’s zoals nieuwe configuratie setup voor lief nemen, is je KPN EB dood, reden onbelangrijk krijg jij een nieuwe box en dus hoogstwaarschijnlijk een ander model; laten die configuratie files niet met elkaar praten. Zelfs de v1 en V2 modellen willen elkaars configuratie files weigeren, guess why het nog niet kan op een consumenten modem.

Tis hier thuis simpel: alles loopt via mijn eigen router en switch, muv 1 TV, 1 PC en dus de router en switch.

Wissel ik van leverancier kan ik hooguit met vlans moeten klojo-en en intern een IP adres aan mijn router moeten toewijzen maar dat is 2 tellen werk vs een goed kwartier en dan heb ik het nog niet over dat KPN maar bijv 10 DHCP bindings toestaat, geen remote inloggen (zonder behulp van randapparatuur lukt dit je gewoon niet of sta je heel snel in quarantaine)

Wat betreft je hardware (achter een modem) kunnen uitlezen is dat niets bezonders, elk apparaat geeft veelal een tip mee van wat het is, dit kan <insert provider> helpen met troubleshooten. Met bijv een dubbele NAT, dchp problemen etc dat deze provider dat niet support is omdat je er niet voor betaald voor dat soort uitgebreider dienstverlening. Dat heet xs4all

dinsdag 18 september 2018 18:15

Acties:

vr6-only

Blub Blub

wimpie007 schreef op dinsdag 18 september 2018 @ 13:15:
[...]

Volgens mij kunnen hackers relatief simpel met mijn externe IP op de inlogpagina van het modem komen
En daarna evt zelf poorten openzetten enzo

Nee, dat kan dus niet. Beter nog, remote inloggen is zelfs uit het menu gehaald in de KPN firmware. In de Telfort en NLE versies kun je als gebruiker ook remote inloggen aanzetten.

Daarnaast is de Experiabox standaard ingesteld als:
- Wachtwoord op WiFi;
- UPnP op uit.

Dus hoe jij bij je verhaal komt van "open" modem verbaast mij. Doet verder niets af aan je verhaal dat het zonder toestemming niet mag. Maar de gevolgen zijn verre van hetgeen dat jij omschrijft.

Daarnaast heeft de medewerker niet gelogen, maar het verhaal niet volledig verteld. Configuraties worden inderdaad automatisch teruggezet bij een reset als de gebruiker ooit eens gebruik heeft gemaakt van de KPN Servicetool. Daarmee kan je dus zelfs overschakelen naar een andere type Experiabox en dan nog heb je jouw gegevens terug, zoals port forwarding en WiFi wachtwoord.

It ain't stupid if it works!

dinsdag 18 september 2018 19:49

Acties:

Fonta

Het grote gros aan internetgebruikers doet helemaal niets aan de instellingen van de router en dus zou het betekenen dat bijna het hele internet open staat.
Tuurlijk is dit niet zo. We leven niet meer in 1990.
Een modem met default config is helemaal zo onveilig nog niet.
Buiten het feit dat het vervelend is dat de instellingen in dit geval weg zijn, is het een open modem noemen overtrokken.
Je kan je daarnaast ook afvragen of je zoveel instellingen wilt doen op een modem die je in bruikleen hebt.

woensdag 19 september 2018 19:20

Acties:

droner

Fonta schreef op dinsdag 18 september 2018 @ 19:49:
Je kan je daarnaast ook afvragen of je zoveel instellingen wilt doen op een modem die je in bruikleen hebt.

Vreemde denkwijze; je moet de techniek m.i. laten werken conform je behoeften, de vraag of die techniek in eigen bezit is of niet is daarbij m.i. niet echt van belang - als je er afhankelijk van bent is dat waar je het mee moet doen.

Dat gezegd hebbende, iemand enig idee hoe ik de EB (v10a) (WiFi) instellingen zo aan kan passen dat ik Blokada kan draaien op m'n Android telefoontje?
Al eerder genoemd zonder antwoord, misschien dat wat extra info helpt: als ik Blokada aanzet (default DNS) werken een hoop apps (bijv. de NU app) niet meer - de NU app geeft de melding dat de verbinding verbroken is. Achter de EB heb ik nog een klein routertje hangen wat een ander WiFi netwerkje maakt (zonder specifieke port forwarding instellingen), als ik met exact dezelfde Android instellingen daarmee verbinding maak werkt alles wel okee. Ergo: op 1 of andere manier wordt Blokada door de EB gebloka, ik bedoel geblokkeerd en dat is natuurlijk niet de bedoeling. Je zou kunnen zeggen: verbind dan met dat andere routertje, maar dat zorgt voor goed bereik in een andere uithoek van het huis, ik wil dus beide kunnen gebruiken. EB instellingen gecheckt maar zie daar niets wat e.e.a. kan verklaren.

[ Voor 51% gewijzigd door droner op 20-09-2018 13:51 ]

vrijdag 21 september 2018 21:44

Acties:

jacovn

Ik ga verhuizen en je moet blijkbaar alles meenemen inclusief de experiabox (we verhuizen paar honderd meter) geluikig geen experia v10a dus..
Het installatie pakket zou alleen een boekje worden

Maar ze sturen wel een monteur om het aan te sluiten (geen kosten)
Er zal toch wel eerst iemand komen om op de glas aansluiting een ding te plaatsen ? Alleen reggefiber is nu geweest.
Ziggo heb ik gelukkig niet gezien, coax spullen zijn wel door baas bv achtergelaten voor ziggo.

Kan ik die monteur mooi wifi door heel het huis in orde laten maken

Hoef ik minder haast te maken met de unifi setup.

[ Voor 11% gewijzigd door jacovn op 21-09-2018 21:45 ]

8x330 NO12.5°, 8x330 ZW12.5°, 8x350 ZW60°, 8x325 NO10°, SE8K, P500. 6x410 ZW10° Enphase

vrijdag 21 september 2018 23:40

Acties:

mad-dog

Glasvezel
KPN

jacovn schreef op vrijdag 21 september 2018 @ 21:44:
Ik ga verhuizen en je moet blijkbaar alles meenemen inclusief de experiabox (we verhuizen paar honderd meter) geluikig geen experia v10a dus..
Het installatie pakket zou alleen een boekje worden

Maar ze sturen wel een monteur om het aan te sluiten (geen kosten)
Er zal toch wel eerst iemand komen om op de glas aansluiting een ding te plaatsen ? Alleen reggefiber is nu geweest.
Ziggo heb ik gelukkig niet gezien, coax spullen zijn wel door baas bv achtergelaten voor ziggo.

Kan ik die monteur mooi wifi door heel het huis in orde laten maken
Hoef ik minder haast te maken met de unifi setup.

Montage van de NTU wordt door monteur gedaan

zaterdag 22 september 2018 12:56

Acties:

rutger_ellen

droner schreef op woensdag 19 september 2018 @ 19:20:
[...]

Dat gezegd hebbende, iemand enig idee hoe ik de EB (v10a) (WiFi) instellingen zo aan kan passen dat ik Blokada kan draaien op m'n Android telefoontje?
Al eerder genoemd zonder antwoord, misschien dat wat extra info helpt: als ik Blokada aanzet (default DNS) werken een hoop apps (bijv. de NU app) niet meer - de NU app geeft de melding dat de verbinding verbroken is. Achter de EB heb ik nog een klein routertje hangen wat een ander WiFi netwerkje maakt (zonder specifieke port forwarding instellingen), als ik met exact dezelfde Android instellingen daarmee verbinding maak werkt alles wel okee. Ergo: op 1 of andere manier wordt Blokada door de EB gebloka, ik bedoel geblokkeerd en dat is natuurlijk niet de bedoeling. Je zou kunnen zeggen: verbind dan met dat andere routertje, maar dat zorgt voor goed bereik in een andere uithoek van het huis, ik wil dus beide kunnen gebruiken. EB instellingen gecheckt maar zie daar niets wat e.e.a. kan verklaren.

Misschien een IPv6 probleem, je EB geeft een IPv6 adres uit, je routertje potentieel niet

zaterdag 22 september 2018 13:10

Acties:

droner

rutger_ellen schreef op zaterdag 22 september 2018 @ 12:56:
[...]Misschien een IPv6 probleem, je EB geeft een IPv6 adres uit, je routertje potentieel niet

Bedankt, goeie suggestie! Een checkje leert dat Blokada daar inderdaad issues mee lijkt te hebben.

maandag 24 september 2018 07:29

Acties:

Damien

-iwnl-

Zijn er meer mensen die de afgelopen weken hele korte interupts in hun verbinding waarnemen? Ik heb zelf 500/500 maar de afgelopen weken heb ik om de zoveel minuten een heel korte timeout. In een spel als WoW sta je heel even stil terwijl discord bijvoorbeeld gewoon door gaat.

Ik had al en de router gekeken maar ik zie niets vreemds.

A wise man can learn more from his enemies than a fool from his friends.

maandag 24 september 2018 08:04

Acties:

Tylen

Dutch ProClass 1000 #56 ⭐⭐⭐⭐⭐

Damien schreef op maandag 24 september 2018 @ 07:29:
Zijn er meer mensen die de afgelopen weken hele korte interupts in hun verbinding waarnemen? Ik heb zelf 500/500 maar de afgelopen weken heb ik om de zoveel minuten een heel korte timeout. In een spel als WoW sta je heel even stil terwijl discord bijvoorbeeld gewoon door gaat.

Ik had al en de router gekeken maar ik zie niets vreemds.

Nergens last van. Speel je via wifi of bedraad?

“Choose a job you love, and you will never have to work a day in your life.”

maandag 24 september 2018 08:19

Acties:

Damien

-iwnl-

Tylen schreef op maandag 24 september 2018 @ 08:04:
[...]

Nergens last van. Speel je via wifi of bedraad?

Goede vraag, had ik er inderdaad even bij moeten vermelden. Ja ik speel bedraad met daartussen nog een switch.

En als toevoeging:

Gisteren ook Rainbow Six: Siege geprobeerd en ik ondervind daar zelfs een disconnect om de zoveel minuten. Ongeveer 2 potjes kan ik spelen en dan vliegt de verbinding er ongeveer 30 seconden uit. Ik heb nog geen contact gehad met KPN zelf omdat ik de situatie wel willen kunnen reproduceren.

[ Voor 35% gewijzigd door Damien op 24-09-2018 08:22 ]

A wise man can learn more from his enemies than a fool from his friends.

zondag 30 september 2018 11:13

Acties:

drstift

Ik ben helemaal klaar met die wifi van kpn. Heb eb10 en 2 kpn wifi versterkers. Continu wegvallende wifi signalen op macbook en iphones.
Gisteren 2 tplink c1200 gekocht, wifi uitgezet op de eb en alles werkt als een zonnetje.

zondag 30 september 2018 11:42

Acties:

Korvaag

Versterkers werken ook voor geen meter. Je moet ze bedraad inzetten als AP's, dan gaat het prima. Geldt overigens voor bijna elke versterker.

UNOX: The worst operating system

zondag 30 september 2018 12:52

Acties:

AvK

Ready Set Go

drstift schreef op zondag 30 september 2018 @ 11:13:
Ik ben helemaal klaar met die wifi van kpn. Heb eb10 en 2 kpn wifi versterkers. Continu wegvallende wifi signalen op macbook en iphones.
Gisteren 2 tplink c1200 gekocht, wifi uitgezet op de eb en alles werkt als een zonnetje.

Lijkt me dat je iets niet goed doet of fout geconfigd hebt.
Draait hier al jaren prima. Wie er ook komt of met welk apparaat dan ook. iOS of Android, laptops, Macbooks... Geen enkel probleem.
Inderdaad wat Korvaag zegt. Heb je de boel wel bedraad aangesloten?

AopenHX08 ZM400B Athlon64-X2-3800+ ArticFreezer64pro Asrock939Dual-Sata2 2x512MbDDR400 GigabyteR9700pro SBAudigy2 Inspire6700modded PCTVpro ADSL 6Mb/768 NEC2500a Pioneer105DVDrom iiyamaVMPro450 CanonIP4000 LogitechG5 200GbWD7200 80GbWD7200 WinXPhome

zondag 30 september 2018 13:22

Acties:

Barre73

Glasvezel
Isp
Experiabox
KPN
Fiber
Glashart
Reggefiber

drstift schreef op zondag 30 september 2018 @ 11:13:
Ik ben helemaal klaar met die wifi van kpn. Heb eb10 en 2 kpn wifi versterkers. Continu wegvallende wifi signalen op macbook en iphones.
Gisteren 2 tplink c1200 gekocht, wifi uitgezet op de eb en alles werkt als een zonnetje.

Dus je hebt twee routers van ieder 60 euro gekocht om als AP te gebruiken. In plaats van een echte AP te kopen.
Vreemde redenering...

Geen ongevraagde verzoeken via DM svp.

zondag 30 september 2018 18:45

Acties:

krakendmodem

Experiabox
KPN

drstift schreef op zondag 30 september 2018 @ 11:13:
Ik ben helemaal klaar met die wifi van kpn. Heb eb10 en 2 kpn wifi versterkers. Continu wegvallende wifi signalen op macbook en iphones.
Gisteren 2 tplink c1200 gekocht, wifi uitgezet op de eb en alles werkt als een zonnetje.

Niet om te ranten hoor, maar ik heb ook wel eens problemen gehad met wifi en bleek het dus aan de iPhones en MacBooks te liggen, alle andere toestellen werkte er zonder problemen op, maar de Apple apparaten niet.

Na vervangen van de router was dat ook opgelost. Misschien ligt het daar aan. Misschien ook niet. De wifi versterkers van KPN zijn voor die 50 euro echt niet slecht namelijk.

zondag 30 september 2018 20:25

Acties:

Miki

Ik heb hier 3 KPN WiFi versterkers in een vrijwel Apple only huis dus ik vermoed dat het om een defect model gaat. Het is hier namelijk 24/7 al ruim een jaar stabiel.

zondag 30 september 2018 23:00

Acties:

drstift

AvK schreef op zondag 30 september 2018 @ 12:52:
[...]

Lijkt me dat je iets niet goed doet of fout geconfigd hebt.
Draait hier al jaren prima. Wie er ook komt of met welk apparaat dan ook. iOS of Android, laptops, Macbooks... Geen enkel probleem.
Inderdaad wat Korvaag zegt. Heb je de boel wel bedraad aangesloten?

Zeker bedraad; Het heeft (bedraad) ook ca 2 jaar prima gewerkt. Problemen zijn eind 2017 begonnen. Heb vanalles geprobeerd te wisselen. EB10 wifi aan/uit, wifi versterkers aan/uit. Kon uiteindelijk zijn TP link lenen van iemand en daarmee werkte alles goed. Vandaar mijn aankoop van dit product. Heb zelf het vermoeden dat de EB het moeilijk heeft met apple...

maandag 1 oktober 2018 17:14

Acties:

dewaal

drstift schreef op zondag 30 september 2018 @ 11:13:
Ik ben helemaal klaar met die wifi van kpn. Heb eb10 en 2 kpn wifi versterkers. Continu wegvallende wifi signalen op macbook en iphones.
Gisteren 2 tplink c1200 gekocht, wifi uitgezet op de eb en alles werkt als een zonnetje.

Je kan beter een eigen wifi/router kopen en deze als accesspoint inrichten dan weet je zeker dat alles goed werkt.

maandag 1 oktober 2018 17:59

Acties:

maandag 1 oktober 2018 19:58

Ik ben inmiddels ook klaar met de wifi van de EB v10a...

Vaak werkt het allemaal prima, maar soms kan ik ineens niet meer streamen, casten naar de chromecast, of fatsoenlijk surfen op mijn tablet en telefoon. Een tijd(je) later werkt alles ineens weer als een tierelier...

Dit is volledig willekeurig, ik heb de afgelopen maanden geen enkele oorzaak of reden hiervoor kunnen vinden.
Net heb ik alle wifi instellingen op de EB gereset, en daarna uitgezet. Basta.

Dalijk ga ik maar eens rondsnuffelen op het web naar een goede accesspoint.

Acties:

MadMarky

Begint eer ge bezint

Zijn er meer mensen die problemen hebben met Terugkijken?
Sinds vandaag heb ik vanuit de programmagids alleen nog de Begin Gemist functie. Als ik vervolgens via het hoofdmenu naar de Terugkijken pagina gaat staat bij alle programma's van de afgelopen week in een grijze balk dat ik ze helaas niet terug kan kjken.
Is dit een storing of is er iets anders aan de hand? Heb trouwens een Basis abo.

edit:
Na de ontvanger een keer gereset te hebben werkte alles weer als vanouds. Raarrr...

[ Voor 11% gewijzigd door MadMarky op 01-10-2018 22:33 ]

🖥️ | 🚗

dinsdag 2 oktober 2018 12:46

Acties:

dinsdag 2 oktober 2018 13:23

Hmm, ik heb sinds deze storing van gisteren nog steeds last van problemen met terugkijken. Reboot van router en kastje helpen niet.

Wij gebruiken een eigen router - is er iemand aware van wijzigingen in de IGMP settings? De storing (3 sec beeld, dat stopt dan, daarna foutmelding) lijken heel erg op IGMP problemen.

Sometimes you need to plan for coincidence

Acties:

dinsdag 2 oktober 2018 13:32

Glashart

Hmmbob schreef op dinsdag 2 oktober 2018 @ 12:46:
Hmm, ik heb sinds deze storing van gisteren nog steeds last van problemen met terugkijken. Reboot van router en kastje helpen niet.

Wij gebruiken een eigen router - is er iemand aware van wijzigingen in de IGMP settings? De storing (3 sec beeld, dat stopt dan, daarna foutmelding) lijken heel erg op IGMP problemen.

KPN heeft vannacht inderdaad wijzigingen doorgevoerd in de gebruikte IP range voor de multicast streams, dat merkte ik vanochtend ook doordat ITV via mijn eigen router niet meer werkte (inderdaad met de symptomen zoal jij beschrijft).

Oplossing is om de nieuwe IP reeks (217.166.0.0/16) toe te voegen aan IGMPProxy configuratie als upstream netwerk en te zorgen dat je op de ITV WAN interface UDP verkeer vanaf deze reeks naar 224.0.0.0/4 toe gaat staan.

Bij mij werkt alles nu weer prima

Acties:

wouter2512

ik222 schreef op dinsdag 2 oktober 2018 @ 13:23:
[...]

KPN heeft vannacht inderdaad wijzigingen doorgevoerd in de gebruikte IP range voor de multicast streams, dat merkte ik vanochtend ook doordat ITV via mijn eigen router niet meer werkte (inderdaad met de symptomen zoal jij beschrijft).

Oplossing is om de nieuwe IP reeks (217.166.0.0/16) toe te voegen aan IGMPProxy configuratie als upstream netwerk en te zorgen dat je op de ITV WAN interface UDP verkeer vanaf deze reeks naar 224.0.0.0/4 toe gaat staan.

Bij mij werkt alles nu weer prima

$_/-\o_$ Held! $_/-\o_$
Was hier ook al een tijdje aan het debuggen. Maar aangezien ik niet veel kaas heb gegeten van IGMP vorderde het nog niet echt. Na het toevoegen van bovenstaande range werkte het meteen!

Voor EdgeRouters (uitgaande van KPN glas op eth0):

code:

1	admin@erl3# set protocols igmp-proxy interface eth0.4 alt-subnet 217.166.0.0/16

Edit: minor typo

dinsdag 2 oktober 2018 13:33

Acties:

dinsdag 2 oktober 2018 14:00

ik222 schreef op dinsdag 2 oktober 2018 @ 13:23:
[...]

KPN heeft vannacht inderdaad wijzigingen doorgevoerd in de gebruikte IP range voor de multicast streams, dat merkte ik vanochtend ook doordat ITV via mijn eigen router niet meer werkte (inderdaad met de symptomen zoal jij beschrijft).

Oplossing is om de nieuwe IP reeks (217.166.0.0/16) toe te voegen aan IGMPProxy configuratie als upstream netwerk en te zorgen dat je op de ITV WAN interface UDP verkeer vanaf deze reeks naar 224.0.0.0/4 toe gaat staan.

Bij mij werkt alles nu weer prima

HELD!

Sometimes you need to plan for coincidence

Acties:

mr.DJ95

Damien schreef op maandag 24 september 2018 @ 07:29:
Zijn er meer mensen die de afgelopen weken hele korte interupts in hun verbinding waarnemen? Ik heb zelf 500/500 maar de afgelopen weken heb ik om de zoveel minuten een heel korte timeout. In een spel als WoW sta je heel even stil terwijl discord bijvoorbeeld gewoon door gaat.

Ik had al en de router gekeken maar ik zie niets vreemds.

Ik zie wel vreemde spikes in de log die ik heb met speedtest.

Afbeeldingslocatie: https://i.imgur.com/5ESJgVj.png

Afbeeldingslocatie: https://i.imgur.com/4aM96k3.png

dinsdag 2 oktober 2018 14:16

Acties:

Zapp-it

ik222 schreef op dinsdag 2 oktober 2018 @ 13:23:
[...]

KPN heeft vannacht inderdaad wijzigingen doorgevoerd in de gebruikte IP range voor de multicast streams, dat merkte ik vanochtend ook doordat ITV via mijn eigen router niet meer werkte (inderdaad met de symptomen zoal jij beschrijft).

Oplossing is om de nieuwe IP reeks (217.166.0.0/16) toe te voegen aan IGMPProxy configuratie als upstream netwerk en te zorgen dat je op de ITV WAN interface UDP verkeer vanaf deze reeks naar 224.0.0.0/4 toe gaat staan.

Bij mij werkt alles nu weer prima

https://ipinfo.io/AS1136/217.166.0.0/17

dinsdag 2 oktober 2018 14:35

Acties:

dinsdag 2 oktober 2018 14:49

Glashart

Zapp-it schreef op dinsdag 2 oktober 2018 @ 14:16:
[...]

https://ipinfo.io/AS1136/217.166.0.0/17

Ja, als je naar die link kijkt zie je dat het onderdeel is van de genoemde /16, route object is ook voor de /16. Maar het subnet kan inderdaad nog wel kleiner als je kijkt wat daadwerkelijk gebruikt wordt maar dat was bij het vorige subnet (213.75.0.0/16) ook zo en het heeft hier niet veel voordelen om het zo strak mogelijk te configureren naar mijn mening. In de IGMPProxy configuratie sowieso niet en in je firewall regels eigenlijk ook niet in de praktijk omdat je het verkeer toch enkel toe staat met als destination de multicast adressen.

[ Voor 4% gewijzigd door ik222 op 02-10-2018 14:36 ]

Acties:

Zapp-it

ik222 schreef op dinsdag 2 oktober 2018 @ 14:35:
[...]

Ja, als je naar die link kijkt zie je dat het onderdeel is van de genoemde /16, route object is ook voor de /16. Maar het subnet kan inderdaad nog wel kleiner als je kijkt wat daadwerkelijk gebruikt wordt maar dat was bij het vorige subnet (213.75.0.0/16) ook zo en het heeft hier niet veel voordelen om het zo strak mogelijk te configureren naar mijn mening. In de IGMPProxy configuratie sowieso niet en in je firewall regels eigenlijk ook niet in de praktijk omdat je het verkeer toch enkel toe staat met als destination de multicast adressen.

Just talking

Ik had eerst een subnet ingesteld van /22 (uit mijn hoofd) maar ik dacht laat ik is eens zoeken wat het subnet zou zijn op internet en daar kwam ik op de /17 uit

Ik zelf hou ervan om mijn vuurmuur strak in te regelen maar meningen verschillen gelukkig maar. Ik had de link geplaatst FYI

dinsdag 2 oktober 2018 15:59

Acties:

dinsdag 2 oktober 2018 16:07

ik222 schreef op dinsdag 2 oktober 2018 @ 14:35:
[...]

Ja, als je naar die link kijkt zie je dat het onderdeel is van de genoemde /16, route object is ook voor de /16. Maar het subnet kan inderdaad nog wel kleiner als je kijkt wat daadwerkelijk gebruikt wordt maar dat was bij het vorige subnet (213.75.0.0/16) ook zo en het heeft hier niet veel voordelen om het zo strak mogelijk te configureren naar mijn mening. In de IGMPProxy configuratie sowieso niet en in je firewall regels eigenlijk ook niet in de praktijk omdat je het verkeer toch enkel toe staat met als destination de multicast adressen.

Maare, hoe ben je eigenlijk achter de gewijzigde range gekomen?

Ik had zelf vrij snel in de gaten waar de problemen zaten, maar de exacte range.....

Sometimes you need to plan for coincidence

Acties:

Cyberpope

When does the hurting stop??

ik222 schreef op dinsdag 2 oktober 2018 @ 13:23:
[...]

KPN heeft vannacht inderdaad wijzigingen doorgevoerd in de gebruikte IP range voor de multicast streams, dat merkte ik vanochtend ook doordat ITV via mijn eigen router niet meer werkte (inderdaad met de symptomen zoal jij beschrijft).

Oplossing is om de nieuwe IP reeks (217.166.0.0/16) toe te voegen aan IGMPProxy configuratie als upstream netwerk en te zorgen dat je op de ITV WAN interface UDP verkeer vanaf deze reeks naar 224.0.0.0/4 toe gaat staan.

Bij mij werkt alles nu weer prima

Ik heb een asus router ingesteld met het script dat je hier op T.net kunt vinden.
Moet ik ook nog iets doen en zoja hoe doe je dat?

With so many things coming back in style, I can't wait till loyalty, intelligence and morals become a trend again.......

dinsdag 2 oktober 2018 16:23

Acties:

dinsdag 2 oktober 2018 18:13

Glashart

Hmmbob schreef op dinsdag 2 oktober 2018 @ 15:59:
[...]
Maare, hoe ben je eigenlijk achter de gewijzigde range gekomen?

Ik had zelf vrij snel in de gaten waar de problemen zaten, maar de exacte range.....

De logs bekijken, die zijn vaak je vriend bij het debuggen van een issue. Daar zag ik dus nu vanaf welke source ip's nu eerst verkeer gedropt werd door de firewall en na het oplossen daarvan melde IGMPProxy in zijn logs dat hij verkeer binnenkreeg van adressen welke niet in de upstream newerken gedefinieerd waren.

En hoe je dan het subnet bepaald, dat doe ik dus door te kijken naar de adressen in de logs en bijvoorbeeld door een whois te doen van zo'n adres en te kijken bij welk blok dit hoort. Natuurlijk kan het ook nog zo zijn dat er meerdere losse blokken zijn maar daar kom je dan weer vanzelf achter als er nog steeds dingen niet werken met bijbehorende log meldingen.

Cyberpope schreef op dinsdag 2 oktober 2018 @ 16:07:
[...]

Ik heb een asus router ingesteld met het script dat je hier op T.net kunt vinden.
Moet ik ook nog iets doen en zoja hoe doe je dat?

Je bedoelt deze neem ik aan: [KPN Glasvezel] Een eigen Asus router gebruiken. Even snel gekeken maar zo te zien zetten ze daar al gewoon 0.0.0.0/0 als upstream netwerk op de VLAN4 interface en worden er totaal geen firewall regels geconfigureerd voor VLAN 4. Of dat de beste (veilige) setup is kun je je afvragen maar die aanpak betekent wel dat je voor een wijziging zoals die van afgelopen nacht niets hoeft aan te passen in je configuratie. Ik ga er dus vanuit dat het bij jou gewoon nog werkt.

Acties:

tomdh76

wouter2512 schreef op dinsdag 2 oktober 2018 @ 13:32:
[...]

Held!
Was hier ook al een tijdje aan het debuggen. Maar aangezien ik niet veel kaas heb gegeten van IGMP vorderde het nog niet echt. Na het toevoegen van bovenstaande range werkte het meteen!

Voor EdgeRouters (uitgaande van KPN glas op eth0):
code:
1
admin@erl3# set protocols igmp-proxy interface eth0.4 alt-subnet 217.166.0.0/16
Edit: minor typo

Dank ! Kan er ook nog een upstream ip address nu gedelete worden uit de igmp proxy config?

dinsdag 2 oktober 2018 18:20

Acties:

vSphere/ESXi

tomdh76 schreef op dinsdag 2 oktober 2018 @ 18:13:
[...]

Dank ! Kan er ook nog een upstream ip address nu gedelete worden uit de igmp proxy config?

Je 10.x hoeft niet in de upstream en er hoeft niets in de downstream (alleen een interface).

[ Voor 8% gewijzigd door |sWORDs| op 02-10-2018 18:24 ]

dinsdag 2 oktober 2018 18:41

Acties:

dinsdag 2 oktober 2018 18:54

Glashart

En de oude 213.75 range zou nu in principe ook weg kunnen. Maar heb hem zelf nog even laten staan, de wijziging zou in theorie ook tijdelijk kunnen zijn namelijk.

Edit: Klopt niet, oude reeks is ook nog in gebruik.

[ Voor 16% gewijzigd door ik222 op 02-10-2018 19:08 ]

Acties:

dinsdag 2 oktober 2018 19:07

ik222 schreef op dinsdag 2 oktober 2018 @ 18:41:
En de oude 213.75 range zou nu in principe ook weg kunnen. Maar heb hem zelf nog even laten staan, de wijziging zou in theorie ook tijdelijk kunnen zijn namelijk.

Niet weggooien.

Dat is nog steeds een upstream voor metadata (updates, epg, kanalen). Die lijkt in ieder geval nog steeds gebruikt te worden (zie join op 224.3.2.6).

Als je deze range er nu uitgooit dan verwacht ik dat er zaken spoedig stukgaan. Je moet de nieuwe range dus toevoegen en niet vervangen.

Ik ken Ubiquiti niet, maar ik vraag me af of deze oplossing dus wel klopt:

wouter2512 in "[KPN Glasvezel] Ervaringen & Discussie - Deel 2"

Acties:

dinsdag 2 oktober 2018 19:10

Op mijn Mikrotik kon ik de range probleemloos toevoegen naast de oude, dat werkt prima.

Sometimes you need to plan for coincidence

Acties:

dinsdag 2 oktober 2018 19:57

Glashart

Thralas schreef op dinsdag 2 oktober 2018 @ 18:54:
[...]

Niet weggooien.

Dat is nog steeds een upstream voor metadata (updates, epg, kanalen). Die lijkt in ieder geval nog steeds gebruikt te worden (zie join op 224.3.2.6).

Als je deze range er nu uitgooit dan verwacht ik dat er zaken spoedig stukgaan. Je moet de nieuwe range dus toevoegen en niet vervangen.

Ik ken Ubiquiti niet, maar ik vraag me af of deze oplossing dus wel klopt:

wouter2512 in "[KPN Glasvezel] Ervaringen & Discussie - Deel 2"

Je hebt gelijk, zag dat vanochtend niet direct maar ik zie nu ook nog steeds meerdere joins en verkeer vanuit de oude reeks inderdaad. Je hebt dus inderdaad gewoon beide subnets nodig in de IGMPProxy upstream en in eventuele firewall regels nu.

Acties:

Tom Paris

Zapp-it schreef op dinsdag 2 oktober 2018 @ 14:49:
[...]

Just talking
Ik had eerst een subnet ingesteld van /22 (uit mijn hoofd) maar ik dacht laat ik is eens zoeken wat het subnet zou zijn op internet en daar kwam ik op de /17 uit

Ik zelf hou ervan om mijn vuurmuur strak in te regelen maar meningen verschillen gelukkig maar. Ik had de link geplaatst FYI

Op 217.166.0.0/17 werkt het niet bij mij, /16 wel.

Ik denk dat het 217.166.128.0/17 moet zijn, zie RIPE.

[ Voor 14% gewijzigd door Tom Paris op 02-10-2018 20:06 ]

Veuillez agréer, Madame, Monsieur, l'expression de mes sentiments distingués.

dinsdag 2 oktober 2018 20:18

Acties:

dinsdag 2 oktober 2018 20:24

Glashart

De IP's die ik tot nu toe daadwerkelijk gebruikt heb zien worden komen allemaal uit 217.166.225.0/24 om precies te zijn. Dus nee 217.166.0.0/17 zal inderdaad niet werken want dan valt die /24 die je zeker nodig hebt er niet onder, 217.166.128.0/17 dus wel inderdaad.

Maar goed zoals eerder gezegd, ik zou lekker de hele /16 in de upstream en in eventuele firewall regels zetten.

Acties:

Tom Paris

ik222 schreef op dinsdag 2 oktober 2018 @ 20:18:
De IP's die ik tot nu toe daadwerkelijk gebruikt heb zien worden komen allemaal uit 217.166.225.0/24 om precies te zijn. Dus nee 217.166.0.0/17 zal inderdaad niet werken want dan valt die /24 die je zeker nodig hebt er niet onder, 217.166.128.0/17 dus wel inderdaad.

Maar goed zoals eerder gezegd, ik zou lekker de hele /16 in de upstream en in eventuele firewall regels zetten.

Ik zie ook 217.166.226.0/24 aan mijn kant. Eens dat een /16 simpel is, maar ik zet ook liever de deur wat minder wijd open. We blijven toch Tweakers...

Veuillez agréer, Madame, Monsieur, l'expression de mes sentiments distingués.

dinsdag 2 oktober 2018 20:44

Acties:

dinsdag 2 oktober 2018 21:31

Glashart

Dat is altijd een goed streven maar filteren op de /16 subnets is echt veilig genoeg in dit geval. Het ITV netwerk is namelijk een private netwerk waar alle klanten een 10.x.x.x IP krijgen. Alle publieke adressen die hier routing technisch überhaupt bij kunnen komen zullen dus hoe dan ook van het platform zijn. Dus dit verder inperken voegt niets toe.

Waar je wel zeker van wilt zijn is dat andere klanten nooit in jou netwerk (of router) kunnen komen vanaf dit private netwerk. Nou neem ik aan dat KPN daar ook al in het netwerk voor zorgt maar ik wil daar niet volledig afhankelijk van zijn. Zelf sta ik daarom vanuit 10.0.0.0/8 alleen de echt benodigde IGMP pakketten toe.

Dat laatste is dus de reden waarom ik die eerder genoemde Asus configuratie niet optimaal vind, daar wordt namelijk niets gefilterd.

Acties:

dinsdag 2 oktober 2018 21:36

Tom Paris schreef op dinsdag 2 oktober 2018 @ 20:24:
Ik zie ook 217.166.226.0/24 aan mijn kant. Eens dat een /16 simpel is, maar ik zet ook liever de deur wat minder wijd open. We blijven toch Tweakers...

Een heel rondje door alle zenders (zonder pluspakketten) geeft 217.166.22[456].0/24.

Nog pragmatischer, volgens mij kun je gewoon 0.0.0.0/0 invullen. Het is een proxy, geen firewall.

Ik zou verder gewoon firewallen op interface en destination 224.0.0.0/8 voor IGMP/UDP. Zonder IGMP join is er toch geen verkeer; waar het vandaan komt boeit niet.

Acties:

Zapp-it

Tom Paris schreef op dinsdag 2 oktober 2018 @ 19:57:
[...]

Op 217.166.0.0/17 werkt het niet bij mij, /16 wel.

Ik denk dat het 217.166.128.0/17 moet zijn, zie RIPE.

Yep, je hebt gelijk, de 217.166.0.0/17 werkt ook bij mij niet maar de 217.166.128.0/17 wel. Ik was net thuis zodat ik het kon testen maar thanxs voor de input!

woensdag 3 oktober 2018 00:19

Acties:

vSphere/ESXi

Thralas schreef op dinsdag 2 oktober 2018 @ 21:31:
[...]

Een heel rondje door alle zenders (zonder pluspakketten) geeft 217.166.22[456].0/24.

Nog pragmatischer, volgens mij kun je gewoon 0.0.0.0/0 invullen. Het is een proxy, geen firewall.

Ik zou verder gewoon firewallen op interface en destination 224.0.0.0/8 voor IGMP/UDP. Zonder IGMP join is er toch geen verkeer; waar het vandaan komt boeit niet.

Klinkt als 217.166.224.0/22.

Dan krijg je dus zoiets:
Afbeeldingslocatie: https://i.postimg.cc/RhYRwQKg/Screen_Shot_2018-10-03_at_10.16.57_AM.png

Alias:

Afbeeldingslocatie: https://i.postimg.cc/Hs70fMQC/Screen_Shot_2018-10-03_at_10.15.14_AM.png

IPTV rules:
Afbeeldingslocatie: https://i.postimg.cc/J4J6jvYJ/Screen_Shot_2018-10-03_at_10.15.51_AM.png

STB network rules:
Afbeeldingslocatie: https://i.postimg.cc/MZfd8gS4/Screen_Shot_2018-10-03_at_10.16.23_AM.png

[ Voor 29% gewijzigd door |sWORDs| op 03-10-2018 10:20 ]

donderdag 4 oktober 2018 16:30

Acties:

donderdag 4 oktober 2018 23:56

sinds we bij kpn zitten ( afgelopen december ) hebben we een irritant probleem wat we bij ziggo nooit hebben gehad namelijk dat de internet verbinding regelmatig ( paar keer per dag ) voor een aantal seconden tot een minuut weg valt....

kpn heeft al een paar keer de lijn doorgemeten en niks geks kunnen vinden,ookal een keer de modem gereset etc,

dit gebeurd in chrome maar ook in firefox en internet explorer,

met wifi hebben we nergens last van.

dit probleem speelt zich af op zowel mijn pc als de laptop van mijn moeder.

( netflix kijken via de mediabox van kpn geeft ook dit probleem een aantal keer per avond )

kpn wilt wel een monteur vinden maar als het dan aan onze kant ligt mogen we gaan betalen....

we hebben al een aantal keer nieuwe kabels geprobeerd maar ook dit mag niet helpen.

ik vraag mij toch echt af hoe dit kan.

in december loopt het contract af,misschien maar naar xs4all gaan ofzo want dit is niet leuk meer.

[ Voor 5% gewijzigd door joey82 op 04-10-2018 16:31 ]

Acties:

White_Collar

Reggefiber

@joey82 zou je netwerk eens willen uittekenen?

Wellicht heb je een brakke switch in je netwerk staan die de boel verstoord.

"The reason for time is so that everything doesn't happen at once"

vrijdag 5 oktober 2018 10:45

Acties:

vrijdag 5 oktober 2018 10:54

White_Collar schreef op donderdag 4 oktober 2018 @ 23:56:
@joey82 zou je netwerk eens willen uittekenen?

Wellicht heb je een brakke switch in je netwerk staan die de boel verstoord.

ik ben niet zo bekend met dit allemaal maar het is eigenlijk erg simpel.

kabel van modem naar de computer/laptop

ik heb hier niks doorgetrokken of switches er tussen,gewoon rechtstreeks van de modem een kabel naar de pc/laptop.

Acties:

Muis666

joey82 schreef op vrijdag 5 oktober 2018 @ 10:45:
[...]
ik heb hier niks doorgetrokken of switches er tussen,gewoon rechtstreeks van de modem een kabel naar de pc/laptop.

Ik mis toch een kabel. Als het goed is heb je een NTU met lampjes. Daarvandaan een kabel naar je Experiabox (die geen modem werkzaamheden doet bij glasvezel). En dan vanaf de experiabox naar de pc/laptop...

Of heb je ADSL en zit je in het verkeerde topic?

[ Voor 3% gewijzigd door Muis666 op 05-10-2018 10:58 . Reden: Verduidelijking ]

vrijdag 5 oktober 2018 11:05

Acties:

vrijdag 5 oktober 2018 11:30

Muis666 schreef op vrijdag 5 oktober 2018 @ 10:54:
[...]

Ik mis toch een kabel. Als het goed is heb je een NTU met lampjes. Daarvandaan een kabel naar je Experiabox (die geen modem werkzaamheden doet bij glasvezel). En dan vanaf de experiabox naar de pc/laptop...

Of heb je ADSL en zit je in het verkeerde topic?

we hebben glasvezel van kpn....het kastje wat tegen de muur hang wat met een kabeltje naar de modem gaat van kpn zit op nog geen 20 cm van elkaar vandaan,ze staan letterlijk naast elkaar.

Acties:

vrijdag 5 oktober 2018 11:49

Maar de kabel vanaf de experiabox zit dus of in je pc, of de laptop van je moeder? Je wisselt deze steeds?

Heb je al eens geprobeerd om deze kabel in een andere poort van je experiabox te doen? Kan zomaar een klein hardwarefoutje oid zijn wat je daarmee oplost.

Edit: ik zie nu dat je TV kastje ook klachten geeft, dus dan zal die kabel omstreken niet helpen.

[ Voor 16% gewijzigd door Hmmbob op 05-10-2018 11:31 ]

Sometimes you need to plan for coincidence

Acties:

Muis666

Ik lees niets over klachten met normale tv kijken. Dan lijken de kabels in orde.
Ik lees geen klachten met wifi. Dan lijken er geen problemen met de de internetverbinding van de Experiabox.
Ik zou het niet meer weten...

vrijdag 5 oktober 2018 11:57

Acties:

Tylen

Dutch ProClass 1000 #56 ⭐⭐⭐⭐⭐

Vaste ip addressen ingesteld op de laptops/desktops?

“Choose a job you love, and you will never have to work a day in your life.”

vrijdag 5 oktober 2018 12:23

Acties:

vrijdag 5 oktober 2018 13:20

Muis666 schreef op vrijdag 5 oktober 2018 @ 11:49:
Ik lees niets over klachten met normale tv kijken. Dan lijken de kabels in orde.
Ik lees geen klachten met wifi. Dan lijken er geen problemen met de de internetverbinding van de Experiabox.

joey82 schreef op donderdag 4 oktober 2018 @ 16:30:
(...) dat de internet verbinding regelmatig ( paar keer per dag ) voor een aantal seconden tot een minuut weg valt (....) met wifi hebben we nergens last van.

dit probleem speelt zich af op zowel mijn pc als de laptop van mijn moeder.
( netflix kijken via de mediabox van kpn geeft ook dit probleem een aantal keer per avond )

[ Voor 40% gewijzigd door Hmmbob op 05-10-2018 12:25 ]

Sometimes you need to plan for coincidence

Acties:

vrijdag 5 oktober 2018 14:41

Hmmbob schreef op vrijdag 5 oktober 2018 @ 11:30:
Maar de kabel vanaf de experiabox zit dus of in je pc, of de laptop van je moeder? Je wisselt deze steeds?

Heb je al eens geprobeerd om deze kabel in een andere poort van je experiabox te doen? Kan zomaar een klein hardwarefoutje oid zijn wat je daarmee oplost.

Edit: ik zie nu dat je TV kastje ook klachten geeft, dus dan zal die kabel omstreken niet helpen.

we hebben 2 kabels 1 voor de pc en 1 voor de laptop,in een jaar tijd al 4 keer nieuwe kabels geprobeerd maar niks geen effect.

Acties:

Barre73

Glasvezel
Isp
Experiabox
KPN
Fiber
Glashart
Reggefiber

@joey82 :

De internetverbinding van de computers geeft dus problemen. De Netflix app op de decoder (die niet via het TV Vlan maar via het internet Vlan loopt) geeft problemen.
Ik zeg: KPN probleem. Wellicht een nieuwe NTU nodig (het glasvezelkastje) of een andere Experiabox.
Maar hoe dan ook: ik zou die monteur wel durven laten komen hoor. Dit lijkt zeker niet aan je eigen netwerk of kabels te liggen maar bij KPN zelf.

Geen ongevraagde verzoeken via DM svp.

zondag 7 oktober 2018 20:32

Acties:

tayram

jimmy87 schreef op zondag 18 september 2016 @ 04:06:
[...]

Opgelost! $_/-\o_$
Ik moest pppoe0 ook nog op 1500 zetten quasi mtu en wat geduld hebben voor hij een nieuwe pppoe verbinding opbouwt.
Daarna radvd opnieuw gestart en nu werken alle ipv6 sites waaronder tweakers ook zoals het hoor. $_/-\o_$

Ik heb nu een edgerouter 4. Ik krijg dit niet voor elkaar. Kan iemand mij uitleggen hoe ik dit in mijn edgerouter 4 brengen? Alvast bedankt.

donderdag 11 oktober 2018 12:33

Acties:

donderdag 11 oktober 2018 13:02

Las zojuist hier dat KPN onlangs wijzigingen heeft doorgevoerd in de IP Range voor multicast streams; Nu heb ik zelf alweer enige tijd problemen met het haperen van zenders (heb zelf een EdgeRouter/TP-Link switch voor Internet & Televisie, telefonie gaan nog via EB). In mijn Edgerouter config heb voor igmp-proxy alt-subnet 0.0.0.0/0, zou dit voldoende moeten zijn? Heb niet de laatste firmware op de edgerouter, kan dat nog helpen?

Verder, hoe kan ik dit het beste troubleshooten, het begint redelijk anoying te worden. Iemand tips, ideeën?

Acties:

donderdag 11 oktober 2018 13:25

Glashart

mawi schreef op donderdag 11 oktober 2018 @ 12:33:
Las zojuist hier dat KPN onlangs wijzigingen heeft doorgevoerd in de IP Range voor multicast streams; Nu heb ik zelf alweer enige tijd problemen met het haperen van zenders (heb zelf een EdgeRouter/TP-Link switch voor Internet & Televisie, telefonie gaan nog via EB). In mijn Edgerouter config heb voor igmp-proxy alt-subnet 0.0.0.0/0, zou dit voldoende moeten zijn? Heb niet de laatste firmware op de edgerouter, kan dat nog helpen?

Verder, hoe kan ik dit het beste troubleshooten, het begint redelijk anoying te worden. Iemand tips, ideeën?

Als je al 0.0.0.0/0 als alt-subnet ingesteld hebt staan hoeft je daarin uiteraard geen aanpassingen te doen voor de nieuwe IP range.

Voor de rest, gebeurt dat haperen continu of enkel soms een keer en loopt het verder goed? Nieuwste firmware installeren lijkt me sowieso verstandig maar verder zou ik ook eens kijken hoe hoog je CPU load e.d. is.

Acties:

donderdag 11 oktober 2018 14:00

ik222 schreef op donderdag 11 oktober 2018 @ 13:02:
[...]

Als je al 0.0.0.0/0 als alt-subnet ingesteld hebt staan hoeft je daarin uiteraard geen aanpassingen te doen voor de nieuwe IP range.

Voor de rest, gebeurt dat haperen continu of enkel soms een keer en loopt het verder goed? Nieuwste firmware installeren lijkt me sowieso verstandig maar verder zou ik ook eens kijken hoe hoog je CPU load e.d. is.

Haperen gebeurt meestal na een minuut of 5 á 10, dan zie je dat het beeld even bevriest, maar vervolgens weer doorgaat. Dan, wederom na zo'n 5 minuten komt de melding in beeld dat je naar een andere zender moet zappen. CPU load lijkt op dat moment niet echt hoog. Gisteren de edgerouter maar een keer herstart, daarna werd het probleem erger. Toen nog een keer herstart, daarna kon ik op RTL4 door blijven kijken zonder haperingen, maar zodra ik naar een andere zender zapte, had ik weer last van haperingen (erger dan voorheen, behalve dus op rtl 4)

Overigens op de On Demand services zoals Netflix geen problemen. Ook als je de zender even pauzeert, ook dan doen de haperingen zich niet meer voor, maar ik heb begrepen dat je dan geen multicast gebruikt?

[ Voor 9% gewijzigd door mawi op 11-10-2018 13:26 ]

Acties:

vrijdag 12 oktober 2018 06:17

Glashart

Als je gepauzeerd hebt ga je inderdaad over naar een unicast stream, dan maak je dus geen gebruik meer van multicast. De problemen die jij beschrijft lijken inderdaad IGMP problemen te zijn.

Heb je IGMP snooping aan staan op de TP-Link switch? Zo ja dan kan je dat een keer uitzetten om te testen, heb je het niet aanstaan dan moet je dit aanzetten (het zou eigenlijk aan moeten staan).

En anders inderdaad je Edgerouter upgraden.

Acties:

vrijdag 12 oktober 2018 07:36

Ik kom net beneden, en zie dat mijn experiabox V10a een groene LED heeft, ipv de standaard roze.

De internetverbinding werkt wel nog gewoon.

Blijkt er vannacht een firmware upgrade uitgerold te zijn.
Nu ben ik benieuwd naar de changelog...

En nee, de settings zijn nog steeds gelocked.

Acties:

Alpha89

Richub schreef op vrijdag 12 oktober 2018 @ 06:17:
Ik kom net beneden, en zie dat mijn experiabox V10a een groene LED heeft, ipv de standaard roze.
De internetverbinding werkt wel nog gewoon.

Blijkt er vannacht een firmware upgrade uitgerold te zijn.
Nu ben ik benieuwd naar de changelog...

En nee, de settings zijn nog steeds gelocked.

Dat komt inderdaad door de laatste firmware (dat lampje dan).

Weet niet of je al op het KPN Forum je feedback hebt gegeven. De "changelog" vind je daar ook:

https://forum.kpn.com/int...n-v10a-454616/index1.html

vrijdag 12 oktober 2018 10:34

Acties:

vrijdag 12 oktober 2018 11:50

Daar staat dat de firmware 6 september uitkwam, en 23 september gepusht werd.

Raar dan dat ik 'm nu pas krijg, terwijl ik afgelopen dinsdag nog de stroom even uit moest zetten ivm een fitting vervangen, en mijn volledige netwerk dus een reboot kreeg.

Nouja, dalijk eens testen of die Android bug geplet is, die was nog het irritantste.

Edit:
Die android bug lijkt idd geplet te zijn. Gelukkig, kan ik weer Ziggo Go kijken met mijn tablet & chromecast..

(Met inloggegevens van een van mijn vrienden.

)

[ Voor 21% gewijzigd door Richub op 12-10-2018 10:46 ]

Acties:

vrijdag 12 oktober 2018 12:00

ik222 schreef op donderdag 11 oktober 2018 @ 14:00:
Als je gepauzeerd hebt ga je inderdaad over naar een unicast stream, dan maak je dus geen gebruik meer van multicast. De problemen die jij beschrijft lijken inderdaad IGMP problemen te zijn.

Heb je IGMP snooping aan staan op de TP-Link switch? Zo ja dan kan je dat een keer uitzetten om te testen, heb je het niet aanstaan dan moet je dit aanzetten (het zou eigenlijk aan moeten staan).

En anders inderdaad je Edgerouter upgraden.

IGMP Snooping op de tp-link een keer disabled en weer enabled, Edgerouter geupdate en het leek verholpen te zijn, maar zag op een gegeven moment (veel later dan voorheen) toch weer de melding om te zappen naar een andere zender. Op dat moment was ik één van m'n STBs aan het bijwerken en dat gaat momenteel nog steeds niet goed; na zo'n 80% komt er een foutmelding, fout 561:opvragen instellingen mislukt:

Je tv-ontvanger krijgt een verkeerd IP-adres om op het tv-netwerk te komen. De oorzaak kan een probleem in het netwerk zijn of je tv ontvangt een IP-adres van een ander apparaat. Denk hierbij aan een printer, een Apple Airport, een WiFi versterker of een ander apparaat dat aan je modem zit. Zet deze apparaten 1 voor 1 uit. Om er achter te komen waar dit vandaan komt.

1 van m'n STBs is nog niet bijgewerkt, daar werkt alles nog goed op...

Acties:

vrijdag 12 oktober 2018 21:58

Glashart

Fout 561 heb ik wel eens voorbij zien komen als de STB de via DHCP aangeleverde DNS server niet kan bereiken. Heb je dat goed geconfigureerd staan?

Ook kan die fout voorkomen als je een tweede DHCP server in je netwerk hebt draaien, dat is naam ik aan niet het geval?

Acties:

zaterdag 13 oktober 2018 08:37

ik222 schreef op vrijdag 12 oktober 2018 @ 12:00:
Fout 561 heb ik wel eens voorbij zien komen als de STB de via DHCP aangeleverde DNS server niet kan bereiken. Heb je dat goed geconfigureerd staan?

Ook kan die fout voorkomen als je een tweede DHCP server in je netwerk hebt draaien, dat is naam ik aan niet het geval?

Begin toch het vermoeden te krijgen dat het met mijn switch te maken heeft; als ik een igmp-proxy Reset doe, dan werkt het weer even. Heb voor nu de KPN eb maar weer aangesloten, kreeg het thuis niet langer verkocht ;-) Wordt vervolgd...

Acties:

Muis666

mawi schreef op vrijdag 12 oktober 2018 @ 21:58:
[...]

Begin toch het vermoeden te krijgen dat het met mijn switch te maken heeft; als ik een igmp-proxy Reset doe, dan werkt het weer even. Heb voor nu de KPN eb maar weer aangesloten, kreeg het thuis niet langer verkocht ;-) Wordt vervolgd...

Ik zou nog even bridged IPTV hebben geprobeerd. Dan kun je zien of de problemen wellicht komen door de igmp proxy van de edgerouter

zondag 14 oktober 2018 09:38

Acties:

the_shadow

Bubbelmaker extraordinair

Goed, ik heb sinds een paar weken ook last van een klapperende IPTV connectie (i.c.m. een EdgeRouter Lite). Het begon met gezeur ieder +/- 12 min, en werd erger tot op het punt dat er nog geen 2 seconden gekeken kon worden zonder het befaamde advies om heen en weer te zappen.

Gisteren heb ik m'n volledige config het raam uit gedaan en de boel opnieuw opgebouwd (aan de hand van https://kriegsman.io/ en http://www.pimwiddershove...uter-lite-lessons-learned). Helaas geen succes: een minuutje of 4 kijken is geen probleem, daarna begint het eerst met haperen, maar na een tijd klapt hij er weer helemaal uit.

Ik heb het vermoeden dat het de igmp proxy is, maar aangezien ik hier als upstream subnet 0.0.0.0/0 heb ingesteld kunnen KPN veranderingen hier bijna niet het probleem zijn zou ik zeggen?

Ziet iemand aan mijn config iets wat dit probleem zou kunnen verklaren? Mijn FTU zit op eth0, eth2 is m'n interne netwerk (DHCP via eigen DHCP server). Eth1 heb ik ingericht puur voor 1 settop box, waar de ERL het DHCP doet. Mijn ERL zit op de meest recente firmware versie (v1.10.7).

code:

firewall {
    all-ping enable
    broadcast-ping disable
    ipv6-receive-redirects disable
    ipv6-src-route disable
    ip-src-route disable
    log-martians enable
    name WAN_IN {
        default-action drop
        description "WAN to Internal"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related"
            log enable
            protocol all
            state {
                established enable
                invalid disable
                new disable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            log enable
            protocol all
            state {
                established disable
                invalid enable
                new disable
                related disable
            }
        }
    }
    name WAN_LOCAL {
        default-action drop
        description "WAN to router"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related"
            log disable
            protocol all
            state {
                established enable
                invalid disable
                new disable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            log disable
            protocol all
            state {
                established disable
                invalid enable
                new disable
                related disable
            }
        }
        rule 50 {
            action accept
            description OpenVPN
            destination {
                port [...]
            }
            protocol tcp_udp
        }
    }
    receive-redirects disable
    send-redirects enable
    source-validation disable
    syn-cookies enable
}
interfaces {
    ethernet eth0 {
        description "eth0 - FTTH"
        duplex auto
        mtu 1512
        speed auto
        vif 4 {
            address dhcp
            description "eth0.4 - IPTV"
            dhcp-options {
                client-option "send vendor-class-identifier &quot;IPTV_RG&quot;;"
                client-option "request subnet-mask, routers, rfc3442-classless-static-routes;"
                default-route no-update
                default-route-distance 254
                name-server update
            }
        }
        vif 6 {
            description "eth0.6 - Internet"
            mtu 1508
            pppoe 0 {
                default-route auto
                firewall {
                    in {
                        name WAN_IN
                    }
                    local {
                        name WAN_LOCAL
                    }
                }
                idle-timeout 180
                mtu 1500
                name-server auto
                password kpn
                user-id [...]@internet
            }
        }
    }
    ethernet eth1 {
        address 192.168.1.254/24
        description "eth1 - IPTV"
        duplex auto
        speed auto
    }
    ethernet eth2 {
        address 192.168.2.254/24
        description "eth2 - LAN"
        duplex auto
        speed auto
    }
    loopback lo {
    }
    openvpn vtun0 {
        [...]
    }
}
port-forward {
    [...]
}
protocols {
    igmp-proxy {
        interface eth0.4 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
        interface eth1 {
            role downstream
            threshold 1
        }
    }
    static {
        route 213.75.112.0/21 {
            next-hop 10.146.64.1 {
            }
        }
    }
}
service {
    dhcp-server {
        disabled false
        global-parameters "option vendor-class-identifier code 60 = string;"
        global-parameters "option broadcast-address code 28 = ip-address;"
        hostfile-update disable
        shared-network-name IPTV {
            authoritative enable
            subnet 192.168.1.0/24 {
                default-router 192.168.1.254
                dns-server 8.8.8.8
                dns-server 8.8.4.4
                lease 86400
                start 192.168.1.50 {
                    stop 192.168.1.200
                }
            }
        }
        static-arp disable
        use-dnsmasq disable
    }
    dns {
        forwarding {
            cache-size 150
            listen-on eth2
            listen-on eth1
            name-server 8.8.8.8
            name-server 8.8.4.4
            options listen-address=192.168.2.254
            options listen-address=192.168.1.254
        }
    }
    [...]
    nat {
        rule 5000 {
            description IPTV
            destination {
                address 213.75.0.0/16
            }
            log disable
            outbound-interface eth0.4
            protocol all
            type masquerade
        }
        rule 5001 {
            description IPTV
            destination {
                address 10.60.0.0/16
            }
            log disable
            outbound-interface eth0.4
            protocol all
            type masquerade
        }
        rule 5010 {
            description "KPN Internet"
            log enable
            outbound-interface pppoe0
            protocol all
            source {
                address 192.168.2.0/24
            }
            type masquerade
        }
        rule 5011 {
            description "KPN Internet"
            log enable
            outbound-interface pppoe0
            protocol all
            source {
                address 192.168.1.0/24
            }
            type masquerade
        }
    }
    [...]
}
system {
    [...]
    task-scheduler {
        task updateIPTVroute {
            executable {
                path /config/scripts/tvroute.sh
            }
            interval 5m
        }
    }
    [...]
}

I'd rather be diving | The best thing about alcohol hand gel in hospitals isn't the hygiene, but that everyone walks around like they're hatching a dastardly plan. | "Cheese is just milk’s attempt at being immortal."

zondag 14 oktober 2018 09:58

Acties:

zondag 14 oktober 2018 10:08

Glashart

@the_shadow Je moet in jou configuratie wel even een extra NAT regel aanmaken voor de nieuwe IP reeks die KPN in gebruik genomen heeft. Dus van NAT regel 5000 moet je ook een variant aanmaken met daarin als destination 217.166.0.0/16

Daarnaast zou ik in NAT regel 5001 de destination aanpassen naar 10.0.0.0/8

Acties:

Miki

the_shadow schreef op zondag 14 oktober 2018 @ 09:38:
Goed, ik heb sinds een paar weken ook last van een klapperende IPTV connectie (i.c.m. een EdgeRouter Lite). Het begon met gezeur ieder +/- 12 min, en werd erger tot op het punt dat er nog geen 2 seconden gekeken kon worden zonder het befaamde advies om heen en weer te zappen.

Gisteren heb ik m'n volledige config het raam uit gedaan en de boel opnieuw opgebouwd (aan de hand van https://kriegsman.io/ en http://www.pimwiddershove...uter-lite-lessons-learned). Helaas geen succes: een minuutje of 4 kijken is geen probleem, daarna begint het eerst met haperen, maar na een tijd klapt hij er weer helemaal uit.

Ik heb het vermoeden dat het de igmp proxy is, maar aangezien ik hier als upstream subnet 0.0.0.0/0 heb ingesteld kunnen KPN veranderingen hier bijna niet het probleem zijn zou ik zeggen?

Ziet iemand aan mijn config iets wat dit probleem zou kunnen verklaren? Mijn FTU zit op eth0, eth2 is m'n interne netwerk (DHCP via eigen DHCP server). Eth1 heb ik ingericht puur voor 1 settop box, waar de ERL het DHCP doet. Mijn ERL zit op de meest recente firmware versie (v1.10.7).

code:

firewall {
    all-ping enable
    broadcast-ping disable
    ipv6-receive-redirects disable
    ipv6-src-route disable
    ip-src-route disable
    log-martians enable
    name WAN_IN {
        default-action drop
        description "WAN to Internal"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related"
            log enable
            protocol all
            state {
                established enable
                invalid disable
                new disable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            log enable
            protocol all
            state {
                established disable
                invalid enable
                new disable
                related disable
            }
        }
    }
    name WAN_LOCAL {
        default-action drop
        description "WAN to router"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related"
            log disable
            protocol all
            state {
                established enable
                invalid disable
                new disable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            log disable
            protocol all
            state {
                established disable
                invalid enable
                new disable
                related disable
            }
        }
        rule 50 {
            action accept
            description OpenVPN
            destination {
                port [...]
            }
            protocol tcp_udp
        }
    }
    receive-redirects disable
    send-redirects enable
    source-validation disable
    syn-cookies enable
}
interfaces {
    ethernet eth0 {
        description "eth0 - FTTH"
        duplex auto
        mtu 1512
        speed auto
        vif 4 {
            address dhcp
            description "eth0.4 - IPTV"
            dhcp-options {
                client-option "send vendor-class-identifier &quot;IPTV_RG&quot;;"
                client-option "request subnet-mask, routers, rfc3442-classless-static-routes;"
                default-route no-update
                default-route-distance 254
                name-server update
            }
        }
        vif 6 {
            description "eth0.6 - Internet"
            mtu 1508
            pppoe 0 {
                default-route auto
                firewall {
                    in {
                        name WAN_IN
                    }
                    local {
                        name WAN_LOCAL
                    }
                }
                idle-timeout 180
                mtu 1500
                name-server auto
                password kpn
                user-id [...]@internet
            }
        }
    }
    ethernet eth1 {
        address 192.168.1.254/24
        description "eth1 - IPTV"
        duplex auto
        speed auto
    }
    ethernet eth2 {
        address 192.168.2.254/24
        description "eth2 - LAN"
        duplex auto
        speed auto
    }
    loopback lo {
    }
    openvpn vtun0 {
        [...]
    }
}
port-forward {
    [...]
}
protocols {
    igmp-proxy {
        interface eth0.4 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
        interface eth1 {
            role downstream
            threshold 1
        }
    }
    static {
        route 213.75.112.0/21 {
            next-hop 10.146.64.1 {
            }
        }
    }
}
service {
    dhcp-server {
        disabled false
        global-parameters "option vendor-class-identifier code 60 = string;"
        global-parameters "option broadcast-address code 28 = ip-address;"
        hostfile-update disable
        shared-network-name IPTV {
            authoritative enable
            subnet 192.168.1.0/24 {
                default-router 192.168.1.254
                dns-server 8.8.8.8
                dns-server 8.8.4.4
                lease 86400
                start 192.168.1.50 {
                    stop 192.168.1.200
                }
            }
        }
        static-arp disable
        use-dnsmasq disable
    }
    dns {
        forwarding {
            cache-size 150
            listen-on eth2
            listen-on eth1
            name-server 8.8.8.8
            name-server 8.8.4.4
            options listen-address=192.168.2.254
            options listen-address=192.168.1.254
        }
    }
    [...]
    nat {
        rule 5000 {
            description IPTV
            destination {
                address 213.75.0.0/16
            }
            log disable
            outbound-interface eth0.4
            protocol all
            type masquerade
        }
        rule 5001 {
            description IPTV
            destination {
                address 10.60.0.0/16
            }
            log disable
            outbound-interface eth0.4
            protocol all
            type masquerade
        }
        rule 5010 {
            description "KPN Internet"
            log enable
            outbound-interface pppoe0
            protocol all
            source {
                address 192.168.2.0/24
            }
            type masquerade
        }
        rule 5011 {
            description "KPN Internet"
            log enable
            outbound-interface pppoe0
            protocol all
            source {
                address 192.168.1.0/24
            }
            type masquerade
        }
    }
    [...]
}
system {
    [...]
    task-scheduler {
        task updateIPTVroute {
            executable {
                path /config/scripts/tvroute.sh
            }
            interval 5m
        }
    }
    [...]
}

Ik heb zo mijn twijfels of het aan je apparatuur ligt. Ik heb de afgelopen 3 weken ook een paar keer rond 2030u gehad dat bij tv uitzendingen het begon te stotteren, alsof de apparatuur over z’n nek ging.

Ik heb alles origineel van KPN dus een Experia V10 + een KPN WiFi versterker bedraad aangesloten + recente VIP tv ontvanger.
Het is nu weer een paar dagen in orde.

zondag 14 oktober 2018 11:20

Acties:

the_shadow

Bubbelmaker extraordinair

ik222 schreef op zondag 14 oktober 2018 @ 09:58:
@the_shadow Je moet in jou configuratie wel even een extra NAT regel aanmaken voor de nieuwe IP reeks die KPN in gebruik genomen heeft. Dus van NAT regel 5000 moet je ook een variant aanmaken met daarin als destination 217.166.0.0/16

Daarnaast zou ik in NAT regel 5001 de destination aanpassen naar 10.0.0.0/8

Zojuist toegevoegd en aangepast, maar helaas geen solaas (ook niet na een reboot en een herstart van de settop box). Na exact 4min en 30s (consequent) hikt of verbreekt het signaal.

I'd rather be diving | The best thing about alcohol hand gel in hospitals isn't the hygiene, but that everyone walks around like they're hatching a dastardly plan. | "Cheese is just milk’s attempt at being immortal."

zondag 14 oktober 2018 11:43

Acties:

zondag 14 oktober 2018 12:02

Glashart

Ik zie verder niets raars in je configuratie, klinkt bijna als een of andere bug in de software van de Edgerouter. Misschien eens proberen te downgraden naar een oudere versie?

Acties:

vSphere/ESXi

the_shadow schreef op zondag 14 oktober 2018 @ 09:38:
[...]

Gisteren heb ik m'n volledige config het raam uit gedaan en de boel opnieuw opgebouwd

[...]

ik222 schreef op zondag 14 oktober 2018 @ 09:58:
@the_shadow Je moet in jou configuratie wel even een extra NAT regel aanmaken voor de nieuwe IP reeks die KPN in gebruik genomen heeft. Dus van NAT regel 5000 moet je ook een variant aanmaken met daarin als destination 217.166.0.0/16

Daarnaast zou ik in NAT regel 5001 de destination aanpassen naar 10.0.0.0/8

Niet dat het dit probleem oplost, maar:

213.75.0.0/16->213.75.167.0/24
217.166.0.0/16->217.166.224.0/22
0.0.0.0/0->213.75.167.0/24 + 217.166.224.0/22
Optie 28/60 kunnen weg uit dhcp-server

En die SNAT naar 10.0.0.0/8 of 10.60.0.0/16 snap ik niet, lijkt me niet nodig, op netwerkje.com is dit 10.142.64.0/18 wat de range van zijn IPTV netwerk is, ik denk dat deze volledig weg kan.

En is classless routes nog steeds niet gefixt bij Ubiquiti? rfc3442-classless-static-routes zou voldoende moeten zijn, maar je hebt hem nu ook nog eens static+script(voor overschrijven van next hop), en als je toch een script gebruikt is zoiets via /etc/dhcp3/dhclient-exit-hooks.d zonder static fraaier.

[ Voor 43% gewijzigd door |sWORDs| op 14-10-2018 12:27 ]

zondag 14 oktober 2018 12:44

Acties:

zondag 14 oktober 2018 13:18

Glashart

Op mijn pfSense NAT ik simpelweg het verkeer wat via de ITV interface naar buiten gaat. Dat is in de praktijk dan dus het ITV 10.x (/22) subnet waar ik zelf inzit + een /21 die ik als route van de DHCP server van KPN krijg.

Op zich heb je die 2 NAT regels wel ook echt nodig dus als je dan een destination moet specificeren in zo'n Edgerouter zou ik er gewoon de hele 10.0.0.0/8 neerzetten (anders moet je het weer aanpassen als je ITV IP een keer wijzigt) + de gebruikte public IP ranges. Immers de regel staat toch op de uitgaande interface dus zonder route over die interface doet het niets.

Rfc3442 classless routes werkt volgens mij inderdaad nog steeds simpelweg niet op die Edgerouters. Als dat zou werken kan ook die hele static route + bijbehorend update script weg...

Acties:

the_shadow

Bubbelmaker extraordinair

ik222 schreef op zondag 14 oktober 2018 @ 11:43:
Misschien eens proberen te downgraden naar een oudere versie?

Was inderdaad ook mijn idee. Ik heb net een rollback gedaan naar v1.9.7+hotfix.4: nog steeds hetzelfde probleem. Na strak 4.5 min een hik, 4.5. min later klapt hij er uit.

I'd rather be diving | The best thing about alcohol hand gel in hospitals isn't the hygiene, but that everyone walks around like they're hatching a dastardly plan. | "Cheese is just milk’s attempt at being immortal."

zondag 14 oktober 2018 13:22

Acties:

zondag 14 oktober 2018 13:53

Ik snap van deze hele discussie maar weinig...

Ik moet nu wel ineens denken aan de vrije routerkeuze waar de KPN volgens europese regelgeving aan mee zou moeten gaan werken.

Stel dat de KPN hier inderdaad aan gaat meewerken:
Hoe de vliegende fak leg je dit verhaal uit aan een gebruiker die graag een eigen router wil, maar die geen netwerkguru is...

Dat wordt nog een pittige uitdaging voor de helpdesk, denk ik zo.

Acties:

vSphere/ESXi

ik222 schreef op zondag 14 oktober 2018 @ 12:44:
Op mijn pfSense NAT ik simpelweg het verkeer wat via de ITV interface naar buiten gaat. Dat is in de praktijk dan dus het ITV 10.x (/22) subnet waar ik zelf inzit + een /21 die ik als route van de DHCP server van KPN krijg.

[...]

Destination daarvan is 213.75.167.0/24 + 217.166.224.0/22 en niet 10.x.

Richub schreef op zondag 14 oktober 2018 @ 13:22:
Ik snap van deze hele discussie maar weinig...

Ik moet nu wel ineens denken aan de vrije routerkeuze waar de KPN volgens europese regelgeving aan mee zou moeten gaan werken.

Stel dat de KPN hier inderdaad aan gaat meewerken:
Hoe de vliegende fak leg je dit verhaal uit aan een gebruiker die graag een eigen router wil, maar die geen netwerkguru is...

Dat wordt nog een pittige uitdaging voor de helpdesk, denk ik zo.

Misschien als de router fabrikanten het in een wizard opnemen zoals FRITZ!! ook doet.
Anders is het wel erg lastig, 2 of 3 VLANs, PPPoE, twee keer DHCP en igmpproxy...

[ Voor 22% gewijzigd door |sWORDs| op 14-10-2018 13:59 ]

zondag 14 oktober 2018 14:01

Acties:

eymey

KPN
Fiber
Glashart
Reggefiber
Glasvezel
Isp

Vrije routerkeuze kan matuurlijk heel erg breed uitgelegd worden. Afhankelijk van hoe je het interpreteert voldoen ze er al aan door een dmz of bridge mode in het meegeleverde apparaat te stoppen. Of door gewoon te stellen: "hier zijn de instellingen. Zie verder de handleiding van uw router"

Marstek Venus 5.12kWh v151, CT002 V118, CT003 V116 DSMR5.5, PV 11xEnphase IQ7+ Z-O, 5xEnphase IQ7+ N-W - ~4,7Wp theoretisch, ~3,5Wp praktijk.

zondag 14 oktober 2018 16:46

Acties:

zondag 14 oktober 2018 17:21

ik222 schreef op zondag 14 oktober 2018 @ 09:58:
@the_shadow Je moet in jou configuratie wel even een extra NAT regel aanmaken voor de nieuwe IP reeks die KPN in gebruik genomen heeft. Dus van NAT regel 5000 moet je ook een variant aanmaken met daarin als destination 217.166.0.0/16

Tenzij je reverse path filtering (vrij lastig icm, IPTV) wilt aanzetten schiet je hier niets mee op, die range bestaat alleen als multicast source.

Als hij echt nodig was als route zouden ze hem wel meegeven via DHCP (net als 213.75.112.0/21).

Op mijn pfSense NAT ik simpelweg het verkeer wat via de ITV interface naar buiten gaat.

Dit. Destination IPs specificeren slaat nergens op en is véél foutgevoeliger, tenzij die ubiquiti het echt niet zonder kan (kan ik me niet voorstellen).

the_shadow schreef op zondag 14 oktober 2018 @ 13:18:
[...]
Was inderdaad ook mijn idee. Ik heb net een rollback gedaan naar v1.9.7+hotfix.4: nog steeds hetzelfde probleem. Na strak 4.5 min een hik, 4.5. min later klapt hij er uit.

Even terug naar debuggen 101: sniff je IPTV uplink eens en kijk eens wat er op netwerkniveau gebeurt.

De IGMP query interval is 125s, daar zou het dus niet aan mogen liggen.

eymey schreef op zondag 14 oktober 2018 @ 14:01:
Vrije routerkeuze kan matuurlijk heel erg breed uitgelegd worden. Afhankelijk van hoe je het interpreteert voldoen ze er al aan door een dmz of bridge mode in het meegeleverde apparaat te stoppen.

Valt wel mee hoor. In het besluit werd het aansluitpunt (FTU, AOP) als grenspunt genomen ('netwerkaansluitpunt'). Dáár moet je (met instructies van de provider) je eigen apparatuur op kunnen aansluiten.

Logischerwijs zijn de provders daar niet happy mee; als het goed is komt de ACM met een nieuwe beleidsregel nalv. de consultatie van begin dit jaar.

Acties:

zondag 14 oktober 2018 18:26

Glashart

|sWORDs| schreef op zondag 14 oktober 2018 @ 13:53:
[...]

Destination daarvan is 213.75.167.0/24 + 217.166.224.0/22 en niet 10.x.

Voor 217.166.224.0/22 krijg ik ook geen route, dat is enkel een multicast source. Ik krijg vanuit KPN enkel een /21 uit de 213.75 als route gepusht via DHCP RFC3442.

En of er ooit verkeer naar 10.x gaat van binnenuit heb ik nooit bekeken, denk inderdaad van niet. Maar ik zie logischerwijs gewoon een connected route daarvoor.

Acties:

vSphere/ESXi

ik222 schreef op zondag 14 oktober 2018 @ 17:21:
[...]

Voor 217.166.224.0/22 krijg ik ook geen route, dat is enkel een multicast source. Ik krijg vanuit KPN enkel een /21 uit de 213.75 als route gepusht via DHCP RFC3442.

En of er ooit verkeer naar 10.x gaat van binnenuit heb ik nooit bekeken, denk inderdaad van niet. Maar ik zie logischerwijs gewoon een connected route daarvoor.

IPTV netwerk:
Afbeeldingslocatie: https://i.postimg.cc/MHLcRh6x/Screen-Shot-2018-10-14-at-6-06-16-PM.png

Eerste en derde doet de router, niets met IPTV platform te maken.

10.14x.y.42 = IPTV IP (DHCP)
10.14x.y.1 = IPTV default gateway
10.60.x.x = IPTV querier naar 224.0.0.1
213.75.167.58 = Sap Broadcast naar 224.3.2.6:9875
217.166.224.0/22 = IPTV Streams naar 224.0.250.0/23, 224.0.252.0/24 en 224.0.253.0/24
213.75.112.0/21 = static route via IPTV default gateway (10.14x.y.1)
192.168.0.2 = IPTV box

Het enige wat overblijft is NAT naar de static route (NAT voor IPTV Box).

IPTV box LAN:
Afbeeldingslocatie: https://i.postimg.cc/sgz46hPW/Screen-Shot-2018-10-14-at-6-45-47-PM.png

Afbeeldingslocatie: https://i.postimg.cc/sgz46hPW/Screen-Shot-2018-10-14-at-6-45-47-PM.png

[ Voor 16% gewijzigd door |sWORDs| op 14-10-2018 18:47 ]

zondag 14 oktober 2018 20:16

Acties:

zondag 14 oktober 2018 21:00

Glashart

Ja dat zeg ik, dus de enige NAT regel op dit moment echt nodig is die naar die 213.75.0.0/16 of nog specifieker zelfs al je dat echt wil...

Maar wat ik bedoel, ik zou idealiter gewoon al het verkeer over je ITV WAN interface NAT'en. Dan regelt routering de rest wel, als je die gewoon via DHCP binnenkrijgt heb je daar dan nooit omkijken naar. Alles zo strak mogelijk zetten is leuk maar zorgt ervoor dat je bij elke kleine aanpassing van KPN ook weer dingen moet aanpassen, ik probeer een zo simpel mogelijke setup te maken die niet telkens aangepast hoeft te worden, zonder daarbij veiligheidsrisico's te nemen.

@Thralas Wat ik het en der begreep heeft Ubiquiti recent dat RP filter default aangezet. Dat zorgt inderdaad voor veel gezeur met ITV icm met die dingen. Maar in de configuratie hierboven staat dat alweer uit zo te zien, dus dan kan dat het probleem niet zijn inderdaad. Als je dat op zou willen lossen had je overigens echt een route nodig normaal gezien, niet enkel een NAT regel.

[ Voor 25% gewijzigd door ik222 op 14-10-2018 20:26 ]

Acties:

vSphere/ESXi

ik222 schreef op zondag 14 oktober 2018 @ 20:16:
Ja dat zeg ik, dus de enige NAT regel op dit moment echt nodig is die naar die 213.75.0.0/16 of nog specifieker zelfs al je dat echt wil...

Maar wat ik bedoel, ik zou idealiter gewoon al het verkeer over je ITV WAN interface NAT'en. Dan regelt routering de rest wel, als je die gewoon via DHCP binnenkrijgt heb je daar dan nooit omkijken naar. Alles zo strak mogelijk zetten is leuk maar zorgt ervoor dat je bij elke kleine aanpassing van KPN ook weer dingen moet aanpassen, ik probeer een zo simpel mogelijke setup te maken die niet telkens aangepast hoeft te worden, zonder daarbij veiligheidsrisico's te nemen.

@Thralas Wat ik het en der begreep heeft Ubiquiti recent dat RP filter default aangezet. Dat zorgt inderdaad voor veel gezeur met ITV icm met die dingen. Maar in de configuratie hierboven staat dat alweer uit zo te zien, dus dan kan dat het probleem niet zijn inderdaad. Als je dat op zou willen lossen had je overigens echt een route nodig normaal gezien, niet enkel een NAT regel.

De aanpassingen die we gehad hebben lagen buiten de ranges, dus breed houden werkt daar niet voor, ook werken bepaalde andere KPN diensten in de bredere range niet en regent het meldingen in je igmpproxy log wat ook bij effecten kan hebben. Daarnaast heb ik niet echt een veilig gevoel bij de IPTV boxen.

Ik neig dus meer naar juiste ranges zetten.

zondag 14 oktober 2018 23:45

Acties:

maandag 15 oktober 2018 11:22

|sWORDs| schreef op zondag 14 oktober 2018 @ 21:00:
[...]

De aanpassingen die we gehad hebben lagen buiten de ranges, dus breed houden werkt daar niet voor, ook werken bepaalde andere KPN diensten in de bredere range niet en regent het meldingen in je igmpproxy log wat ook bij effecten kan hebben.

Ik snap niet wat je hiermee bedoelt.

De enige 'aanpassing' was een wijziging van de multicast source. Dat heeft niets met NAT te maken; met een (eventueel) extra alternatief subnet voor igmpproxy ben je er.

Daarnaast heb ik niet echt een veilig gevoel bij de IPTV boxen.

Ik neig dus meer naar juiste ranges zetten.

Dat waar @ik222 op doelt is primair het NAT'en, en dat heeft geen bal met beveiliging te maken. Alles dat je naar KPN stuurt wil je NAT'en; vanaf 192.168.0.0/16 met KPN praten heeft geen zin.

Het enige dat IPTV firewalltechnisch 'vervelender' maakt dan het grote boze internet zijn de multicast streams (die kun je niet conntracken), voor de rest volstaat een standaard allow-incoming-established-en-drop-de-rest firewall policy.

Acties:

vSphere/ESXi

Thralas schreef op zondag 14 oktober 2018 @ 23:45:
[...]

Ik snap niet wat je hiermee bedoelt.

De enige 'aanpassing' was een wijziging van de multicast source. Dat heeft niets met NAT te maken; met een (eventueel) extra alternatief subnet voor igmpproxy ben je er.

Ik bedoel dat 0.0.0.0/0 en 213.75.0.0/16 gebruiken niet voldoende was, 217.166 moest er nu ook bij, dus desondanks dat je bredere ranges gebruikt is het niet altijd 0 touch bij wijzigingen.
Waar ik het ook over had was dat itvonline.nl in 2015 bijvoorbeeld op 213.75.3.164 zat, dan wil je niet 213.75.0.0/16 naar je IPTV VLAN natten.
Een andere probleem met 0.0.0.0/0 is dat alle het multicast verkeer (ook UPNP) dan door de igmpproxy gaat en je bergen not in any valid net for upstream VIF meldingen krijgt.

Thralas schreef op zondag 14 oktober 2018 @ 23:45:

[...]

Dat waar @ik222 op doelt is primair het NAT'en, en dat heeft geen bal met beveiliging te maken. Alles dat je naar KPN stuurt wil je NAT'en; vanaf 192.168.0.0/16 met KPN praten heeft geen zin.

Het enige dat IPTV firewalltechnisch 'vervelender' maakt dan het grote boze internet zijn de multicast streams (die kun je niet conntracken), voor de rest volstaat een standaard allow-incoming-established-en-drop-de-rest firewall policy.

Ik bedoel dat ik ze liever niet in mijn LAN heb zitten (maar in mijn guest VLAN) en verder zo strak mogelijk af firewall.

Alias:
Afbeeldingslocatie: https://i.postimg.cc/Hs70fMQC/Screen_Shot_2018-10-03_at_10.15.14_AM.png

IPTV rules:
Afbeeldingslocatie: https://i.postimg.cc/J4J6jvYJ/Screen_Shot_2018-10-03_at_10.15.51_AM.png

STB network rules:
Afbeeldingslocatie: https://i.postimg.cc/MZfd8gS4/Screen_Shot_2018-10-03_at_10.16.23_AM.png

[ Voor 8% gewijzigd door |sWORDs| op 15-10-2018 11:56 ]

maandag 15 oktober 2018 12:15

Acties:

Barre73

Glasvezel
Isp
Experiabox
KPN
Fiber
Glashart
Reggefiber

Dit onderwerp begint inmiddels een eigen topic te verdienen naar mijn mening...

Geen ongevraagde verzoeken via DM svp.

maandag 15 oktober 2018 12:35

Acties:

vSphere/ESXi

Barre73 schreef op maandag 15 oktober 2018 @ 12:15:
Dit onderwerp begint inmiddels een eigen topic te verdienen naar mijn mening...

Wat blijft er dan nog over voor een KPN glasvezel topic als we het gebruik van een eigen router of switches eruit halen? En krijgen we dan niet heel veel posts in het verkeerde topic?

[ Voor 9% gewijzigd door |sWORDs| op 15-10-2018 12:36 ]

maandag 15 oktober 2018 12:47

Acties:

maandag 15 oktober 2018 12:56

Ik snap Barre wel: het is nu meer een discussie over hoe je firewall strikt in te stellen geworden - niet meer hoe de Edge Router Lite ingesteld kan worden voor KPN.

Sometimes you need to plan for coincidence

Acties:

vSphere/ESXi

Hmmbob schreef op maandag 15 oktober 2018 @ 12:47:
Ik snap Barre wel: het is nu meer een discussie over hoe je firewall strikt in te stellen geworden - niet meer hoe de Edge Router Lite ingesteld kan worden voor KPN.

De eigenlijke discussie gaat gewoon om de juiste ranges, die KPN eigenlijk al twee jaar (en de 8,5 jaar daarvoor via ACM) zou moeten geven maar niet doet, daar zit het echte probleem. Ik snap ook niet waarom ze niet gewoon de instellingen van de Experiabox die ze ook aan WholeSale providers geven beschikbaar maken.

2008/63/EG (Besluit eindapparaten)
Artikel 2

Een aanbieder van een openbaar telecommunicatienetwerk publiceert de technische specificaties van de netwerkaansluitpunten op genoegzame wijze op de eigen internetpagina, voordat via deze netwerkaansluitpunten diensten aan het publiek beschikbaar worden gesteld.

Het zetten van te ruime (alles buiten de static) NAT ranges kan voor problemen met andere diensten zorgen (van KPN maar ook duizenden bedrijven):
http://ipv4info.com/domai...5.0.0-213.75.255.255.html
http://ipv4info.com/domai....0.0-217.166.255.255.html

code:

ping buismanadvies.nl
PING buismanadvies.nl (213.75.8.43): 56 data bytes
64 bytes from 213.75.8.43: icmp_seq=0 ttl=247 time=5.313 ms
PING webmail.onlinehosting.nl (217.166.54.4): 56 data bytes
64 bytes from 217.166.54.4: icmp_seq=0 ttl=120 time=8.905 ms

Afbeeldingslocatie: https://i.postimg.cc/Dyn59mRk/Screen-Shot-2018-10-15-at-2-06-41-PM.png

Maar er is nu inderdaad wel genoeg over gezegd.

[ Voor 53% gewijzigd door |sWORDs| op 15-10-2018 14:09 ]