Verbinding met bepaalde site niet mogelijk vanaf vast internet

Ik heb de volgende vraag al naar de helpdesk gestuurd, maar het is vast handig om het ook hier vragen…

Het lukt me niet om op een bepaalde site te komen en dit lijkt alleen bij (mijn?) freedom internet niet te werken. De site is https://parawave-audio.com/ ik ben eigenlijk benieuwd of anderen er wel bij kunnen. Dit soort dingetjes zijn al eerder gebeurd, zelfs www.isitdownrightnow.com was al eens onbereikbaar voor alleen mijn (vaste) internet, maar dan is het meestal na een dag ofzo weer goed. Nu blijft bovenstaande site onbeschikbaar.

Ik heb het op verschillende browsers en machines geprobeerd, zonder succes. Zodra ik op mijn mobiel overschakel naar data abonnement kan ik er meteen wel bij. Ga ik terug naar wifi, meteen niet meer. Ook vanaf m’n werk kan ik de site gewoon prima bereiken. Ik heb de router maar gereset, ook zonder succes.

Het is in deze situatie nogal vervelend omdat ik er software wil kopen, maar de registratie doet een online check, dus al kan ik het vast via mobiel of werk bestellen en downloaden, die check na installatie gaat dan niet lukken. Als het echt moet vind ik wel een workaround, desnoods via VPN, maar hopelijk kan dit gewoon opgelost worden.

Kunnen anderen wel bij die site? En misschien iemand een idee wat het kan zijn? Zou het toch een router dingetje kunnen zijn misschien? Ik heb de standaard Fritzbox 7590, firmware 7.57.

Groeten, Robin

IPv4 ellende:

Zie ook deze topics.

1 like

Geeft bij mij een lege pagina en 500 - Internal Server Error in developer tools.

1 like

Hier zelfde uitdagingen op die sites. The IPv4 only sites zijn een probleem door de hergebruikte ipv4 adressen binnen het Freedom netwerk. Ze zijn correct geregistreerd, maar veel sites hebben nog oude geoip gegevens.

We kunnen alleen hopen dat de sites nu eindelijk eens iets met ipv6 gaan doen.

1 like

Dank voor alle reacties!

Ik was hier al bang voor eigenlijk, dat het misschien geen technisch probleem was maar een geblokkeerd IP, of een oude foute range ergens. Het viel me al eerder een keer op ik op bepaalde plekken onder een range-block zat. Iets dat ik raar vond, want zoiets verwacht ik niet bij providers met statische IP’s. Maargoed, ik was even vergeten dat we hier waarschijnlijk oude adressen van onbekende ex-eigenaren hebben. En dat met de neiging van sites om perma-bans te doen (wat ik ergens wel begrijp, want een simpele blacklist is nou eenmaal snel en simpel) zal me nog wel meer verassingen gaan opleveren vrees ik.

Was nooit een issue met m’n trouwe oude xs4all IP (of demon daarvoor), ik had graag bij betaald om m’n IP mee te kunnen nemen als een telefoonnummer, maargoed, dan maar wachten op een toekomst met volledige IP6 adoptie :slight_smile:

Die krijg ik dus ook. Totaal geen extra informatie verder. Het enige opvallende was dat bij de aanroep ik wel meteen index.php achter het adres werd geplakt, dus het komt wel bij een webserver aan, lijkt het.

Ik denk dat ik maar eens een mailtje ga sturen naar die site, wat bij jou blijkbaar werkte. Niet geschoten is altijd mis en als ze een verkoop mislopen (moeten ze het wel fixen voor black friday) zijn ze misschien wat enthousiaster om het te herstellen.

1 like

De adressen die ik heb gehad (KPN en FiberCrew range) kwamen uit Oekraine voor recycelen… Er zijn sites die dat geen prettige bron ven requests zijn. (zorg instellingen o.a. vinden dat je uit EU of NL moet komen)

1 like

De situatie is zowaar nog iets vreemder geworden, dus ik deel het even:

De eigenaar heeft me ondertussen terug gemailed:

Thank you for your interest in Rapid. We checked the issue and can say that we don’t block any IP ranges to the Netherlands. We got an email from freedom.nl and checked the mentioned IP ranges, but honestly have no reason to block any IP ranges so far. We have several customers in the Netherlands and didn’t get any reports or complaints so far.
My best bet here is that either the provider does something unusual, or our hosting provider blocks on a higher level. If this is the case we can’t really do anything about it unfortunately.

We will look into the issue and check if this is the case.

Freedom, bedankt voor het mailen naar ze! Jammer dat ze het dus ook niet weten.

Nu heb ik zelf ook nog even wat zitten spelen, want ik ben toch nieuwsgierig aan het worden. Als ik op mijn machine inlog via m’n werk VPN en daar de proxy van instel, dan kan ik er gewoon bij. De hele site werkt dan prima. Dat is in ieder geval al handig om te weten, maar het opvallende is: als ik die verbinding verbreek, dan blijft de site werken! Ook pagina’s die ik nog niet bekeken had, dus niet vanwege cache. Echter, alleen op de browser die ik er al voor gebruikt had. Ook na een reboot en een dag later werkt alles nog.

Ligt het dan aan de cookies dacht ik? Dat waren de volgende: PHPSESSID, currency en language. Wat blijkt nou, deze zitten ook al in de niet-werkende browsers. Blijkbaar worden die gewoon al weg geschreven, ondanks de foutmelding.

Cookies betekent leven, dus misschien ook werkende static content? En inderdaad: een url van een plaatje werkt wel gewoon overal: https://parawave-audio.com/image/cache/catalog/pw-xt/boxart-dh-01x01.jpg

Wie begrijpt het nog? :sweat_smile:

Kan dan alleen maar op de server zitten. Plaatje werkt hier bij mij ook, website niet. Logische stap is dan toch echt dat de website eigenaar in de logs gaat kijken wat er gebeurd. Bovenstaand verhaal en daarbij je IP-adres en datum + tijdstip van je bezoek dat een 500 error oplevert, zou voor hen voldoende moeten zijn om dit te achterhalen. Mochten ze zelf geen beheer hebben over de webserverlogs (bijv. bij shared hosting), dienen ze dit even naar hun hostingprovider door te sturen. Elke fatsoenlijke hoster pakt een dergelijk verzoek op.

Lijkt er heel erg op dat hun hosting provider een Blocklist heeft waar diverse IPv4 adressen, die nu in gebruik zijn bij Freedom, op staan. Maar dat is dus gebaseerd op oude informatie.

Als ze nu ook via IPv6 zouden hosten was er dus niks aan de hand geweest…

Sowies. Zo’n 500 is een server error. En wat robin ook al concludeerde:

Wellicht een vergeten geo-module in hun php. Zo’n 500 geeft aan dat de webserver of code het niet meer weet en het request uit de handen laat vallen.

In dit soort gevallen kijkt ik altijd even hier: