VPN snelheid daalt naar bijna nul tijdens roamen in Belgie.

[Supke]

Ik had onderstaande vraag op de Vodafone community site gepost en kreeg het advies het hier bij Tweakers te posten omdat hier vermoedelijk meer kennis aanwezig is.

Het volgende is aan de hand.

Als ik van huis ben gebruik ik bijna altijd een VPN (OpenVPN) verbinding naar mijn thuis netwerk zodat ik mijn lokale services kan bereiken.

Ik kom geregeld in België en wat er steeds gebeurt is: zodra ik in België naar een Belgische provider roam (Proximus en OrangeB getest) valt de VPN snelheid terug naar bijna nul. Mijn 192kbps Icecast stream valt vrijwel helemaal stil buffert alleen nog maar met grote pauzes ertussen,websites zowel lokaal als op Internet laden mega traag. Zodra ik de VPN verbinding verbreek loopt het streamen weer goed en kan ik alles weer normaal bereiken behalve mijn lokale servers uiteraard.

Mijn OpenVPN is geen split tunnel, alle verkeer gaat over de tunnel. Ik gebruik een alternatieve UDP poort voor de OpenVPN server thuis. Zodra ik in NLD ben en weer via Vodafone online ben werkt alles perfect en snel.

Heeft iemand enig idee wat hier aan de hand kan zijn?
Ik heb dit probleem al heel lang en me altijd afgevraagd waar het aan ligt en of ik er ets aan kan veranderen.
In NLD werkt alles tiptop.

[FredvZ]

Supke schreef op zondag 11 augustus 2024 @ 16:03:
Mijn OpenVPN is geen split tunnel, alle verkeer gaat over de tunnel. Ik gebruik een alternatieve UDP poort voor de OpenVPN server thuis. Zodra ik in NLD ben en weer via Vodafone online ben werkt alles perfect en snel.

Welk poortnummer heb je gekozen?

[anboni]

Supke schreef op zondag 11 augustus 2024 @ 16:03:
Mijn OpenVPN is geen split tunnel, alle verkeer gaat over de tunnel. Ik gebruik een alternatieve UDP poort voor de OpenVPN server thuis. Zodra ik in NLD ben en weer via Vodafone online ben werkt alles perfect en snel.

Klinkt als traffic shaping. Probeer eens om te bouwen naar tcp/443 als je die mogelijkheid hebt.

[Supke]

@FredvZ
Ik gebruik UDP 1299 voor de OpenVPN server.

@anboni
Dat kan wel maar is nogal een gedoetje. Ik ben ondertussen bezig contact te maken met Proximus. Op hun forum kan je niet zomaar registreren dus ga zo een email zenden met mijn vraag.

Klinkt als "traffic shaping" inderdaad maar zou internet niet transparant moeten zijn en we hebben toch ook nog zoiets als netneutraliteit?

Ik wil even een antwoord afwachten van een van de Belgische providers.
Ik zou ook nog OpenVPN port sharing kunnen gebruiken dan kan ik de OpenVPN server én mijn webserver tegelijk op poort 80/443 laten draaien.
https://www.vpntutorials....webserver-on-port-80-443/

Maar deze opties wil ik nog even mee wachten tot ik precies weet wat er gaande is anders ben ik dingen aan het instellen die misschien niet gaan werken. Als ik zeker weet wat er precies gebeurd kan ik daar meer gericht omheen werken hoop ik tenminste,

[FredvZ]

Supke schreef op maandag 12 augustus 2024 @ 11:14:
Klinkt als "traffic shaping" inderdaad maar zou internet niet transparant moeten zijn en we hebben toch ook nog zoiets als netneutraliteit?

Het komt niet vaak voor, maar het kan ook aan de routering liggen tussen de Belgische providers en jouw Nederlandse provider thuis, bijvoorbeeld:
- Een van de schakels in de route naar huis heeft een lage bandbreedte of gebruikt een lagere MTU
- De UDP-pakketten worden de verkeerde kant op gerouteerd (hetzij de van de Belgische provider naar jouw huis of v.v.)


Ik heb geen idee welke MTU sizes de Belgische providers gebruiken. OpenVPN staat standaard op 1500, dit zou je steeds met stappen van 8 verlagen totdat het wel werkt.

