Externe overdracht grote bestanden(>1MB) naar DS220+ mislukt

[dvtxc]

Ongeveer een week geleden heb ik een Synology DS220+ in gebruik genomen. De NAS is extern te bereiken via een DDNS server en een OpenVPN server die op de NAS draait. De NAS hangt met een statisch lokaal ip-adres aan een FRITZ!Box 7490, waarop poort 1194 is doorgeschakeld naar de NAS (en tijdelijk ook poort 5001 zodat ik er nu op afstand even mee kan rommelen). Poorten in de Synology Firewall zijn geopend voor lokale verbindingen vanuit 10.x.x.x

Deze verbinding werkt prima voor het downloaden van bestanden van de NAS (gaat met de maximale uploadsnelheid van mijn internetverbinding waar de NAS aan hangt), maar ik krijg vanuit mijn ouderlijk huis niets groter dan een paar MB naar de NAS geschreven.

• Upload via DSM-interface (via poortnummer 5001) blijft steken op ongeveer 10 kB/s. Vaak mislukt de overdracht na iets van 2 MB.
• Ik kan me via OpenVPN (via poortnummer 1194) verbinden. De mounts zijn allemaal via een lokaal ip-adres te zien. Maar zodra ik bestanden naar de NAS kopieer, wordt de overdracht na 2 minuten afgebroken met de volgende foutcode: Unknown Network Error: 0x8007003B
• Uploads via mijn eigen mobiele dataverbinding gaan wel vlot. Daarom heb ik het vermoeden dat het aan Windows of aan de router in mijn ouderlijk huis ligt. (Is een ASUS RT N66U, laatste ASUS firmware. Hangt achter een glasvezelmodem.)

Ik heb het volgende geprobeerd:

• Firewall op mijn Windows PC uitschakelen.
• Firewall op mijn Synology NAS uitschakelen.
• Tijdelijk alle poorten op mijn router naar de NAS openzetten.
• DSM update, NAS herstarten
• Upload test via speedtest: zou geen probleem moeten opleveren, ik haal een constante 50 Mbit/s
• Ping test vanuit het thuisnetwerk naar mijn NAS: 20% packet loss. Hetzelfde geldt voor ping tests vanuit de router firmware. Router en glasvezelmodem herstarten hebben niets opgeleverd.
• Met een vaste LAN-verbinding hetzelfde geprobeerd. Het ligt dus niet aan de WLAN instellingen.

[ Voor 7% gewijzigd door dvtxc op 29-12-2020 17:06 ]

[LanTao]

dvtxc schreef op dinsdag 29 december 2020 @ 17:02:
Upload via DSM-interface (via poortnummer 5001) blijft steken op ongeveer 10 kB/s. Vaak mislukt de overdracht na iets van 2 MB.

Dit klinkt als een MTU-probleem waarbij de zender te grote packets stuurt die niet gefragmenteerd kunnen worden. Misschien moet je de tunnel-MTU verkleinen.

[Ben(V)]

Klinkt alsof je een lan protocol gebruikt om iets over het internet te kopieren.
Gebruikt je soms gewoon smb?
Dat werkt niet zo best over het internet, die krijgt last van timeouts.

En packets wordt altijd gefragmenteerd dat zit gewoon in het tcp protocol ingebakken, daar hoef je zelf de mtu niet voor aan te passen, al is een mtu groter dan standaard zetten altijd een matig idee.

[Thralas]

LanTao schreef op woensdag 30 december 2020 @ 03:58:
Dit klinkt als een MTU-probleem waarbij de zender te grote packets stuurt die niet gefragmenteerd kunnen worden.

Inderdaad. Je kunt ook relatief simpel vaststellen of dit het probleem is door wat pings te versturen:

ping /n 1 /f /l 1472 1.1.1.1

En herhalen met het publieke IP van de andere zijde (als ICMP niet gefilterd wordt). Als dat vanaf één van beide kanten geen response oplevert dan heb je blijkbaar een MTU-probleem. Lengte (1472) verkleinen tot het wel werkt.

Misschien moet je de tunnel-MTU verkleinen.

