Nieuwe modem: Wel OpenVPN-verbinding, geen/trage connectie

[Howmessages]

Mijn broer en ik hebben beide een Synology NAS waarop we OpenVPN ingesteld hebben. Dit heeft lange tijd goed gewerkt: ik kon met mijn clients verbinden met zijn NAS en hij kon met zijn clients verbinden met mijn NAS. Onderstaand de situatie zoals deze was. Eerst als mijn broer een verbinding wilde maken met mijn NAS en daarna als ik een verbinding wilde maken met zijn NAS.



Nu hebben we zijn TP-Link Archer MR200 LTE-modem vervangen voor een Teltonika RUT240 omdat de MR200 nogal wat kuren vertoonde en binnen moest staan, wat ten koste ging van de snelheid/kwaliteit van internet. Sindsdien ervaren we een probleem:



Ik kan met mijn clients nog wel op een normale manier verbinding maken met zijn NAS maar andersom gaat er iets mis. Hij kan met zijn clients nog wel de OpenVPN-verbinding maken met mijn NAS en dit verloopt snel, maar daarna kan hij niet tot nauwelijks gebruik maken van internet. Het openen van webpagina's gaat bijvoorbeeld zeer traag of krijgt een time-out, maar een ping naar bijvoorbeeld 1.1.1.1 of google.nl werkt zoals verwacht.

Ik begrijp niet waar dit door kan komen. Ik zit te denken aan de firewall in de nieuwe modem of iets dergelijks, maar dan nog begrijp ik niet waarom het tot stand brengen van de OpenVPN-verbinding wel lukt maar het laden van websites/diensten daarna tergend langzaam is terwijl pingen wel werkt. En heeft een firewall überhaupt nog invloed op het verkeer als de OpenVPN-verbinding al tot stand is gekomen? Ik zou verwachten van niet.

We hebben ook geprobeerd direct verbinding te maken met de Teltonika RUT240 maar dan blijft het probleem. Als de Teltonika RUT240 wordt omzeild, bijvoorbeeld door clients direct met LTE te verbinden, dan werkt het wel. Het is dus vrij duidelijk dat het probleem in de Teltonika RUT240 zit.

[Howmessages]

Iemand een idee wat dit probleem kan veroorzaken of in welke hoek ik moet zoeken?

[Thralas]

Howmessages schreef op woensdag 7 december 2022 @ 14:12:
Ik zit te denken aan de firewall in de nieuwe modem of iets dergelijks, maar dan nog begrijp ik niet waarom het tot stand brengen van de OpenVPN-verbinding wel lukt maar het laden van websites/diensten daarna tergend langzaam is terwijl pingen wel werkt.

Controleer eens de (effectieve) mtu van je verbindingen (beide zijden), zowel over de VPN als zonder. Dat kun je doen door te pingen naar 1.1.1.1 of een machine aan de andere kant van de VPN (Windows: ping /f /l 1472 1.1.1.1). De size (1472) verlagen tot je wel een antwoord krijgt.

Zonder VPN zou de mtu 1472 moeten zijn, via OpenVPN minder, maar wel ~28 lager dan die van de OpenVPN interface (netsh interface ipv4 show subinterfaces).

En: hoe ziet je OpenVPN-configuratie eruit?

En #2: waarom probeer je uberhaupt het internet te benaderen via de OpenVPN? Is het niet logischer om de VPN alleen voor de NAS/het andere netwerk te gebruiken?

[Voor 8% gewijzigd door Thralas op 08-12-2022 19:43]

[Ben(V)]

Split tunnel aanzetten op de client van je broer.
Dan gaat het verkeer naar het internet niet via de Vpn en jouw Nas.

En je kunt ook die nutteloze Rut240's ertussenuit halen.

[Howmessages]

Thralas schreef op donderdag 8 december 2022 @ 19:42:
[...]


Controleer eens de (effectieve) mtu van je verbindingen (beide zijden), zowel over de VPN als zonder. Dat kun je doen door te pingen naar 1.1.1.1 of een machine aan de andere kant van de VPN (Windows: ping /f /l 1472 1.1.1.1). De size (1472) verlagen tot je wel een antwoord krijgt.

Zonder VPN zou de mtu 1472 moeten zijn, via OpenVPN minder, maar wel ~28 lager dan die van de OpenVPN interface (netsh interface ipv4 show subinterfaces).

Als ik dit doe dan krijg ik pas antwoord bij een MTU van 1352 en als ik de VPN aanzet een MTU van 1299. Een ifconfig in de Teltonika gaf de volgende waarde terug bij wwan0:

code:

UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1380  Metric:1

In eerste instantie heb ik de MTU-waarde van OpenVPN op mijn NAS aangepast van de standaard 1450 naar 1352 en toen deed alles het weer. Maar volgens mij is een MTU van 1500 sowieso wel gewenst voor hun verbinding. In het verleden heb ik hier ook eens mee te maken gehad waarbij Netflix op een Apple TV 3 niet werkte omdat het een MTU-waarde van 1500 nodig had en de LTE-modem toen geen MTU-waarde hoger dan 1499 kon instellen.

Dus heb ik de MTU-waarde in de Teltonika MOB1S1A1 interface aangepast naar 1500 en weer ifconfig gedaan. Dan krijg ik wel een MTU-waarde van 1500 terug. Alleen dan krijg ik het probleem dat de VPN-verbinding van mijn client naar de DS120j NAS van mijn broer niet meer goed werkt en ik begrijp niet waarom. Als ik de MTU-waarde dan in de DS120j aanpas naar 1352, dan werkt het wel weer. Maar ik begrijp totaal niet waarom? Zou jij of iemand anders mij kunnen uitleggen waarom het zo is dat als de MTU-waarde op hun Teltonika modem wordt verhoogd, de VPN-verbinding naar de server bij mijn broer ineens niet meer werkt terwijl deze voorheen de standaard MTU-waarde van 1450 had? Hopelijk is het een beetje duidelijk, anders wil ik het wel weer even uittekenen.

En #2: waarom probeer je uberhaupt het internet te benaderen via de OpenVPN? Is het niet logischer om de VPN alleen voor de NAS/het andere netwerk te gebruiken?

De VPN-verbinding is er niet perse om het interne netwerk te benaderen maar om geoblocking te omzeilen. Mijn broer woont in het VK waardoor een heleboel Nederlandse content geblokkeerd wordt. De andere kant op, mijn clients naar de NAS aan van mijn broer, is wel vooral om op hun netwerk bezig te zijn. Ik gebruik het bijvoorbeeld om de webinterface van de Teltonika te gebruiken.

[Thralas]

Howmessages schreef op zaterdag 14 januari 2023 @ 14:28:Hopelijk is het een beetje duidelijk, anders wil ik het wel weer even uittekenen.

Het feit dat het over 2 OpenVPN servers tegelijk gaat maakt dat ik het niet helemaal kan doorgronden. En iets dat er niet impliciet staat maar wat er wel aan de hand lijkt: klopt het dat je broer geen vast internet heeft en daarom een LTE modem gebruikt?

Zou jij of iemand anders mij kunnen uitleggen waarom het zo is dat als de MTU-waarde op hun Teltonika modem wordt verhoogd, de VPN-verbinding naar de server bij mijn broer ineens niet meer werkt terwijl deze voorheen de standaard MTU-waarde van 1450 had?

Wat er denk ik misgaat bij het verhogen van de MTU is dat dat niets verandert aan het feit dat het mobiele netwerk (blijkbaar) een maximale MTU van 1380 ondersteunt. Tenminste, ik veronderstel dat de interface MTU niet uit de lucht is komen vallen. Je zou dat nog kunnen controleren door de pingtest te herhalen (liefst op het modem zelf) nadat je de MTU van MOB1S1A1 naar 1500 hebt gezet.

Die 1380 is dan de zwakste schakel in het hele pad en iets waar je rekening mee zult moeten houden bij het configureren van de VPNs. De effectieve payload voor OpenVPN is hetzelfde als bij de ping-test: 1380 - 20 (ip) - 8 (udp of icmp) = 1352.

Als je dit in je OpenVPN configs zet zou 't allemaal moeten werken:

code:

fragment 1352
mssfix

tcp zal dan gelimiteerd worden op mss, udp zal worden gefragmenteerd

[Howmessages]

Dank voor je reactie!

Thralas schreef op zondag 15 januari 2023 @ 15:41:
[...]


Het feit dat het over 2 OpenVPN servers tegelijk gaat maakt dat ik het niet helemaal kan doorgronden.

Ik heb het nog eens uitgetekend. De eerste was de situatie zoals voorheen, waarbij de MTU-size van de Teltonika dus 1380 was. Daarbij kon mijn broer met zijn clients geen verbinding maken met mijn Synology DS118 NAS VPN-server.



Na het aanpassen van de MTU-size op de Teltonika gaat het de andere kant op niet goed. Mijn clients kunnen geen verbinding meer maken met de DS120j VPN-server van mijn broer zoals onderstaand:



Het enige wat daarbij is aangepast is de MTU-size op de Teltonika van 1380 naar 1500. De MTU-size op beide VPN-servers is op dat moment 1450, de standaard waarde van OpenVPN.

En iets dat er niet impliciet staat maar wat er wel aan de hand lijkt: klopt het dat je broer geen vast internet heeft en daarom een LTE modem gebruikt?

Inderdaad iets wat ik had moeten verduidelijken: ja, hij kan enkel internet ontvangen over LTE. Niet geweldig maar een andere mogelijkheid is er op het platteland momenteel niet voor hem. Er is een klein sprankje hoop dat er komende jaren glasvezel gaat komen maar op korte termijn zal dat niet zijn.

Wat er denk ik misgaat bij het verhogen van de MTU is dat dat niets verandert aan het feit dat het mobiele netwerk (blijkbaar) een maximale MTU van 1380 ondersteunt. Tenminste, ik veronderstel dat de interface MTU niet uit de lucht is komen vallen. Je zou dat nog kunnen controleren door de pingtest te herhalen (liefst op het modem zelf) nadat je de MTU van MOB1S1A1 naar 1500 hebt gezet.

Die 1380 is dan de zwakste schakel in het hele pad en iets waar je rekening mee zult moeten houden bij het configureren van de VPNs. De effectieve payload voor OpenVPN is hetzelfde als bij de ping-test: 1380 - 20 (ip) - 8 (udp of icmp) = 1352.

De MTU van MOB1S1A1 heb ik op 1500 kunnen zetten en daarna kon ik vanaf de modem pingen met een MTU van 1472. Volgens mij werkt het dan ( 1472 + 20 IP + 8 ICMP headers = 1500) en is de Teltonika niet meer de bottleneck.

Ik begrijp alleen niet waarom, op het moment dat ik die MTU wijzigde naar 1500, ik vervolgens met mijn clients geen stabiele verbinding meer kon maken met de VPN-server op de DS120j van mijn broer. Opeens had ik de problemen die mijn broer eerst ervaarde. Dat terwijl het met een MTU-waarde van 1380 in de Teltonika en de mssfix op de DS120j VPN-server op 1450 eerder wel werkte. Dat kan ik niet plaatsen.

Ik kan dan ook pas pingen met een MTU-waarde van 1299 op mijn clients, anders krijg ik de melding 'Request timeout for icmp_seq 0'. Dat is niet anders als ik de mssfix op de DS120j VPN-server op 1352 zet.

Als je dit in je OpenVPN configs zet zou 't allemaal moeten werken:

code:

fragment 1352
mssfix

tcp zal dan gelimiteerd worden op mss, udp zal worden gefragmenteerd

Mssfix van 1352 op beide servers zorgt in ieder geval niet voor problemen aan beide kantenm, dus die waarde houd ik nu maar aan. Toch blijf ik benieuwd waarom het aanpassen van de MTU-waarde op de Teltonika ineens problemen gaf aan mijn kant. Dat is nog wel interessant om te achterhalen, dan pas denk ik dat ik de werking van de MTU-waarde een beetje ga begrijpen.

[Thralas]

Howmessages schreef op maandag 16 januari 2023 @ 21:41:
Ik kan dan ook pas pingen met een MTU-waarde van 1299 op mijn clients, anders krijg ik de melding 'Request timeout for icmp_seq 0'. Dat is niet anders als ik de mssfix op de DS120j VPN-server op 1352 zet.

1. mssfix 1352 of fragment 1352? mssfix doet namelijk helemaal niets voor icmp
2. heb je 't ook op de client gezet? zal primair moeten gebeuren op de kant die een verbinding opzet, dus de client, en bij inkomend verkeer ook op de andere kant (dus server)

Mssfix van 1352 op beide servers zorgt in ieder geval niet voor problemen aan beide kantenm, dus die waarde houd ik nu maar aan.

Met andere woorden: het werkt (en dan veronderstel ik: met fragment en mssfix)?

Toch blijf ik benieuwd waarom het aanpassen van de MTU-waarde op de Teltonika ineens problemen gaf aan mijn kant. Dat is nog wel interessant om te achterhalen, dan pas denk ik dat ik de werking van de MTU-waarde een beetje ga begrijpen.

Zonder daar al te lang over te filosoferen: als de enige non-1500 MTU link in het pad die Teltonika is/was, dan kan het niet anders dan die toch de problemen veroorzaakt.

Je zegt dat je met ping size 1500 kan pingen, maar heb je dat met de juiste flags gedaan? Onder Linux moet je '-M do' meegeven om de DF flag te zetten, anders zegt de test niets. Kan zijn dat je eerst de niet-busyboxversie van ping moet installeren.