[Supke]

@FredvZ

Ik heb thuis Ziggo en mijn mobiele provider is Vodafone.

Als ik geen VPN gebruik zijn alle verbindingen goed en snel, ook naar mijn servers thuis die ik over het open Internet kan bereiken zoals de httpd.

MTU kan ik inderdaad eens aanpassen, goed idee. Daar zal ik ook eens mee knutselen net als de poort zal ik veranderen zodra ik een antwoord heb van een van een van de providers.

Anders ben ik straks lukraak dingen aan het veranderen die later onnodig bleken.
Als ik een onbevredigend antwoord krijg op mijn vragen aan de providers ga ik dat zeker testen allemaal 👍 en houd jou/jullie op de hoogte.

[jeroen3]

Geven de logs nog enige info? Kun je die meer verbose maken voor het troubleshooten?

[Supke]

@jeroen3

Dat is een goeie.
Ik zeg het altijd tegen anderen kijk in de logs en nu heb ik er zelf totaal niet aan gedacht 🙄

Dus ik ben er eens even in gedoken de openvpn log staat nogal vol prive gegevens dus die kan ik niet zomaar delen maar wat ik wel apart vind is een MTU van 1600 ???

code:

Aug 11 15:21:56     openvpn     12197   109.38.xxx.xxx:33476 peer info: IV_MTU=1600
Aug 11 15:21:56     openvpn     12197   109.38.xxx.xxx:33476 peer info: IV_PROTO=990
Aug 11 15:21:56     openvpn     12197   109.38.xxx.xxx:33476 peer info: IV_TCPNL=1
Aug 11 15:21:56     openvpn     12197   109.38.xxx.xxx:33476 peer info: IV_NCP=2
Aug 11 15:21:56     openvpn     12197   109.38.xxx.xxx:33476 peer info: IV_PLAT=android
Aug 11 15:21:56     openvpn     12197   109.38.xxx.xxx:33476 peer info: IV_VER=3.8.5connectQA3

[Ben(V)]

Mtu veranderen zal echt helemaal niets helpen.
Mtu werkt zo wie zo alleen binnen een Lan op het internet wordt dat door de apparatuur van de provider geregeld en als je een andere dan standaard mtu gebruikt, werkt dat enkel vertragend omdat de pakketjes dan opgesplitst moeten worden.

Als het vanuit Nederland wel lekker werkt en vanuit België niet dan ligt het aan de Belgische provider.
Als die aan traffic shaping doen kun je poort 433 proberen die laten ze meestal wel met rust.

Enige performance winst is ook nog te behalen door binnen de VPN tunnel voor UDP te kiezen en niet voor tcp.


PS Wat jij in de log ziet is de mtu binnen de tunnel en die wordt door Openpn zelf ingesteld in samenspraak met de OpenVpn client en heeft niets met de mtu van je lan of je provider te maken.

[Supke]

@Ben(V)

Hmm oke ik was al aan het klooien geslagen met de MTU dus dat heeft geen zin dan ga ik dat zo weer eruit slopen.

UDP is ook wat ik gebruik op poort 1299 voor de OpenVPN server.

Ik wacht nog even een reactie af van Orange.be waar ik ondertussen op het forum een bericht heb geplaatst. En Proximus heb ik een mail gestuurd dus dat ga ik even afwachten als dat geen soelaas bied dan ga ik inderdaad eens poort 443 instellen met de shared port option omdat ik reeds een httpd op poort 443 heb. Misschien kan ik nog een andere standaard poort bedenken die ze niet snel zullen blokken / knijpen en ik niet in gebruik heb op de WAN thuis.

[jeroen3]

@Ben(V) Nou dat lijkt me wel essentieel, want ondersteuning voor fragmentatie in openvpn is optioneel zo lijkt het.

quote: https://openvpn.net/commu...e-manual-for-openvpn-2-4/

--fragment adds 4 bytes of overhead per datagram.

See the --mssfix option below for an important related option to --fragment.

It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead.

Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation.

icecast is multicast, speel hier eens mee?

Je kunt ook TCP gebruiken, dan zijn dit soort dingen doorgaans geen probleem meer.