Of bij voorkeur de MTU op tussenliggende links corrigeren. Merkwaardig is dat de test met de webinterface zelfs problematisch is. Dat zou gewoon moeten werken als beide routers 1500 MTU hanteren.

dvtxc schreef op dinsdag 29 december 2020 @ 17:02:
of aan de router in mijn ouderlijk huis ligt. (Is een ASUS RT N66U, laatste ASUS firmware. Hangt achter een glasvezelmodem.)[/li]

Welke ISP? Is er sprake van PPPoE? Zoja, welk apparaat zet de PPPoE-verbinding op en gebruikt deze een MTU/MRRU van 1500?

Bij KPN (en alles wat KPN doorverkoopt) kun je de MTU voor PPPoE op 1500 zetten ipv. (de default) 1492, dat voorkomt dit soort problemen.

li]Ping test vanuit het thuisnetwerk naar mijn NAS: 20% packet loss. Hetzelfde geldt voor ping tests vanuit de router firmware. Router en glasvezelmodem herstarten hebben niets opgeleverd.[/li]

Wat bedoel je hier met thuisnetwerk? Een ping via de VPN-verbinding? Dan is 20% packet loss het probleem als de MTU verder klopt. Als dat niet optreedt over een mobiele verbinding: controleren waar de packet loss optreedt en of er misschien iets van een firewall op de N66U is die vervelend doet.

[Frogmen]

over een VPN verbinding is ftp of ssh vaak een stuk sneller en stabieler. Let op niet ftp vanaf het internet open zetten want dat is niet zo veilig. Mogelijk zit het probleem in je upload vanaf je thuis adres, is die verbinding traag?

[lier]

Persoonlijk zou ik eerst beginnen met dat het binnenshuis goed werkt. 20% Packet loss zegt mij dat er iets goed mis is...kan een slechte kabel zijn. Zodra dat goed werkt kan je je focussen op bestandsoverdracht via VPN (zorg wederom dat je het eerst lokaal goed hebt werken).

[dvtxc]

Thralas schreef op woensdag 30 december 2020 @ 08:37:
Inderdaad. Je kunt ook relatief simpel vaststellen of dit het probleem is door wat pings te versturen:

Bedankt voor de vele tips. Ik denk dat ik hier wat hulp nodig heb, want ik hoor nu voor het eerst van MTU. (Netwerken zijn niet mijn ding )

Via SSH vanaf mijn NAS krijg ik het volgende:

Ping van NAS naar 1.1.1.1:

ping -c 1 -M do -s 1472 1.1.1.1

Antwoord:

PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
ping: local error: Message too long, mtu=1492

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Het lukt vanaf -s 1464 (met header (?) 1492).

Ping van NAS naar mijn publieke IP-adres:

ping -c 5 -M do -s 1464 83.xxx.xxx.xxx

Antwoord:

PING 83.xxx.xxx.xxx (83.xxx.xxx.xxx) 1464(1492) bytes of data.

--- 83.xxx.xxx.xxx ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

Ping van mijn Windows PC naar 1.1.1.1

ping /n 1 /f /l 1472 1.1.1.1

Antwoord:

Pinging 1.1.1.1 with 1472 bytes of data:
Reply from 1.1.1.1: bytes=1472 time=3ms TTL=60

Ping statistics for 1.1.1.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 3ms, Average = 3ms

Ping van mijn Windows PC naar het publike IP-adres van mijn NAS

ping /n 1 /f /l 1472 84.xxx.xxx.xxx

Antwoord:

Pinging 84.xxx.xxx.xxx with 1472 bytes of data:
Reply from 91.xxx.xxx.xxx: Packet needs to be fragmented but DF set.

Ping statistics for 84.xxx.xxx.xxx:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

Het pakketverlies is verholpen als ik de grootte terugbreng tot /l 1464.

Als dit een MTU probleem is, waar moet ik de MTU corrigeren? Ik heb ontdekt dat het niet mogelijk is om de MTU op de router waaraan mijn NAS hangt, aan te passen:

Met de FRITZ!Box kan de MTU-grootte niet handmatig worden aangepast. Dit is ook niet nodig, omdat de FRITZ!Box ondersteuning biedt voor MSS clamping (Maximum Segment Size) waardoor automatisch de grootte van de gegevenspakketten wordt aangepast aan de kleinere MTU van de onderling verbonden netwerken.

Thralas schreef op woensdag 30 december 2020 @ 08:37:
Welke ISP? Is er sprake van PPPoE? Zoja, welk apparaat zet de PPPoE-verbinding op en gebruikt deze een MTU/MRRU van 1500?

Bij KPN (en alles wat KPN doorverkoopt) kun je de MTU voor PPPoE op 1500 zetten ipv. (de default) 1492, dat voorkomt dit soort problemen.

Hier heb ik nu een FTTH verbinding van Caiway. Uit dit Tweakblog kan ik opmaken dat Caiway DHCP gebruikt.

Ik weet niet welk protocol de ISP (Deutsche Telekom) waaraan mijn NAS hangt, gebruikt. Het is een VDSL2 verbinding en het ziet er naar uit dat daar de MTU 1492 is.

Thralas schreef op woensdag 30 december 2020 @ 08:37:
Wat bedoel je hier met thuisnetwerk? Een ping via de VPN-verbinding? Dan is 20% packet loss het probleem als de MTU verder klopt. Als dat niet optreedt over een mobiele verbinding: controleren waar de packet loss optreedt en of er misschien iets van een firewall op de N66U is die vervelend doet.

Ik bedoelde vanaf mijn eigen Windows PC. Ik heb toen ontdekt dat ik ook een ping test kan uitvoeren vanuit de firmware van mijn router en die test gaf echter hetzelfde resultaat.

Hoe kan ik controleren waar de packet loss precies optreedt? Ik heb al geprobeerd de firewall van de N66U uit te schakelen. Het heeft helaas niets opgeleverd.

Frogmen schreef op woensdag 30 december 2020 @ 11:18:
over een VPN verbinding is ftp of ssh vaak een stuk sneller en stabieler. Let op niet ftp vanaf het internet open zetten want dat is niet zo veilig. Mogelijk zit het probleem in je upload vanaf je thuis adres, is die verbinding traag?

Een Speedtest toont aan dat mijn uploadsnelheid in orde is. Als ik bittorrent uitprobeer kan ik de geadverteerde uploadsnelheid van de ISP van Caiway ook volledig benutten.

De uploadsnelheid van de ISP waaraan mijn NAS hangt is inderdaad iets lager, maar nog steeds stabiel boven de 10 Mbit/s. En juist dat zou bij het uploaden naar de NAS toch niet moeten uitmaken?

---

Edit:

De MTU lijkt inderdaad een rol te spelen. Ik heb het volgende aan het ovpn-configuratiebestand toegevoegd:

code:

mssfix 1420

En nu gaat de bestandsoverdracht (SMB via OVPN) met ongveer 200 kb/s. Nog niet denderend, maar al meer dan 10 kb/s. Het log van OpenVPN zegt echter nog steeds:

code:

Wed Dec 30 14:49:11 2020 IPv4 MTU set to 1500 on interface 11 using service

Wat moet ik aanpassen om altijd met de juiste MTU waarde met mijn NAS te communiceren? Op de een of andere manier gaat dat dus bij een mobiele dataverbinding altijd goed. Via mijn mobiele dataverbinding kan ik in DSM met iets van 20 Mb/s bestanden uploaden.

[ Voor 7% gewijzigd door dvtxc op 30-12-2020 14:57 ]

[LanTao]

Ben(V) schreef op woensdag 30 december 2020 @ 07:40:
Klinkt alsof je een lan protocol gebruikt om iets over het internet te kopieren.
Gebruikt je soms gewoon smb?
Dat werkt niet zo best over het internet, die krijgt last van timeouts.

Huh? Het is gewoon een protocol over TCP, waarom zou dat meer timeouts krijgen dan bijvoorbeeld HTTP?

Het probleem van SMB(v2) is dat het op protocolniveau pas het volgende block verstuurt zodra het vorige acknowledged is, en niet eerder. Er kunnen dus geen packets 'in flight' zijn, wat TCP zelf wel kan. Hierdoor wordt je totale doorvoer sterk beperkt door enige latency onderweg. Op een LAN - waarvoor SMB dertig jaar geleden ontwikkeld is - is dit niet zo'n probleem, maar over het Internet wel. Dit is overigens verholpen in SMBv3.

