VPN met fixed IP publiek toegankelijk geblokkeerd?

Sorry, ik had het bericht eerder geplaatst, een heel stuk meer uitgebreid en duidelijker, maar deze is na het bewerken gewoon verdwenen, dus ik bewerk het bericht niet meer.

Maar de zinsopbouw loopt niet zo lekker zie ik, hier mijn vraag opnieuw nu met juiste opbouw:

Vraagje, ik heb een 4 tal IP-adressen op een KVM VPS bij een grote Nederlandse hoster uit Leiden, op deze VPS draai ik een VPN-server (wireguard) waarmee ik een verbinding maak tussen een client op het Odido thuis netwerk, deze VPN verbinding is geprobeerd op te zetten, met succes, maar wordt per IP keer op keer geblokkeerd na ca. 10 tot 60 minuten, het werkt even prima, goede ping, ik haal ermee 300 mbit/s, maar ineens valt de verbinding weg, alsof het wordt geblokkeerd door Odido? Wat ik ook probeer, firewall instellingen nalopen, debuggen met traceroute en MTR, alle logs nalopen, de verbinding komt niet meer terug.

Enige hoe ik de verbinding weer terug krijg is als ik VPN client een ander publiek IP-adres geef via de VPN-server, dan werkt het weer even, 10-60 minuten en BAM weer geblokkeerd, logisch hoor als dit afwijkende gedrag wordt geblokkeerd op een thuis abonnement, dit was mijn manier om het ontbreken van een vast IP adres bij Odido thuis op te lossen en ervoor te zorgen dat het toch een vast IP adres heeft, al dan niet via een heel ander netwerk.

Klopt het dat een dergelijk afwijkend internetpatroon wordt geblokkeerd door Odido glasvezel thuis?

En zoja, is er bekend of met Odido zakelijk dit wel is toegestaan?

  @harmenzo 

traceroute -[T of U] -O info -p [port] [host]

Het betreft TransIP. Traceroutes, logs bekeken, MTR allemaal al gedaan, niets bijzonders op te zien. Caches geleegd (ARP, iptables en DNS), reboots gedaan, het werkt prima, tot dat het ergens wordt geblocked, daarna werkt het simpelweg nooit meer er is geen uitgaand en inkomend verkeer meer mogelijk, ik heb bij TransIP navraag gedaan en ze hebben het nagekeken maar ze hebben niets geblokkeerd of dergelijke blokkerende mechanismes in werking.

Ik zal kijken of het wel lukt via 4G hotspot (Odido) en later ook via een Ziggo client bij een vriend om de VPN verbinding tot stand te brengen, dan sluit het in ieder geval uit of dergelijke verkeer op IP basis via TransIP wordt geblocked of niet, dat had ik nog niet gedaan.

@FrozenNL 

via 4G werkt dit prima, mooie verbinding, geen 300/300 natuurlijk over 4G zoals via glasvezel, maar de VPN verbinding is technisch dik in orde:

Het zou wellicht ook een tekortkoming van je router thuis kunnen zijn. Gebruik je de Zyxel?

@harmenzo 

VPN verbinding doet het nu wel weer, mogelijk slechts een 24 uur block, ik zal het even monitoren en extra aandacht geven aan de router om te zien of dit het knelpunt is. Misschien had ik gisteren zo lopen klooien met de instellingen dat na de factory reset het niet goed stond en het daarom niet werkte (bijv. doordat ik SNAT regel niet goed had staan iptables), ik hou het scherp in de gaten, bedankt voor de feedback, waardeer ik sterk! 

@FrozenNL

Ik zet even een paar dingen op een rijtje. Correct me if I'm wrong...

1) Je hebt een (wireguard) VPN server op je VPS.

2) Je hebt een VPN client op een PC (of ander soort host) achter je Zyxel thuis.

3) De VPN interface op je VPS heeft een lokaal ip adres.

4) De VPN interface op je PC thuis heeft een publiek ip adres.

5) De VPN loopt over UDP tussen VPN client en VPN server.