Je zou natuurlijk als het probleem zich voordoet even wat kunnen pingen met variabele lengte. Dan kun je vinden of je mtu echt een probleem is.

[ Voor 7% gewijzigd door jeroen3 op 12-08-2024 13:28 ]

[FredvZ]

Ben(V) schreef op maandag 12 augustus 2024 @ 12:47:
PS Wat jij in de log ziet is de mtu binnen de tunnel en die wordt door Openpn zelf ingesteld in samenspraak met de OpenVpn client en heeft niets met de mtu van je lan of je provider te maken.

Niet helemaal, als de MTU van je VPN groter is dan of gelijk is aan de MTU van de carrier dan kan dat nog steeds tot issue's leiden.

[Supke]

Oke even een pluim voor Proximus.be. Nadat 1 medewerker uit de chat was gevlucht na mijn vraag kreeg ik bij de volgende een onverwacht uitgebreid antwoord:

"Hallo,

Het lijkt erop dat het probleem dat je ervaart, te maken heeft met de netwerkomstandigheden wanneer je in België bent en verbindt via een Belgische provider. Hier zijn een paar mogelijke oorzaken en oplossingen:

Roaming en VPN: Bij roaming kunnen providers bepaalde beperkingen opleggen op netwerkverkeer, vooral op VPN's. Het is mogelijk dat Proximus en OrangeB beperkingen opleggen aan VPN-verkeer, wat leidt tot de lage snelheid die je ervaart. Dit kan een manier zijn om de netwerkbelasting te beheren of om specifieke vormen van dataverkeer te beperken.

Poortbeheer: Je gebruikt poort 1299 voor de VPN, wat een ongebruikelijke poort is. Hoewel dit normaal werkt in Nederland, kan het zijn dat de Belgische providers verkeer op deze poort throttlen of zelfs blokkeren. Je zou kunnen proberen om over te schakelen naar een meer gangbare poort, zoals 443 (de standaard HTTPS-poort), die minder kans heeft om beperkt te worden door providers.

UDP versus TCP: Je geeft aan dat je OpenVPN via UDP gebruikt. UDP-verkeer kan soms minder stabiel zijn over netwerken met strengere beperkingen of hogere latency, wat vaker voorkomt bij roaming. Een mogelijke oplossing is om OpenVPN over TCP te proberen, hoewel dit iets trager kan zijn, biedt het meestal meer stabiliteit.

ISP-instellingen in België: Het kan ook zijn dat de Belgische providers gewoonweg een lagere prioriteit geven aan VPN-verkeer of dat ze hun netwerken anders configureren voor buitenlandse klanten, wat kan leiden tot een trager verkeer.

Split-tunnel configuratie: Hoewel je aangeeft dat je een full-tunnel gebruikt, zou je ook kunnen overwegen om een split-tunnel te configureren voor tests, zodat alleen het verkeer dat naar je thuisnetwerk moet, door de VPN gaat. Dit kan helpen om de belasting te verlagen en te zien of het probleem zich nog steeds voordoet.

Hopelijk kan je door deze stappen eens te ondernemen een oplossing vinden. Kan ik je verder nog met iets helpen?"

Wat jullie dus ook al vermoeden word mijn ongebruikelijk OpenVPN poort geknepen die ga ik dus toch maar eens veranderen dan.

[Ben(V)]

Die medewerker heeft er duidelijk weinig verstand van.
Het enige zinvolle wat hij zegt is dat providers aan traffic shaping kunnen doen, maar dat moet dan in België liggen, maar daar is hij zelf de helpdesk van dus zou hij moeten weten of dat geberud.
Bij mijn weten doet geen enkele Nederlandse provider aan traffic shaping.

Het verschil tussen udp en tcp is dat tcp garandeert dat elk pakketje aankomt en udp niet, maar het VPN protocol zorgt daar al voor dus is tcp gebruiken is gewoon overhead.

En voor de duidelijkheid, verkeerde of niet matchende mtu settings hebben wel invloed, maar dat is marginaal en nauwelijks waarneembaar.

Zoals al gezegd is je beste kans poort 433 te gebruiken.