En packets wordt altijd gefragmenteerd dat zit gewoon in het tcp protocol ingebakken, daar hoef je zelf de mtu niet voor aan te passen, al is een mtu groter dan standaard zetten altijd een matig idee.

De MTU groter dan standaard zetten is een matig idee juist omdat fragmentatie in de praktijk gewoon niet zo vaak werkt op het Internet.

[Thralas]

dvtxc schreef op woensdag 30 december 2020 @ 14:26:
Als dit een MTU probleem is, waar moet ik de MTU corrigeren? Ik heb ontdekt dat het niet mogelijk is om de MTU op de router waaraan mijn NAS hangt, aan te passen:

Met de FRITZ!Box kan de MTU-grootte niet handmatig worden aangepast. Dit is ook niet nodig, omdat de FRITZ!Box ondersteuning biedt voor MSS clamping (Maximum Segment Size) waardoor automatisch de grootte van de gegevenspakketten wordt aangepast aan de kleinere MTU van de onderling verbonden netwerken.

Dat is een flinke drogreden die ze daar gebruiken - MSS clamping werkt alleen voor TCP, met UDP heb je nog steeds een probleem. En blijkbaar werkt het ook voor TCP niet vlekkeloos, want anders had je dit probleem niet (in het webinterface-geforward-scenario).

Jammer dat zo'n 'veelgebruikt' product blijkbaar RFC4638 (MTU 1500 voor PPPoE) niet ondersteunt.

Hier heb ik nu een FTTH verbinding van Caiway. Uit dit Tweakblog kan ik opmaken dat Caiway DHCP gebruikt.

Als er geen sprake is van PPPoE dan kun je veronderstellen dat de MTU aan die kant gewoon 1500 is.

Ik weet niet welk protocol de ISP (Deutsche Telekom) waaraan mijn NAS hangt, gebruikt. Het is een VDSL2 verbinding en het ziet er naar uit dat daar de MTU 1492 is.

Dat zal PPPoATM zijn ivm. VDSL, en dan houdt het op. RFC4638 is alleen van toepassing op PPPoE. Je zit dus vast aan MTU 1492.

Hoe kan ik controleren waar de packet loss precies optreedt? Ik heb al geprobeerd de firewall van de N66U uit te schakelen. Het heeft helaas niets opgeleverd.

Daar kun je het beste iets als mtr voor gebruiken - een traceroute, maar dan continu. Dan zie je zo waar de packetloss optreedt.

De uploadsnelheid van de ISP waaraan mijn NAS hangt is inderdaad iets lager, maar nog steeds stabiel boven de 10 Mbit/s. En juist dat zou bij het uploaden naar de NAS toch niet moeten uitmaken?

Nee, dat is het probleem ook niet.

Inmiddels zijn we erachter dat Caiway waarschijnlijk gewoon 1500 doet en je VDSL 1492. Het is dan ook niet vreemd dat het enkel optreedt als je náár de NAS uploadt, dat is immers de kant met de afwijkende MTU.

Wat vreemd is, is dat je NAS blijkbaar op de hoogte is van een afwijkende MTU (heeft de Fritzbox vast geadverteerd via DHCP). De NAS zou daarom bij een verbinding z'n TCP MSS dusdanig moeten adverteren dat het vanzelf goed gaat. En anders belooft de Fritzbox het voor je te doen. Toch gaat dat kennelijk niet goed.

Reden dat het via een mobiele verbinding wel werkt kan zijn omdat je daar mogelijk een nog veel lagere MTU hebt.

Anyhow, je kunt de MTU op je Fritzbox niet wijzigen, je NAS lijkt ook al op de hoogte. Je zou kunnen checken of de interface MTU op de NAS inderdaad 1492 is en met tcpdump controleren wat je daar ziet.

tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0 and tcp port 5001'

In de output van de SYN en SYN/ACK zie je de mss van beide kanten geadverteerd worden. Maar ook dat is blijkbaar geen garantie: SLES TCP - Smaller MSS not honored. De verwachting is dat je een 'mss 1452' response ziet van je NAS - en dan ben je nog geen steek verder, want dat zou moeten werken, maar dat doet het niet.

