IP adres geblokkeerd op 1 bepaalde website, via 4G werkt dit wel

@wjb Aan de andere kant zeg je dat je wel het inlog scherm krijgt en dat betekent dat er met de routering ook niets mis is.

Nee dat zeg ik niet ik krijg een time out en geen inlogscherm.

Alleen via een VPN of mobiele verbinding krijg ik het inlogscherm en werkt alle 100%

Helder, dan denk ik dat het een routeringsprobleem betreft.

Jammer dat een traceroute niet sowieso het IP adres van de hops weergeeft ongeacht of er wel of niet een time-out plaatsvindt want dan zouden we meer inzicht kunnen krijgen in de afgelegde route.

Ik hoop dat een moderator dit issue eens voor kan leggen aan de netwerkexperts van KPN.

Heb je ook al gekeken of het probleem niet optreed bij bijvoorbeeld ipv6? Ik heb wel eens eerder gezien dat een AAAA record in de NDS van een domein uitkomt op een andere server, of eentje die niet bestaat. En dan sluit je meteen iedereen met ipv6 buiten.

Of een CNAME met A-record tegelijk. Ik geloof dat dit ook wel eens kan botsen. 

@AriënC  Ja ook daar heb ik naar gekeken en ook gewoon ipv6 even uitgeschakeld.

Het probleem zit volgens mij net als @mr.sanders zegt ergens in het systeem van de website maar die zeggen op hun beurt weer het probleem zit bij KPN.

En zo wordt je van het kastje naar de muur gestuurd en heb ik al sinds 27 juni dit probleem

Hier werkt het perfect. Dus zeg maar dat andere KPN klanten geen probleem hebben. 

De site robot-maatje.com heeft geen IPv6 adres.

De gedachte is overigens wel een goede immers als de gebruikte browser geen fallback van IPv6 naar IPv4 gebruikt dan zou dat problemen kunnen gaan geven. Dan zou ik echter wel verwachten dat veel meer sites problemen geven.

Dat IPv6 kunnen we dus uitsluiten. Maar in Chrome kan je instellen in about:config dat je IPv6 wel of niet wilt gebruiken (als dat beschikbaar is). Dus als in een dergelijke situatie de locaties van een A en AAAA record niet overeenkomen, dan kan je dat zo uitzoeken. Maar nogmaals, puur ter  informatie, en niet de oplossing.

Ik heb een sterk vermoeden dat het probleem ligt bij de site zelf. Soms wil een verbinding wel eens haperen, maar dat kan nooit langer dan een dag duren. Altijd valt het wel op als er congestie lijkt te komen in de netwerken die er wordt afgelegd.

@JohanRobotics Kan je eens met jouw IP naar https://ipinfo.io/<jouw IP> gaan? Dus bijvoorbeeld https://ipinfo.io/183.81.129.204 (dit is een random ip)

Vervolgens kan je onder “Privacy Detection” zien of jouw IP als iets wordt aangemerkt, bijvoorbeeld een VPN/Proxy/Hosting. Sommige websites filteren hierop en dan heb je last van de blokkade. Ik had zelf eens bij Ziggo het kenmerk “Hosting” waardoor ik dus op best wat websites werd geblokkeerd. Nieuw IP fixte dat.

Is wel even een wilde gok, kans is groter dat er niks staat; maar dan kan je evt wel weer verder kijken naar een mogelijke oplossing :)

@ikheetjeff  Bedankt voor deze tip ik heb het direct even getest maar ook hier geen bijzonderheden.

Ik mis een test: Werkt “ping 76.76.21.21” ?

Er is gebruik gemaakt van traceroute, maar de auteur gebruikt blijkbaar de MacOS versie,  en ik krijg hier op een Linux systeem ook 30 regels sterretjes. Maar “traceroute -I robot-maatje.com”  dat met “ping” probes werkt vindt de server op plaats 10. Probleem met traceroute is dat de medewerking van de tussenstations vereist wordt, en blijkbaar hebben de beheerders redenen om dat niet meer te doen.

Als ping werkt is in principe contact met de server mogelijk, en zou de routing in orde zijn.

Dat reverse lookup niet werkt is niet verbazingwekkend, volgens ipinfo.io zitten er 549831 domeinen op dit adres. Of het klopt kan ik niet nagaan. Genoemd wordt “reactjs.org”, in geval van een routing probleem zou die site, software voor webontwikkeling, dus ook niet te bereiken zijn. Ook alleen IPv4.

host robot-maatje.com
robot-maatje.com has address 76.76.21.21
host reactjs.org
reactjs.org has address 76.76.21.21

Welke "medewerking" van de tussenstations?

@hmmsjan_2  De traceroute is niet op een Mac uitgevoerd maar op een Linux systeem met Ubuntu 20.04.

Overigens heb ik ook even de website reactjs.org geprobeerd en deze is inderdaad ook niet bereikbaar via mijn glasvezel verbinding. Waarschijnlijk kan ik dus geen van die 549831 websites op deze host raadplegen.

Een ping geeft onderstaand

--- 76.76.21.21 ping statistics ---
49 packets transmitted, 0 received, 100% packet loss, time 49145ms