[ Voor 9% gewijzigd door Ben(V) op 12-08-2024 14:27 ]

[jeroen3]

Lol. dat lijkt ernstig op chatgpt.

[DukeBox]

Ben(V) schreef op maandag 12 augustus 2024 @ 12:47:
Als die aan traffic shaping doen kun je poort 433 proberen die laten ze meestal wel met rust.

Ben(V) schreef op maandag 12 augustus 2024 @ 14:24:
Zoals al gezegd is je beste kans poort 433 te gebruiken.

Bedoel je niet 443?

[Supke]

Hmm ja verdomd ChatGPT dat kan natuurlijk ook nog.
Want ze zeggen niets met zekerheid dat het wel of niet zo is.
Ze zeggen dat het zo zou kúnnen zijn.

Maar goed poort 443 is een beetje lastig omdat die al in gebruik is. Ik overweeg de port sharing optie te gebruiken maar ik heb dat ooit al eens gebruikt en ik weet niet meer hoe dat toen uitgepakt heeft.
Ik zit nu even na te denken of ik niet een andere poort daarvoor kan bedenken ipv 443

Daarbij is bij mij alles dualstack ook mijn services naar buiten toe op de WAN.
Dat is voor android via vodafone geen issue want dat gebruikt tot nog toe alleen ipv4

[Ben(V)]

@DukeBox
Sorry je hebt gelijk moet 443 zijn.

[Ben(V)]

Alleen de https poort(443) wordt gegarandeerd met rust gelaten omdat het heel gecompliceerd is om onderscheid te maken tussen https en VPN verkeer omdat beiden encrypted zijn.

Maar blijkbaar draai je zelf een webserver die poort 443 gebruikt.

[Supke]

jeroen3 schreef op maandag 12 augustus 2024 @ 13:27:
@Ben(V) Nou dat lijkt me wel essentieel, want ondersteuning voor fragmentatie in openvpn is optioneel zo lijkt het.


[...]

icecast is multicast, speel hier eens mee?

Je kunt ook TCP gebruiken, dan zijn dit soort dingen doorgaans geen probleem meer.

Je zou natuurlijk als het probleem zich voordoet even wat kunnen pingen met variabele lengte. Dan kun je vinden of je mtu echt een probleem is.

Oei multicast heb ik weinig ervaring mee.
Mijn Icecast heeft gewoon een rfc1918 ip adres.
Bovendien is mijn icecast niet alleen lokaal maar ook op de wan bereikbaar met weliswaar een whitelist ervoor maar ik denk niet dat multicast over het internet gaat werken zomaar ik heb er in elk geval niet genoeg kennis van.

Voorlopig ga ik voor het veranderen van de openvpn server poort moet alleen nog even nadenken hoe en wat precies.

[DukeBox]

Supke schreef op maandag 12 augustus 2024 @ 14:39:
Maar goed poort 443 is een beetje lastig omdat die al in gebruik is.

Evt. eerst eens proberen middels een (trial) VPS en die dan doorsturen naar je eigen netwerk met een apparte tunnel?
Als je poort 22 niet gebruikt kan je die evt. ook nog proberen of dat beter werkt.

[Ben(V)]

Misschien kun je Tailscale gebruiken in plaats van OpenVpn.

[jeroen3]

@Ben(V) of zerotier

[Supke]

@DukeBox

Ik zou in de WAN OpenVPN rule inkomende poort op 22 kunnen zetten en de poort lokaal voor pfsense op 1299 kunnen houden maar omdat mijn clients zowel lokaal als via internet die vpn gebruiken moet ik lokaal ook rules of misschien wel nat gebruiken. Ik heb ook nog sshd op de pfsense lopen.
enfin dat loopt me allemaal wat boven mijn pet. Ik ben bang dat ik het overzicht verlies.
Want er loopt nog meer zooi op mijn pfsense.

Simpeler lijkt me die openvpn server naar een andere poort zetten zodat lokaal en op internet alles op dezelfde vpn poort loopt. En dan een poort die ik niet in gebruik heb op de wan maar ook niet local op de pfsense host zelf.

[Supke]

@Ben(V)
@jeroen3