6) Op een gegeven moment werkt de VPN verbinding niet meer, totdat de VPN client een nieuw publiek ip adres krijgt (of je 24 uur wacht).

Een paar gevolgtrekkingen:

a) Het publieke ip adres van de VPN client interface is alleen zichtbaar op de PC thuis en op de VPS. Daartussen zit het verpakt in UDP. De Zyxel en Odido zien alleen die UDP pakketjes.

b) De bestemming van die UDP pakketjes komende vanaf je thuisnetwerk is het publieke ip adres van je VPS.

c) De afzender van die UDP pakketjes is eerst een lokaal ip adres van je PC. De Zyxel doet NAT. Daarna is de afzender het publieke Odido ip adres.

d) Pas op je VPS host komt het publieke VPN client ip adres weer tevoorschijn, en gaat vandaar eventueel verder het internet op.

e) Je publieke VPN client ip adres is dus alleen zichtbaar op je PC thuis, en op je VPS, en vandaar eventueel verder op internet.

f) Omdat het probleem gekoppeld is aan het publieke ip adres van de VPN client, ligt het voor de hand dat het probleem veroorzaakt wordt op een plaats waar dat ip adres zichtbaar is. Dat is dus of op je PC thuis, of bij je VPS.

Toen je de VPN met een mobiele dataverbinding testte, had je toen een VPN client op je telefoon, of gebruikte je de telefoon als router, met de VPN client nog steeds op de PC? In het laatste geval kun je de PC thuis als oorzaak van het probleem wegstrepen. In het andere geval eerder je VPS en het TransIP netwerk/platform.

P.S. Laat eventueel eens iets zien van de routing tables op de VPS en PC als je wilt.

@harmenzo

hierbij de gevraagde info met wat extra's opsomming 1 t/m 6 is correct als ik het goed begrijp, voor de zekerheid heb ik even screenshotjes toegevoegd van WG client en WG server config

De opsommingen A:F is niet helemaal helder voor mij maar ik denk dat de screenshots duidelijkheid geven, de VPN-server geeft client rechtstreeks een publiek toegankelijk IP adres, alles wat op VPN-client draait is bereikbaar extern op het IP adres dat wordt gegeven op de VPS, dit is ook precies de bedoeling. De VPN client die dus achter de Zyxel zit, heeft een firewall die regelt welke poorten wel/niet openstaan naar de rest van het web en dit werkt prima.

Oh zo, ja klopt, is versleuteld TCP/UDP over UDP verkeer inderdaad, geen idee wat de initiele handshake is van Wireguard, er zijn meerdere manieren om bepaalde patronen te ontdekken voor een ISP, het is meer dat ik dit vroeg om het uit te sluiten, dan weet ik dat ik nog even verder moet zoeken naar iets wat ik er zelf nog aan kan doen. Maar het draait nog steeds onafgebroken ik denk dat het arp_proxy was welke uitstond wat voor problemen zorgde, en daardoor misschien een kleine loop ontstond in de router. Ik had gezegd dat ik niets vreemds had gezien maar nu ik hieraan zit te denken merkte ik gisteren wel dat er een online traceroute dienst was welke in een hop loop kwam, ging door terwijl eindpunt al gevonden was tot maximale hop 30 welke was ingesteld als maximum, ik was niet zo bekend met die traceroute service, was ook de enige waar ik dat gedrag verder zag.

Het blijft nu gewoon draaien, super bedankt voor je hulp @harmenzo uurtje wezen iperfen, zo stabiel als maar zijn kan en voor zover ik dat kan beoordelen in 24 uur. Mocht het toch weer fout gaan zal ik zeker de router onder de loep nemen en eventueel een mikrotik router aanschaffen welke zelf de VPN client speelt zodat het uiteindelijke gebakkie, proxmox 128GB RAM 20 core i7-14700K geen extra CPU taken hoeft te doen, toevallig nog een suggesties voor mikrotik router welke hardware ondersteuning heeft voor de versleuteling?