Hoi @ChrisJ . Welkom op het forum.

Hier spelen zoveel variabelen mee dat ik er niks zinnigs over kan zeggen. Wat bedoel je precies met mobiele hotspot? 

Krijg je wel verbinding met je NAS via een gewone wifi en/of mobiele verbinding? 

@ChrisJ Welke VPN techiek gebruik je ?

Wireguard, OpenVPN, SSL-VPN zouden wel moeten werken. Als er een retour poort nodig is levert het op het IPv6 gebaseerde mobile netwerk problemen op, komt er op neer dat het sterk of geheel 1-richtingsverkeer is. De mix van IPv6 en IPv4 kent vele valkuilen, je kan APN=advancedinternet instellen op je smartphone, dan zou het wel moeten werken. Dat is er geen CGNAT actief en hangt je mobile direct aan het internet.

dank tot zover. wat ik bedoel is dat ik via mijn mobiele hotspot (dus 4g connectie vanaf mijn mobiel verbonden met mijn laptop) geen connectie via VPN kan maken. (synology VPN). echter thuis via de wifi of via de wifi vanaf andere locaties.

Het gaat hier om een macbook met een L2TP VPN connectie opgezet.

Ik neem aan de VPN opgezet vanuit de Macbook zelf, en niet vanuit de mobiele telefoon.
En de WiFi hotspot alleen als “doorgeefluik” van de verbinding tussen Macbook en mobiele telefoon.

Als het met L2TP niet zou lukken kun je nog overwegen OpenVPN te gebruiken.

https://kb.synology.com/nl-nl/DSM/tutorial/How_do_I_connect_to_Synology_VPN_Server_via_Mac

Het gekke is dus dat wanneer ik een andere mobiele verbinding van een andere provider gebruik, ik wel gewoon een VPN connectie krijg op de mac. Dus mobiele hotspot via een andere telefoon..