Andere VPN servers zoals jullie voorstellen zou een optie kunnen zijn al loop je daar misschien ook tegen hetzelfde probleem aan.
Als ik het niet kan oplossen met openvpn dan zal ik daar eens naar kijken of misschien wel ernaast opzetten om te testen dat is misschien wel een idee.

[Supke]

Poorten 389 (LDAP) en 636 (LDAPS) getest maar nog geen verbetering.
Ik woon paar honderd meter van de Belgische grens kan dus gemakkelijk testen.

Ik heb er nog een ander toestel van mijn vrouw ernaast zonder VPN loopt daar het mobiele internet normaal via Proximus dus het ligt echt aan de VPN verbinding nog steeds. 😣

[Ben(V)]

Als ze echt aan shaping doen werkt een andere poort ook niet.
Als 443 is mogelijk omdat ssh ook encrypted is.

[Supke]

Dan moet ik 443 inderdaad maar eens instellen alleen al om te testen en het zeker te weten dat het dan wel werkt. Als het dan wel werkt moet ik maar eens gaan nadenken hoe ik dat ga doen misschien toch met port sharing in OpenVPN. Eerst maar eens die 443 testen.

[Supke]

Oke zonet UDP poort 443 getest dat werkte ook niet.
Toen TCP 443 getest en warempel dat werkte meteen als een speer en snel ook.
Nu weet ik het zeker dat ze dus inderdaad alles enorm knijpen of zeg maar gerust onmogelijk maken behalve TCP 443.

Ik heb daarna ook nog OpenVPN port sharing ingesteld zodat ik tegelijk mijn OpenVPN én mijn http server op poort 443 kan connecten dat werkt nu ook, top!

Bedankt allemaal voor de tips en informatie dat me naar de oplossing heeft geleid 👍

[ Voor 4% gewijzigd door Supke op 12-08-2024 20:21 ]

[Paul C]

Fijn dat je het opgelost hebt, maar wel triest van deze constatering dat je eigenlijk maar 1/65536e van je internet kan gebruiken. Wat mij betreft is dit toch minstens wel een klacht waard.

[Supke]

@Paul C

Daar ben ik het 100% mee eens.
Maar ja ik weet niet of die Belgische providers dit ook doen bij hun eigen klanten of alleen bij roaming klanten van buitenlandse collega providers.

Ik heb dit al eens bij Vodafone aangegeven in een Enquête plus ik heb de vraag ook op hun community gezet en tevens ook op het forum van orange.be bij proximus kon ik niet zomaar registreren op hun forum dus daar kwam ik niet zo 1 2 3 op.

Dus ja waar kan je nog meer klagen hierover?
Mij lijkt dat dit helemaal niet mag dus misschien wel bij het EC bij de juiste persoon onder de aandacht brengen.

Maar ja als maar weinig mensen hier last van hebben en nog minder mensen gaan erover klagen bij instanties dan gaan die lui niets doen natuurlijk.

[m.eddy]

Wellicht niet relevant meer maar ben in België en zit ook op Proximus. Poort 51820 WireGuard heeft geen last van throttling. Die gebruik ik om terug te verbinden naar mijn netwerk.

[Supke]

@m.eddy

Zeker is dat nog steeds relevant en heel goed dat je het laat weten.
Als ik die OVPN Port Sharing niet hoef te gebruiken dan heeft dat mijn voorkeur dus ik ga die poort morgen zeker testen. En laat het weten hoe het uitpakt.
Alvast bedankt!

Maar als ik je verhaal dus goed begrijp doen de Belgische providers dat dus ook bij hun eigen klanten, sjezus!

[m.eddy]

Nou nee ben gewoon op vakantie hier en roam blijkbaar op Proximus 4G hier.

[Supke]

Ah oke op die fiets ☺️
Hoe dan ook bedankt voor de tip van poort 51820
Weet je toevallig of udp of tcp nog verschil uitmaakt?

[m.eddy]

Alleen UDP blijkbaar https://en.m.wikipedia.or...%20%22TCP%20meltdown%22).

[Supke]

Oke dat is mooi UDP heeft mijn voorkeur.
Ik kan niet wachten tot morgen dus ben er nu mee bezig het te configureren dus zo even testen.

[boxlessness]

