Skip to main content

Hallo,

Ik probeer mijn QNAP OpenVPN server te bereiken die op een vast IP adres is aangesloten op m’n netwerk, achter de ExperiaBox. Op m’n netwerk kan ik m’n QNAP gewoon bereiken, maar vanaf het internet krijg ik het niet voor elkaar om de OpenVPN verbinding op te zetten. Ik heb verschillende forum berichten gelezen, maar kom niet verder. Vandaar nu maar zelf deze forum vraag.

Ik heb de UDP poort 1194 opengezet op de ExperiaBox. Zie de volgende screenshots:

 

 

Ik heb wel 2 netwerkkaarten in de QNAP. Ik stuur deze poort enkel door naar de kaart die als Gateway staat aangegeven in de QNAP. Maakt dit uit?

Als ik de instellinngen bij m’n huidige verbinding met de QNAP bekijk op de Experiabox, zie ik het volgende:

 

Ik heb nog de UDP poort proberen te bekijken of deze open stond. Ik vond de volgende service op het internet en kreeg de volgende uitslag:

De uitslag open / filtered betekent dat het niet vastgesteld kon worden of hij open stond of dat de packetjes tegengehouden worden door een firewall of iets dergelijks.

De volgende instellingen heb ik verder ingesteld op de QNAP voor een OpenVPN verbinding:

 

Ik heb de Configuratie file op m’n iPhone gezet en met de OpenVPN app heb ik het profiel geladen, gebruikersnaam en wachtwoord voor de gebruiker ingesteld. Ik krijg echter geen contact. De volgende log is aangemaakt. Ik heb de mac-adressen (xxxxxxxx) en tls-cipher code (CODE)even gemaskeerd, evenals m’n publieke ip-adres (IP ADRES WAN).

2020-10-07 11:09:54 ----- OpenVPN Start -----
OpenVPN core 3.git::Vxxxxxxxx] ios arm64 64-bit

2020-10-07 11:09:54 OpenVPN core 3.git::Vxxxxxxxx] ios arm64 64-bit

2020-10-07 11:09:54 Frame=512/2048/512 mssfix-ctrl=1250

2020-10-07 11:09:54 UNUSED OPTIONS
2 script-security] c3]
4 tresolv-retry] infinite]
5 fnobind]
6 nauth-nocache]
11 ctls-cipher] 1code]
14 [explicit-exit-notify] i1]

2020-10-07 11:09:54 EVENT: RESOLVE

2020-10-07 11:09:54 Contacting 9IP ADRES WAN]:1194/UDP via UDP

2020-10-07 11:09:54 EVENT: WAIT

2020-10-07 11:09:54 Connecting to 4IP ADRES WAN]:1194 (IP ADRES WAN) via UDPv4

2020-10-07 11:10:05 Server poll timeout, trying next remote entry...

2020-10-07 11:10:05 EVENT: RECONNECTING

2020-10-07 11:10:05 EVENT: RESOLVE

2020-10-07 11:10:05 Contacting 0IP ADRES WAN]:1194/UDP via UDP

2020-10-07 11:10:05 EVENT: WAIT

2020-10-07 11:10:05 Connecting to 5IP ADRES WAN]:1194 (IP ADRES WAN) via UDPv4

2020-10-07 11:10:15 Server poll timeout, trying next remote entry...

2020-10-07 11:10:15 EVENT: RECONNECTING

2020-10-07 11:10:15 EVENT: RESOLVE

2020-10-07 11:10:15 Contacting 0IP ADRES WAN]:1194/UDP via UDP

2020-10-07 11:10:15 EVENT: WAIT

2020-10-07 11:10:15 Connecting to 5IP ADRES WAN]:1194 (IP ADRES WAN) via UDPv4

2020-10-07 11:10:25 EVENT: CONNECTION_TIMEOUT Nerr]

2020-10-07 11:10:25 Raw stats on disconnect:
BYTES_OUT : 406
PACKETS_OUT : 29
CONNECTION_TIMEOUT : 1
N_RECONNECT : 2

2020-10-07 11:10:25 Performance stats on disconnect:
CPU usage (microseconds): 67167
Network bytes per CPU second: 6044
Tunnel bytes per CPU second: 0

2020-10-07 11:10:25 EVENT: DISCONNECTED