Het lijkt me namelijk nog steeds sterk dat die MTU 1380 willekeurig wordt gekozen.

Bonus: welke mobiele provider betreft het?

MR2100 - Need to Manually set MTU (due to PMTUD failure)

Hier claimt iemand namelijk (geheel ontoevallig?) dat de MTU van 4G van Three/EE 1380 is.

[Howmessages]

Thralas schreef op dinsdag 17 januari 2023 @ 00:24:
[...]

1. mssfix 1352 of fragment 1352? mssfix doet namelijk helemaal niets voor icmp
2. heb je 't ook op de client gezet? zal primair moeten gebeuren op de kant die een verbinding opzet, dus de client, en bij inkomend verkeer ook op de andere kant (dus server)

1. Mssfix 1352. De OpenVPN configuratie op Synology heeft geen optie voor fragment. Misschien wel als ik het via de CLI doe maar daar heb ik nog niet naar gekeken.
2. Bedoel je dan misschien dat ik het in het *.ovpn bestand moet zetten? In de clients zelf is daar geen configuratie voor.

[...]


Met andere woorden: het werkt (en dan veronderstel ik: met fragment en mssfix)?

Klopt, spelen met de MTU-waardes heeft ervoor gezorgd dat het weer werkt. Maar ik wil graag achterhalen wat er nou precies fout ging zodat ik in de toekomst ook kan voorkomen dat het weer fout gaat en ik ook beter begrijp wat die MTU-waarde inhoudt. Ik heb zo'n idee dat ik MTU nu redelijk begrijp, maar het lukt mij nog niet om te plaatsen in de problemen.

Zonder daar al te lang over te filosoferen: als de enige non-1500 MTU link in het pad die Teltonika is/was, dan kan het niet anders dan die toch de problemen veroorzaakt.

Dat was in eerste instantie ook mijn gedachte, totdat het dus vanaf mijn clients naar de DS120j van mijn broer het niet meer werkte na het aanpassen van de MTU-waarde naar 1500 in de Teltonika. Eigenlijk ben ik dus wel benieuwd wat de MTU-waarde van de oude MR200 was waar alles het gewoon deed, want die zal dan denk ik zowel niet 1380 als 1500 zijn geweest.

Dat wil ik nog wel eens testen maar daarvoor moet ik eerst weer eens in Engeland zijn.

Je zegt dat je met ping size 1500 kan pingen, maar heb je dat met de juiste flags gedaan? Onder Linux moet je '-M do' meegeven om de DF flag te zetten, anders zegt de test niets. Kan zijn dat je eerst de niet-busyboxversie van ping moet installeren.

Uit mijn hoofd heb ik op de Teltonika inderdaad eerst iputils-ping moeten installeren en daarna 'ping 1.1.1.1 -c 5 -M do [mtu]' gedaan. Voor de clients heb ik 'ping 1.1.1.1 -f -l [mtu]' (Windows) en 'ping -D -s [mtu] 1.1.1.1' (macOS) gebruikt.

Het lijkt me namelijk nog steeds sterk dat die MTU 1380 willekeurig wordt gekozen.

Bonus: welke mobiele provider betreft het?

MR2100 - Need to Manually set MTU (due to PMTUD failure)

Hier claimt iemand namelijk (geheel ontoevallig?) dat de MTU van 4G van Three/EE 1380 is.

Het gaat inderdaad om Three. Weet jij misschien hoe die MTU-waarde wordt bepaald? Is het de zendmast die deze waarde met de modem afstemt? Is het mogelijk een advieswaarde van de zendmast die de Teltonika wel overnam maar de MR200 niet? Ik lees bijvoorbeeld elders ook weer dat de Huawei B311(die Three normaal uitlevert maar niet heel goed is) standaard een MTU-waarde van 1500 heeft en ook direct de APN '3internet' gebruikt in plaats van 'three.co.uk'. Op zowel de MR200 als Teltonika moesten we zelf 3internet als APN instellen omdat anders port forwarding niet mogelijk is (APN three.co.uk is GCNAT).

Kan de MTU-waarde van 1500 kwaad als Three 1380 hanteert? Mijn eerste gedachte is dat Three ook MTU 1500 ondersteunt omdat anders pakketten gedropt worden en mijn broer momenteel geen problemen met internet ervaart.

Ik vind die MTU-waarde best fascinerend en ben heel erg blij met jouw reacties, nogmaals super bedankt daarvoor.