Supke schreef op maandag 12 augustus 2024 @ 23:22:
Oke dat is mooi UDP heeft mijn voorkeur.
Ik kan niet wachten tot morgen dus ben er nu mee bezig het te configureren dus zo even testen.

Of TCP 21/22 (FTP), TCP 23 (telnet), TCP 53 (DNS)...
Gewoon de lijst met bekende protocollen af gaan.. Zit ook vast wat UDP-spul tussen, e.g. IMAP zit op TCP&UDP 220, en POP3 op 995.
Ik begrijp wel niet helemaal waarom de keuze voor UDP heel belangrijk zou zijn. "if it works, who cares"...

[edit]
Valt me nu pas op dat HTTP3 op UDP 80 draait. Dus als je gewone webserver gewone HTTP doet op TCP 80, kun je je VPN op UDP 80 zetten.

[ Voor 10% gewijzigd door boxlessness op 13-08-2024 00:01 ]

[Supke]

@boxlessness
Bedankt die lijst had ik vanmiddag ook bekeken zo kwam ik erop om die LDAP en LDAPS poorten te testen.
Ik heb een sterk vermoeden dat die poorten allemaal niet gaan werken.
En het is nogal een werkje steeds de poorten te veranderen.
Ik moet een keuze maken zodat ik alle clients ook kan aanpassen.

@m.eddy
Ik heb ondertussen ook 81820 udp getest maar die is bij mij heel erg traag of eigenlijk komt er nauwelijks data door de tunnel.
Ik heb nu weer poort 443 tcp ingesteld dat is een giga verschil.

Ik denk dat ik het zo ga houden en morgen alle andere clients ga aanpassen.

[Thralas]

Supke schreef op maandag 12 augustus 2024 @ 22:02:
Mij lijkt dat dit helemaal niet mag dus misschien wel bij het EC bij de juiste persoon onder de aandacht brengen.

Je probleem heeft niets met shaping of 'afknijpen' van verkeer te maken, die suggestie komt hier meermaals voorbij - maar zoals je zelf al stelt: dat mag niet in de EU, dus dat gebeurt ook niet behoudens bv. overijverige anti-ddosmaatregelen.

Je probleem heeft wel alle schijn van een probleem met je mtu. De mtu van mobiele verbindingen is namelijk vaak geen 1500 maar (veel) lager vanwege allerlei netwerkoverhead.

Een VPN als OpenVPN probeert er op meerdere manieren voor te zorgen dat dit geen probleem oplevert: allereerst door de (tunnel) mtu te berekenen, vervolgens door ook nog de mss van tcp-verbindingen te clampen zodat er niet hoeft te worden gefragmenteerd. Meestal werkt dat. Soms niet: dit is zo'n voorbeeld.

En als het niet werkt? Dan worden je pakketjes af-en-toe te groot en verdwijnt er verkeer op weg naar je VPN (of andersom). Vanwege tcp retransmits/congestion control in je tunnel druppelt er soms nog mondjesmaat verkeer binnen: dat is exact wat je ervaart.

De reden waarom het pas optreedt als je roamt is omdat de mtu van je mobiele verbinding (blijkbaar) afwijkt in die situatie. Ik ben er in ieder geval zelf ook wel eens tegen aangelopen tijdens roamen (in België, zelfs - maar met KPN ipv. Vodafone).

Weet je toevallig of udp of tcp nog verschil uitmaakt?

Ja, dat maakt zeker verschil uit en is vermoedelijk de crux van je 'fix'. Maar vooral omdat ofwel OpenVPN zich anders gedraagt, ofwel omdat je mobiele provider zelf aan mss clamping doet en daarmee je probleem voor je oplost.

Waarschijnlijk zul je ook ontdekken dat 1194/tcp net zo goed werkt en 51820/udp even slecht.

De werkelijke fix is om de mtu van je OpenVPN tun interface te corrigeren. Je kunt iets als tun-mtu 1300 in je config zetten. Dan werkt het ook weer over UDP.

---

Bonus

Als je benieuwd bent waar het verschil nu vandaan komt: installeer PingTools op je telefoon, kies de ping utility en verander de settings (knopje rechtsboven: wijzig 'Do not set DF flag (dont)' naar 'Prohibit fragmentation' en zet packetsize op 1500). Zet ook je WiFi en de VPN uit, anders test je de verkeerde verbinding.