Aangenomen dat je uiteindelijk OpenVPN wilt gebruiken en het niet uitmaakt als TCP (zonder VPN) niet werkt kun je het ook in je OpenVPN config proberen te verhelpen, dat is waarschijnlijk de meest pragmatische oplossing. Let op: dit werkt voor OpenVPN in UDP mode.

code:

tun-mtu 1500
fragment 1300
mssfix

Voorbeeldje komt rechtstreeks uit de OpenVPN manpage; fragment/mssfix zou je frames moeten limiteren tot 1328 (1300 + 8 udp + 20 IP) en dat moet werken; de relevantie van tun-mtu begrijp ik niet helemaal, maar zo is het voorbeeld..

[ Voor 3% gewijzigd door Thralas op 30-12-2020 16:23 ]

[Ben(V)]

LanTao schreef op woensdag 30 december 2020 @ 16:02:
[...]

Huh? Het is gewoon een protocol over TCP, waarom zou dat meer timeouts krijgen dan bijvoorbeeld HTTP?

Het probleem van SMB(v2) is dat het op protocolniveau pas het volgende block verstuurt zodra het vorige acknowledged is, en niet eerder. Er kunnen dus geen packets 'in flight' zijn, wat TCP zelf wel kan. Hierdoor wordt je totale doorvoer sterk beperkt door enige latency onderweg. Op een LAN - waarvoor SMB dertig jaar geleden ontwikkeld is - is dit niet zo'n probleem, maar over het Internet wel. Dit is overigens verholpen in SMBv3.


[...]

De MTU groter dan standaard zetten is een matig idee juist omdat fragmentatie in de praktijk gewoon niet zo vaak werkt op het Internet.

Beetje vreemd als je eerst vraagt waarom smb over het internet een probleem zou zijn en vervolgens zelf uitlegt wat de reden is.

[LanTao]

Ben(V) schreef op woensdag 30 december 2020 @ 17:21:
[...]

Beetje vreemd als je eerst vraagt waarom smb over het internet een probleem zou zijn en vervolgens zelf uitlegt wat de reden is.

De uitleg ging over waarom het protocol trager kan zijn over grotere afstanden. Timeout = failure. Kun je uitleggen waardoor SMB timeouts zou kunnen krijgen over het Internet over verbindingen die verder wel normaal werken (weinig packet loss, latency binnen het continent)?

[Ben(V)]

Het probleem zit niet is de snelheid van de verbinding maar in de latency.
Wat voor een wan verbinding een prima latency is, is in lan termen een eeuwigheid.

Als een tcp frame corrupt raakt dan wordt dat bij de volgende hop in de verbinding geconstateerd en wordt er een retransmission van dat frame aangevraagd en aan de andere kant worden alle frames (dus ook de out of sync frames) weer samengevoegd.

Smb is block georiënteerd boven op tcp/ip en ontworpen voor lan latencies.
Zo'n block kan wel tot 64K groot zijn.

Met andere woorden smb verzend een block data en gaat dan wachten tot de andere kant bericht stuurt dat het allemaal correct is aangekomen om vervolgens het volgende block te sturen.
Komt dat antwoordt niet tijdig, dan wordt een bericht gestuurd dat het verzonden block niet valid meer is en wordt het block opnieuw verzonden.

Maar voor dat het block opnieuw verzonden wordt, wordt er eerst een block size negotiation op touw gezet om te proberen het probleem op te lossen door bijvoorbeeld kleinere blokken te gebruiken.
Zo tuned smb zichzelf naar de latency van het netwerk.

Dat werkt prima op een lan waar die block size negotiation eigenlijk maar zelden voorkomt, tenzij het netwerk overbelast is.
Op het internet kan de latency echter sterk variëren en daardoor loop je de kans dat de verbinding continue bezig is met block size negotiation.

Dus o.a. twee problemen te grote latency voor een lan protocol en dan ook nog potentieel variërende latency wat het nog erger maak.

En als laatste en niet minder belangrijk, het is natuurlijk een gigantisch security risc om je system voor smb openen te zetten naar het internet toe.
Dat is gewoon vragen om gehacked te worden.

[ Voor 3% gewijzigd door Ben(V) op 30-12-2020 19:59 ]