traceroute -I robot-maatje.com geeft 30 keer een sterretje

@wjb traceroute stuurt een verzameling UDP packets het net op met oplopende TTL. Een router verlaagt de TTL met een, en stuurt bij 0 een ICMP boodschap terug dat het pakket weggegooid wordt. Dat teruggestuurde pakket bevat het IP adres van de router en wordt getoond in traceroute. Als die ICMP boodschap niet verstuurd wordt door de router blijft er niets anders over dan sterretjes te tonen. Met ping probes geeft in dit geval het eindpunt gewoon antwoord.

………………...

139.156.98.100 (139.156.98.100)  2.509 ms  2.534 ms  2.556 ms

……………...

09:30:46.046664 IP (tos 0x0, ttl 62, id 10245, offset 0, flags inone], proto ICMP (1), length 88)
    139.156.98.100 > pcbeneden.home: ICMP time exceeded in-transit, length 68
    IP (tos 0x0, ttl 1, id 9883, offset 0, flags tnone], proto ICMP (1), length 60)
 

Als de tussenliggende routers weigeren deze boodschap terug te sturen worden sterretjes afgedrukt.

De website staat niet op zichzelf, voordat het login scherm getoond wordt, wordt ook

smartrobot-solutions.eu.auth0.com aangeroepen op adres 2606:4700::6813:9913

Zou het kunnen dat op uw systeem IPv6 niet correct functioneert en dat de verbinding daarop hangt?

VPN’s ondersteunen IPv6 vaak niet, dus daar verdwijnt het probleem.

U kunt op ipv6-test.com de status bekijken. Wel is het zo dat browsers normaliter terugvallen op IPv4 als V6 niet werkt, maar ik zou niet weten hoe ik het anders moet verklaren. Waarschijnlijk kunt u IPv6 op de router (tijdelijk) uitzetten.

Browsers als firefox, chrome, edge hebben “Developer tools” verstopt in het menu zitten, ik weet niet hoe het zit met Safari. De tab “Netwerk” laat real-time zien welke sites worden aangeroepen met welke vraag en welk antwoord. U kunt daar zien waar de bottleneck zit.

OK, het antwoord is al gepasseerd. Dan begint het dus daadwerkelijk op een routing probleem te lijken en moet het doorgezet worden naar KPN. Ik ben geen deskundige, maar het lijkt erop dat het via een Amazon datacentrum loopt, dus dat zijn geen kleine jongens. Het enige dat verbaast is de static.kpn.net in de traceroute terwijl de anderen 195-190-228-48.fixed.kpn.net en variaties rapporteren, maar de adressen zitten in hetzelfde subnet met dezelfde geolocatie.

Ik kan 76.76.21.18, 76.76.21.19 en 76.76.21.20 van hieruit ook pingen.

Ik zie alleen dit

Ja, dat is duidelijk als de site zelf onbereikbaar is, dus dat helpt niet verder. Ik schreef hierboven dat

ik 76.76.21.18, 76.76.21.19 en 76.76.21.20 van hieruit ook kan pingen. Wat wel vreemd is dat traceroute -I naar 76.76.21.21 veel langer duurt en niet in 7 maar in 10 stappen gaat.

time traceroute -I 76.76.21.20

real    0m0,103s

time traceroute -I 76.76.21.21

real    0m5,087s

reproduceerbaar.

Edit: zegt ook weer niets, “ping -t 10 76.76.21.21” geeft direct respons.

traceroute stuurt probes in batches, wacht op respons, en als niemand antwoord geeft komt na 5 seconden nummer 10 aan de beurt.

Zonder werkende traceroute een lastig probleem.

@hmmsjan_2 

Ja ik baal hier verschrikkelijk van want mijn dagelijks werkzaamheden lopen via dit platform en het heeft tot 26 juni altijd vlekkeloos gefunctioneerd. Het vervelende is dat alle tussenliggende partijen naar elkaar wijzen en zeggen dat het probleem niet in hun systeem zit. Ik vind het vreemd dat niemand mij kan zeggen bij welke stap de verbinding stopt.

Dat is lastig te zeggen omdat de servers na KPN geen ping accepteren. Mogelijk uit veiligheid, wat je regelmatig ziet. 

Ik blijf erbij dat het probleem bij de serverbeheerder zit. Als er een storing was, dan was dat allang ontdekt.

@AriënC  “Als er een storing was, dan was dat allang ontdekt.”

Nou dat moet je niet zeggen ik kon een aantal jaren geleden geen mail versturen als ipv6 op het modem aan stond. KPN kon traceren dat er op de route switch niet goed functioneerde dat heeft 1.5 jaar geduurd voordat ze de juiste locatie konden traceren. 

Dus als er ergens ver weg iets mis gaat is het vaak niet zo gemakkelijk te vinden, maar de techniek van nu zal zeker weer een stuk beter zijn als een aantal jaren geleden.

Ik hoop dat @Alexandra van KPN dit issue voor zal leggen aan de netwerkexperts binnen KPN.

Rare vraag: gebruikt u misschien ESET Thuis van KPN? 

@Nick83 Nee ik gebruik geen ESET van KPN en ook geen ander antivirus programma