Probeer dan te pingen naar 1.1.1.1. Je krijgt dan een foutmelding die je de MTU van je interface vertelt. Bij KPN heb ik slechts 1432.

Trek nu 28 af van de interface MTU (hier: 1432-28=1404) en vul dat in als packetsize en probeer het nog eens. Als het goed is krijg je dan wel een ping response. Herhaal bovenstaande nog eens als je aan het roamen bent.

Of je interface mtu is anders als je aan het roamen bent

Of je interface mtu is ongewijzigd als je roamt maar in die situatie krijg je een timeout. Verklein dan de packetsize tot het wel werkt.

Ik vermoed dat het eerste aan de hand is en OpenVPN wellicht geen rekening houdt met een wijzigende interface mtu. In het tweede geval zou ik je telecomprovider (of de roaming provider) de schuld geven.

[Supke]

Bedankt ik zal er morgen eens mee gaan rommelen.
Opvallend is wel dat geen enkele poort udp of tcp niet werken alleen poort 443 tcp werkt wel.
En dat is niet een beetje verschil maar een verschil van nul data over tunnel naar een prima snelle verbinding over de tunnel.
En dat is niet soms toevallig maar bij elke test hetzelfde resultaat alleen 443 TCP werkt en de rest niet.

[Supke]

@thr

Ik heb ondertussen de standaard OpenVPN poort 1194 ingesteld maar nu met TCP zoals jij voorstelde.
Ook heb ik
tun-mtu 1300; mssfix 1250;
ingesteld bij zowel server als client.
De waardes zijn een wilde gok nog niet echt ping metingen gedaan.

Dit lijkt inderdaad ook te werken.
Ik lig nu in bed en mijn verbinding met proximus is momenteel heel slecht ik haal toch al 12mbps down.

Ik blijf het toch apart vinden dat poort 443 tcp zo veel beter werkt meteen zonder enige mtu instellingen.

[stef243]

Als je echt gebruik moet blijven maken van een https poort zou je ook nog 8443 TCP kunnen proberen. Dit is een alternatieve poort voor https.

[Supke]

@stef243
Die poort zou ik kunnen proberen idd maar zo ook 8080 en nog veel andere poorten die ik kan proberen maar het is steeds nogal wat werk het om te zetten het testen tussen verschillende mobiele providers enz maar het lijkt erop dat het verhaal van @Thralas lijkt te werken. IK heb nu de standaard OpenVPN poort 1194 met TCP in gebruik en heb o.a. de MTU op 1300 gezet en haal nu iets van 12 mbps bij de laatste test vannacht. Daarmee heb ik redelijk goede VPN verbinding met Proximus. Ik wacht nog even met andere poorten te testen tot ik weer in belgie ben dan is de verbinding met proximus beter dan hier vanaf mijn thuis locatie en als die dan nog beter is dan laat ik het voorlopig even zo dan is mijn doel bereikt.

Dat OpenVPN Port Sharing met poort 443 TCP is een leuke oplossing maar nadeeltje is als mensen op mijn websites komen dat ik dan in de log niet meer hun IP adressen zie maar telkens het IP adres van mijn router als source dat vind ik toch een beetje jammer ik vind het juist leuk te zien wie er op mijn websites komen en vooral als ze dingen willen proberen die niet de bedoeling zijn 😊

[Paul C]

boxlessness schreef op maandag 12 augustus 2024 @ 23:53:
[...]
Ik begrijp wel niet helemaal waarom de keuze voor UDP heel belangrijk zou zijn. "if it works, who cares"...
[...]

Stelregel bij netwerkverkeer is: gebruik TCP tenzij je een goede reden hebt om iets anders te doen. VPN is zo'n uitzondering. Als je TCP over TCP gaat tunnelen krijg je twee lagen met transmission control. Dan kun je TCP Meltdown krijgen.

TL;DR:
De twee lagen TCP gaan allebei compenseren en overcompenseren daardoor en werken elkaar tegen. Je verbinding wordt veel trager en onregelmatiger dan nodig.