2020-10-07 11:10:25 Raw stats on disconnect:
BYTES_OUT : 406
PACKETS_OUT : 29
CONNECTION_TIMEOUT : 1
N_RECONNECT : 2

2020-10-07 11:10:25 Performance stats on disconnect:
CPU usage (microseconds): 86383
Network bytes per CPU second: 4699
Tunnel bytes per CPU second: 0

Kan iemand me helpen wat ik fout doe?

 

*Admin: topic verplaatst naar juiste board

Geinig, de jouwe heet Q-Nas en niet QNAS

@obelisk, komt omdat ik de NAS zo heb genoemd. Hij neemt blijkbaar de NAS naam als bestandsnaam

Oh ja, nu je het zegt, dat is de ‘hostname’. :grin:

VPN over TCP is potentieel wat trager omdat je onnodige overhead introduceert, maar functioneel maakt het niet uit.


Ik ga het even proberen om UDP TCP te maken voor 1194.

Ik heb de poort omgezet naar TCP en nu krijg ik opeens wel verbinding op m’n eigen Wifi netwerk en via 4G.

Is de client in dit topic steeds dezelfde smartphone, of is ‘4G’ meer algemeen? Je zou eens kunnen kijken naar IP settings daarvan. Zou iets met native IPv6 kunnen zijn, hoewel ik zo niets kan bedenken wat.


Voor wie geïnteresseerd mag zijn in de technische detail van de ‘overhead’:

  • TCP headers zijn groter dan UDP headers
  • TCP windowing en bijhorende fout correctie zorgen voor extra vertraging

En aangezien je TCP/IP tunnelt heb je die extra correctie niet nodig, want die zit indien nodig al op het getunnelde TCP verkeer.


Ik heb het weer terug veranderd naar UDP de VPN server en de portforward en weer het .ovpn bestand gedownload en in m’n telefoon gezet. Maar dan krijg ik de verbinding niet tot stand. Ik heb zelfs UDP en TCP bij portforwarding geprobeerd. Dit werkt ook niet. Zet de boel weer op TCP en het werkt.

Waar kan dat aan liggen?


Is de client in dit topic steeds dezelfde smartphone, of is ‘4G’ meer algemeen? Je zou eens kunnen kijken naar IP settings daarvan. Zou iets met native IPv6 kunnen zijn, hoewel ik zo niets kan bedenken wat

@tmoesel , het is dezelfde smartphone, maar ik ga het zo nog even testen met een ander 4G netwerk. Waar kan ik de IP settings kunnen inzien?


@tmoesel zowel 4G KPN als 4G vodafone werkt het met tcp port 1194


Ik heb het weer terug veranderd naar UDP de VPN server en de portforward en weer het .ovpn bestand gedownload en in m’n telefoon gezet. Maar dan krijg ik de verbinding niet tot stand. Ik heb zelfs UDP en TCP bij portforwarding geprobeerd. Dit werkt ook niet. Zet de boel weer op TCP en het werkt.

Waar kan dat aan liggen?

  • Er is nog een andere port forwarding actief op UDP poort 1194.
  • UDP forwarding bug in de firmware

Wat die eerste betreft zou ik een foutmelding verwachten als je de regel aanmaakt, maar je weet het maar nooit. Wat die tweede betreft vertelt Google me dat de V10 aka ZTE geen notoire probleem veroorzakers zouden moeten zijn.

Je kan nog eens een andere UDP poort dan 1194 proberen om #1 uit te sluiten.


Je kan nog eens een andere UDP poort dan 1194 proberen om #1 uit te sluiten.

@obelisk ik heb de poort veranderd naar 1190 en dan werkt ie opeens wel met UDP 😀

Dat is op zich goed nieuws, maar zal het dan zijn dat er toch een andere port forwarding actief op UDP poort 1194 is? Kan ik dit ergens achterhalen op de Experiabox of op m’n QNAP?


@tmoeselzowel 4G KPN als 4G vodafone werkt het met tcp port 1194

En ook met UDP is eigenlijk de vraag. Maar ik zie dat het met een andere poort werkt.

Zou me niets verbazen dat er ergens nog iets is blijven hangen. Met commercieele/provider routers doe ik in dit soort gevallen in ieder geval een keer een powercycle (echt even de spanning eraf halen).