[dvtxc]

Thralas schreef op woensdag 30 december 2020 @ 16:16:
[...]

Dankjewel voor de uitgebreide uitleg. Je hebt me op weg geholpen en ik heb nu de overdrachtssnelheid duidelijk weten op te krikken.

Dit is wat ik gedaan heb:

• In de DSM-configuratiescherm heb ik de MTU-waarde handmatig ingesteld. Onder Connectivity > Network > Network Interface > LAN 1 > Edit > IPv4 heb ik bij Set MTU value manually de MTU value op 1492 gezet. tcpdump geeft nu inderdaad mss 1452.
• Het OpenVPN client-configuratiebestand heb ik veranderd:
  
  code:
  

  # comp-lzo   <-- compressie uitgeschakeld
  
  tun-mtu 1492 # <-- toegevoegd
  mssfix 1300 # <-- toegevoegd

• Het server-configuratiebestand (in /var/packages/VPNCenter/etc/openvpn/openvpn.conf ) heb ik via ssh aangevuld met:
  
  code:
  

  # comp-lzo <-- compressie uitgeschakeld
  
  tun-mtu 1492 # <-- toegevoegd
  mssfix 1300 # <-- toegevoegd

Upload via SMB via OpenVPN begint met 6 MB/s en gaat na ongeveer 10 sec. verder met een snelheid die rond de 1,5 MB/s schommelt. Dat is al een flinke verbetering.

Upload via SFTP met FileZilla via OpenVPN gaat nu met een snelheid, die stabiel op 6,4 MB/s (50 Mbit/s) blijft. Precies wat ik van mijn ISP zou verwachten. Ziet er dus naar uit dat ik voor grotere overdrachten toch maar FileZilla moet gebruiken. (Wanneer komt Windows met natieve SFTP ondersteuning vanuit File Explorer? )

Je hebt me flink geholpen. Alvast een fijne jaarwisseling!

---

Edit: Ik heb me één keer opnieuw verbonden en ik zit weer op 25 kiB/s, zelfs via FTP in FileZilla. Ergens heb ik iets dus hooguit tijdelijk verbeterd.

Ik snap deze waarschuwing ook niet:

Thu Dec 31 15:15:41 2020 ::ffff:83.xxx.xxx.xxx(1194) WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1492)

Ik wil toch juist dat MTU kleiner of gelijk aan 1492 is?

Zou het helpen als ik de Fritz!Box die ik van mijn ISP heb gekregen, vervang door een router met ddwrt erop, waar ik de MTU wel zelf kan instellen, of ben ik daar door mijn ISP gelimiteerd aan 1492?

---

Ben(V) schreef op woensdag 30 december 2020 @ 19:52:

En als laatste en niet minder belangrijk, het is natuurlijk een gigantisch security risc om je system voor smb openen te zetten naar het internet toe.
Dat is gewoon vragen om gehacked te worden.

Dit hoor ik vaak en ik heb nog steeds geen allesomvattende gids voor het instellen van een NAS gevonden, omdat dat toch een beetje van de persoonlijke situatie en het gebruik afhangt. Nu je het toch nog eens in dit draadje benoemt, is mijn strategie veilig?

Ik heb alleen UDP 1194 (OpenVPN) en UDP 500, 1701, 4500 (L2TP/IPsec) geopend op mijn router. Op mijn Synology heb ik de firewall geactiveerd en accepteer ik voor de voorgenoemde poorten via LAN1 alleen verbindingen van IP-adressen uit Nederland. Voor de rest zijn alleen poorten geopend voor verbindingen vanuit het thuisnetwerk (192.168.x.x) en vanuit een VPN-adapter: (10.x.x.x).

Als ik langer weg ben, kan ik 5001 openen of is het een no-go om poorten zoals 5001 en 443 of bijvoorbeeld Plex 32400 naar buiten toe te openen?

[ Voor 13% gewijzigd door dvtxc op 31-12-2020 15:45 ]

[Thralas]

dvtxc schreef op donderdag 31 december 2020 @ 14:31:

• In de DSM-configuratiescherm heb ik de MTU-waarde handmatig ingesteld. Onder Connectivity > Network > Network Interface > LAN 1 > Edit > IPv4 heb ik bij Set MTU value manually de MTU value op 1492 gezet. tcpdump geeft nu inderdaad mss 1452.

Die was al 1492 via DHCP als het goed is. Geen ramp om het statisch te configureren, maar het hoeft niet.

code:

# comp-lzo   <-- compressie uitgeschakeld
tun-mtu 1492 # <-- toegevoegd
mssfix 1300 # <-- toegevoegd

Die waarde voor tun-mtu klopt niet. Maar omdat je mssfix gebruikt worden je TCP-packets toch nooit zo groot, dus heel veel maakt het niet uit, tenzij je iets met UDP wilt doen.

Ik zou 'm weglaten. Als je UDP wilt doen kun je dat oplossen met fragment.

Ik wil toch juist dat MTU kleiner of gelijk aan 1492 is?

Ja, maar dat dwing je al af via mssfix (TCP) of fragment (UDP). Het alternatief is de exacte MTU berekenen en instellen (tun-mtu en/of link-mtu). OpenVPN probeert je te vertellen dat wat je aan het doen bent dubbelop is.

Zoals eerder gezegd zou ik die optie weglaten, dan blijft hij 1500. Voor tcp geldt dat het naar mss 1300 wordt geclampt (effectieve mtu: 1300 data + ~20 tcp + ~20 ip = 1340).

Als je problemen blijft behouden met snelheden dan zou ik nog even met mtr aan de slag gaan. Packet los is ronduit funest voor je throughput, en kan die 25 kB/s ook prima veroorzaken.

Dit hoor ik vaak

Het wordt ook te vaak geroepen zonder nader te specificeren wat nu de reden erachter is. Er zijn er veel, maar ze zijn nooit allemaal van toepassing.

SMBv1 is onveilig omdat het lek was (allang gepatcht). Microsoft vindt SMBv1 onveilig omdat het achterhaald is (terecht, maar niet perse iets dat gevaar oplevert). SMBvX is onveilig omdat het een aantal poorten vereist waar nog véél meer protocollen overheen gaan.

Allemaal waar. Maar hier helemaal niet aan de orde: je NAS draait Linux en gebruikt Samba ipv. Windows.

Ook dáár zijn wel eens dingen aan loos, en je blijft het risico houden op een onbedoeld gastaccount of te simpel wachtwoord dat opeens de hele wereld toegang tot je shares geeft. Dat is tenminste een onderbouwde redenering.

Ik heb alleen UDP 1194 (OpenVPN) en UDP 500, 1701, 4500 (L2TP/IPsec) geopend op mijn router. Op mijn Synology heb ik de firewall geactiveerd en accepteer ik voor de voorgenoemde poorten via LAN1 alleen verbindingen van IP-adressen uit Nederland. Voor de rest zijn alleen poorten geopend voor verbindingen vanuit het thuisnetwerk (192.168.x.x) en vanuit een VPN-adapter: (10.x.x.x).

Dat is prima, en precies hoe je het zou moeten inrichten. De kans dat dit problemen oplevert is verwaarloosbaar.

Als ik langer weg ben, kan ik 5001 openen of is het een no-go om poorten zoals 5001 en 443 of bijvoorbeeld Plex 32400 naar buiten toe te openen?

Je hebt een werkende VPN; gebruik die. Kenmerk van dat soort services is dat er opeens héél veel meer attack surface is, itt. een VPN waar je meestal niets mee kan zonder authenticatie, als het een beetje meezit met keys die je onmogelijk kunt 'raden'.

Pakketten als Synology/Plex zou ik absoluut niet direct via het internet beschikbaar maken als het niet hoeft. Kwestie van tijd voordat iemand weer een keer een lek in die producten vindt en dan is het hopen dat je op tijd update.

Niet op inzetten, je kunt beter aan je VPN-setup blijven sleutelen. Kijk bijvoorbeeld eens naar Wireguard, dat maakt een 'always on'-VPN nog net wat prettiger. Als er andere locaties zijn waarvandaan je een VPN wilt hebben kun je ofwel een client gebruiken, of een router (Ubiquiti, MikroTik) of Raspberry Pi overwegen die een permanente VPN opzet.