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?

@FrozenNL

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

Nee, dat zou mij tenminste verbazen.

Maar ik heb wel eens eerder gehoord dat de stabiliteit van VPN naar een bepaald VPS platform te wensen overliet. En dat bleek aan dat platform te liggen. Wat is het platform waarop je VPS draait?

Trouwens, vertelt traceroute je niet of het probleem bij Odido ligt, of bij je VPS hoster?

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

(Dit is traceroute onder linux. Tracert onder Windows heeft minder opties. Laat maar even weten als je hiervoor een oplossing zoekt.)

  @harmenzo 

traceroute - T of U] -O info -p pport] ]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.

@harmenzo

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:

via Odido thuis glasvezel werkt het ook hoor, maar binnen een uur stopt dit, vermoedelijk een cron die wat zaken naloopt en dan blokkeert. Ik heb helaas niet gelet of het telkens op een vaste minuut geblokkeerd worden, en heb ook niet zoveel zin om er meer IP-adressen voor te huren bij TransIP om dat uit te vogelen.

@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 

Ja, ik gebruik de Zyxel EX5601-T1, maar ook na een factory reset geen verbinding op een reeds eerder gebruikt IP, dus ook geen volgelopen caches op de router, dit zal toch wel resetten na een fabrieksherstel?

@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! 

Bijna heel uur (14:58 nu), draai nu al die tijd al op de VPN, ben benieuwd

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

Draait nog steeds, misschien had het te maken met proxy_arp welke niet aan stond in /etc/sysctl (Debian 12; WG server) voor de "blokkade”, als het over 48 uur nog steeds stabiel is, ga ik er voorzichtig van uit dat het is opgelost.

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

@FrozenNL

De opsommingen A:F is niet helemaal helder voor mij maar ik denk dat de screenshots duidelijkheid geven

Met a t/m f wil ik zeggen dat het netwerk verkeer tussen de VPN client en server "verpakt" zit in UDP pakketjes. Dat netwerk verkeer, inclusief het publieke ip adres van de VPN client interface, zit dus in de "payload" van die UDP pakketjes. Het publieke ip adres van de VPN client interface verschijnt dus niet als afzender of bestemming van die UDP pakketjes zelf. (Sorry als ik hiermee een open deur intrap.) Je Zyxel en Odido zien dat ip adres dus helemaal niet. Het is onzichtbaar omdat het in de VPN tunnel zit, om hetzelfde nog maar eens op een andere manier te zeggen. Omdat het probleem blijkens je beschrijving aan dat ip adres gekoppeld lijkt te zijn, vormt dat een aanwijzing waar de oorzaak vermoedelijk wel en niet zit.

Bedankt voor de screenshots.

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.

En misschien dat deze loop werd gezien als een soort DOS aanval ofzo en dat het hierdoor wordt geweerd, geen idee of er mechanismes zijn die zo een loop herkennen en dan denken na er x te hebben gedaan ehhh ik stop hier nu maar mee ofzo, of ik zet dit maar even op een unroutable lijst, of dat het voor een overload zorgt, ik heb hier te weinig zicht op hoe dit precies werkt.

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?

En zal trouwens alleen de poorten forwarden vanaf de VPN server welke echt nodig zijn, scheelt weer overhead van scan botjes. De keuze is eigenlijk een protocol met hardware acceleratie of Wireguard welke weinig overhead heeft van zichzelf, het verkeer zal redelijk worden, zeg 500-700 connecties met 150-250mbit throughput in de pieken, geen idee of dit mogelijk is met Wireguard of dat ik hier toch IPSec voor moet gaan gebruiken met hardware acceleratie. Maar goed, probleem lijkt voor nu opgelost. Van mij mag deze op slot.