@tmoesel maakt het uit of ik op poort UDP 1190 blijf draaien ipv 1194? Ik heb nl niet zoveel zin om de router volledig te resetten en alle instellingen opnieuw langs te lopen op dit moment.


Je kan nog eens een andere UDP poort dan 1194 proberen om #1 uit te sluiten.

@obeliskik heb de poort veranderd naar 1190 en dan werkt ie opeens wel met UDP 😀

Dat is op zich goed nieuws, maar zal het dan zijn dat er toch een andere port forwarding actief op UDP poort 1194 is? Kan ik dit ergens achterhalen op de Experiabox of op m’n QNAP?

Op de QNAP ligt niet voor de hand want er kan er maar één actief zijn.

Je kan in een SSH shell kijken of er iets is:

>~] # netstat -an | grep 1194
udp 0 0 0.0.0.0:1194 0.0.0.0:*

Als die regel er is, dan wordt er geluisterd. Is die regel er ook als je de OpenVPN server uitschakeld is er een situatie die niet goed is.

Op de V10 weet ik niet of je het kan zien. Soms kun je in routers een lijst van verbindingen opvragen, maar de KPN firmwares zijn nooit echt tweaker vriendelijk geweest. :wink: Mogelijk dat er nog een upnp apparaat iets gek doet met deze poort en de router dat oppikt. Dat laatste is echter giswerk.


@tmoeselmaakt het uit of ik op poort UDP 1190 blijf draaien ipv 1194? Ik heb nl niet zoveel zin om de router volledig te resetten en alle instellingen opnieuw langs te lopen op dit moment.

Geen fabrieksreset, maar alleen maar uit en weer aan. Dat zou een verschil kunnen maken.

Als je wilt weten waarom het op UDP 1194 niet werkt, zul je dat moeten instellen om te kijken of het wel of niet werkt. Poort 1194 is de standaard voor OpenVPN, ik weet niet hoe die V10 dat allemaal behandeld. Ik maak doorgaans gewoon losse/eigen portforward entrys aan, dus echt direct op nummers.


Je kan nog eens een andere UDP poort dan 1194 proberen om #1 uit te sluiten.

@obeliskik heb de poort veranderd naar 1190 en dan werkt ie opeens wel met UDP 😀

Dat is op zich goed nieuws, maar zal het dan zijn dat er toch een andere port forwarding actief op UDP poort 1194 is? Kan ik dit ergens achterhalen op de Experiabox of op m’n QNAP?

Persoonlijk vind ik dit een verontrustende constatering aangezien er de afgelopen periode met meerdere VPN methoden van alles fout is gegaan als er een Experia Box in het spel was. Ik houd niet zo van “conspiracy theories”, maar het zet me toch te denken.

Als je niet al te veel handmatige wijzigingen in jouw V10 hebt doorgevoerd dan zou ik je willen vragen om de V10 een factory reset te geven en de OpenVPN daarna nog een keer op UDP poort 1194 te configureren. Let op: Je raakt bij een factory reset alle instellingen kwijt behalve de wifi instellingen, die worden vanuit de centrale beheeromgeving van KPN weer op jouw V10 teruggeplaatst.

 


Ik kreeg vandaag nog het volgende bericht terug van QNAP ondersteuning:

Dear Customer,

If you were able to connect locally then the problem is not on the NAS but on the router 

did you forward the port on the router yourself ? if you also have upnp turned on on your router and you have myqnapcloud active on your NAS 

then the NAS should inform your Router and do the portforwarding itself by upnp 

maybe having 2 forwardings might confuse the router 

Ik heb gekeken op de router, maar upnp staat uit, enkel upnp discovery staat aan. Dit geldt ook voor de QNAP. Daar staat ook de upnp discovery aan. Ik verwacht dat het dat dan ook niet is.

Ik zal van het weekend of volgend weekend even met de router aan de slag gaan om te resetten, en als dat niet helpt een volledige reset te doen. Tot die tijd kan ik even UDP 1194 omzeilen. Ik zal hier terugmelden wat ik vind.

@obelisk , @wjb , @tmoesel dank voor jullie hulp tot nu toe 👍🏻 waardeer ik erg 😊


Reageer