Probeer het APN toegangspunt van de eigen mobiele telefoon op "advancedinternet" te zetten.
(Na gebruik weer terugzetten naar "internet” omdat het een veel hoger accugebruik geeft).

Verder:

• Gewoon de telefoon eens helemaal uitzetten, en weer opstarten
• Je hebt de mobiele data toch wel ingeschakeld staan??

Van T-Mobile NL weet ik uit trial-error van een paar jaar terug dat ze een aantal portforwards hebben (en alleen IPv4). Poort 500 zal dus wellicht opstaan voor de VPN die jij gebruikt.

Vodafone NL kan ik niet uit ervaring zeggen, wel dat ze e.v.t. per individu iets konden regelen. Misschien nu verder geautomatiseerd, maar weet ik niet.

T-Mobile USA heeft  al heel lang IPv6 backbone en als je goed graaft kun je de voors en tegens wel vinden.

KPN is anders dan T-Mobile USA, maar detail verschillen kan ik niet met zekerheid zeggen, ik heb alleen maar een KPN prepaid SIMkaart en daarvoor is nog geen IPv6 aangezet. Je zult met diverse netwerktools aan de slag moeten, hopelijk reageert er iemand die ook Mac en iPhone? en Synology en 2x KPN heeft die het probleem kan reproduceren.

Als VPN Client vanuit locatie naar een VPN-server thuis heb je niets te maken met port forwards.
Dat is pas op niveau van je thuisnetwerk aan de hand, vanuit de router naar je NAS toe bijvoorbeeld, (als daar tevens de VPN-server op draait).

Toch heb je uiteraard te maken met een “keten” van aan elkaar geknoopte connecties. Waar net kleine verschillen in gebruikte apparatuur en systemen, dat net niet 100% goed op elkaar hoeft aan te sluiten.

Heb wel gemerkt dat sommige VPN methoden soms net wat meer moeite hebben om met het standaard APN toeganspunt (“internet”) overweg te kunnen. Net ergens een klein foutje, komt de verbinding niet tot stand. Het APN toeganspunt op “advancedinternet” lijkt dan toegeeflijker te zijn.

Omdat VPN doorgaans gebruik maakt van het UDP protocol, waarbij geen controle plaats heeft van verzonden data packets zelf. (Controle bij VPN heeft dan wel op een andere laag / niveau plaats).
Zijn VPN-verbindingen relatief gezien erg instabiel, kunnen moeizamer tot stand komen, of in mogelijke gevallen soms helemaal niet. Het kan een hele uitzoekerij zijn waar „ergens“ in de keten van aan elkaar geknoopte connecties haperingen kunnen voorkomen.

Storingen verminderen / „vermijden“ / opheffen:
De ene VPN methode kan een positief resultaat opleveren, tegenover een andere methode „geen“.
Dus het kan voordeel opleveren, meerdere VPN methoden als „reserve“ achter de hand te hebben.

Een storing kan in voorkomende gevallen ook worden opgelost, door het apparaat waarmee je verbindt (laptop, smartphone), of waarop de server draait (NAS of router) simpelweg te herstarten.
(Maar ja, voor een NAS „op afstand“ ben je meestal niet ter plekke).

En zoals eerder aangehaald, bijv. het gebruik van een ander toegangspunt.

Ook versies van firmware / software kunnen bepalend zijn in wel of geen goede VPN afhandeling. Mogelijk speelt er op dit moment ook mee dat providers op “systeem niveau” bezig zijn kwetsbaarheden m.b.t. het “Open SSL” protol te corrigeren? Dat zal mogelijk ook nog her en der niet helemaal 100% foutvrij verlopen?   Dus nogal wat variabelen waar een en ander mis kan gaan.

Marathon VPN test:
Toevallig ben ik net een omvangrijke VPN “test marathon” aan het vastleggen.
Omdat ikzelf ook in een aantal erg specifieke gevallen tegen VPN problemen aanloop.
Testen omvatten o.a.:
Direct vanuit een smartphone (Android 11) naar de VPN-server (op de router) thuis, maar ook als Client vanuit een laptop via WiFi HotSpot of tethered USB connectie met de smartphone.

Maar ook bijv. de mogelijkheden van een smartphone via tethered USB aan een router. Niet alleen naar mijn eigen VPN-server thuis. Maar tevens ook naar 4 andere VPN-servers elders, waarbij verschillende internet providers in het spel zijn.

Andersom ook bij een locatie elders in een NAT achter NAT set-up VPN connecties vanuit mijn “meeneem” router, of die weer “rechtstreeks” elders achter internet aangesloten.
(Of vanuit de laptop de VPN Client via de WiFi connectie met die meeneem router).

Heb afgelopen week mogelijk wel 40-50 VPN-verbindingen uitgeprobeerd.
Veelal met succes, maar ook voorbeelden waar het op vast loopt. En dat is eigenlijk nog maar een “beperkte” test, afhankelijk van typisch gebruik van bepaalde apparaten die voorhanden zijn.

Zomaar even de vinger op de zere plek leggen waar het aan schort is er niet bij. Zelf maak ik geen gebruik van Apple apparatuur, heb met die VPN-testen daar juist geen “Apple” voorbeelden van.

Overigens leveren VPN-connecties vanuit een VPN Client op een laptop (met Windows) via WiFi (router), WiFi hotspot (of tethered USB) met smartphone doorgaans weing problemen op.

Het zijn portforwards op Carrier Grade NAT niveau, dus niet bij jouw thuis, maar in de netwerk/routing infrastructuur van de mobile operator. Een L2TP client stuurt data naar server (outbound) en er moet iets ontvangen kunnen worden op poort 500 (inbound). Daarvoor moet er een ‘gat in NAT’, o.a. bij de carriers infra / operator.

Ik vermoed dat die portforwards op Carrier Grade NAT niveau alleen nodig is als jezelf achter een Mobiele connectie een VPN-server zou willen gebruiken?  (Of bijv. een web-server of zo).
Ofwel de verbinding de “andere kant uit”.  De aanroep voor een verbinding naar jou “achter de mobiele connectie”.  (Heb je eigenlijk ook een “vast” mobiel IP-adres nodig).

Bijv. mensen in het buitengebied met een mobiele connectie die thuis (in dat buitengebied) een NAS hebben staan, waar ze vanaf een andere plek willen inloggen.  Maar is niet de soort connectie op Client niveau vanuit de mobiele telefoon naar een server elders toe (die op zijn beurt weer achter een vaste verbinding zit).

Verder komt er altijd connectie / ontvangst “terug”, anders zou je niet eens kunnen internetten.