QNAP OpenVPN bereiken via ExperiaBox V10

Ah … daar.

Als je daar zou kiezen voor "Allow connections from the list only" dan zou dat het issue van @HenriHi heel goed kunnen verklaren.

Dan wel ja, overigens moet hij dat dan bewust geconfigureerd hebben want dit is de standaard instelling.

@wjb dank voor de suggestie. Heb het meteen even nagekeken. De instelling stond daar al zo:

@obelisk dank dat je het even hebt nagekeken bij jou. Heb jij een zelfde opstelling draaien: QNAP direct aangesloten op de Experiabox V10?

Nee @HenriHi , ik heb een eigen router achter de glasvezel hangen (zie onderschrift).

De v10 ken ik verder niet, ik heb een blauwe maandag de v10a gebruikt maar daar zit nu een dikke laag stof op.

Als je die webserver op http://192.168.2.50 kan bereiken en je hebt een port-forwarding op de V10 gemaakt voor TCP poort 80 dan moet je de webserver ook op jouw publieke IP adres vanaf Internet kunnen benaderen.

Om een eventueel issue rond NAT loopback uit te sluiten, benader die webserver via 4G.

@wjb Ik heb het even getest en nu kan ik inderdaad m’n webserver bereiken via 4G 👍🏻 Hebben we hier iets mee uitgesloten nu qua mogelijke oorzaken?

De OpenVPN verbinding ook meteen getest, maar die werkt nog niet.

@obelisk Ah, het onderschrift had ik inderdaad nog niet gelezen. Had ik jouw opzet maar. Helaas wordt hier nog geen glasvezel geleverd 😕

OpenVPN op de QNAS kan ik niet mee helpen, ik zet liever zo weinig mogelijk diensten open op de NAS richting het internet. QNAS heeft kwa security al een een paar tikken op de vingers gehad.

De NAS is voor file storage en MariaDB, om te spelen heb ik wel een Raspberry PI servertje.

Als ik teruglees zie ik dat je al succesvol hebt kunnen verbinden met de OVPN via je lokale netwerk. Daardoor neig ik toch de schuld bij de portforwarding te leggen. Zelf zou ik de forward en keer weggooien en opnieuw configuren ook al lijkt alles goed te staan.

 Als het dan nog niet werkt kun je nog proberen om de ‘Network interface’ in plaats van op ‘All’ te specificeren in de OpenVPN server, maar aangezien de .2.50 werkt geeft het waarschijnlijk geen verandering.

Als het dan nog niet werkt haal ik er Wireshark of tcpdump bij om te kijken of er überhaupt iets binnenkomt op het netwerk, maar dan zijn we op een ander niveau aangeland.

@obelisk dank voor de suggestie. Ik ga even de huidige portforwarding op de Experiabox eruit gooien en opnieuw aanmaken

Ter info: Ik heb QVPN even geïnstalleerd, een OpenVPN server geactiveerd en de config geïmporteerd in de ‘OpenVPN voor Android’ app.

Na het aanmaken van de bijbehorende DST-NAT rule (zeg maar port forward) in de firewall was ik in de eerste poging binnen. Dus QVPN is in default configuratie gewoon bereikbaar.

Kan je via jouw eigen wifi de webserver ook benaderen op jouw publieke IP adres?

Is jouw publieke IP adres ook het IP adres dat in die .ovpn bij “remote” vermeld wordt?

De QNAP detecteerd je publieke adres voor hun Cloud en andere remote diensten (die je niet hoeft te gebruiken overigens). Ik zie bij mij het correcte publieke adres in het OpenVPN configuratie bestand staan.

remote 84.82.xxx.xxx 1194

@HenriHi heeft dat dacht ik al bevestigd maar het kan geen kwaad nog een keer te kijken.

Kan je via jouw eigen wifi de webserver ook benaderen op jouw publieke IP adres?

@wjb Ja ik kan m’n publieke ip adres gewoon bereiken via m’n eigen wifi netwerk. Ik heb even een test gedaan door de portforward voor HTTP uit te zetten en dan valt hij weg. Zodra ik de portforward weer aanzet, kan ik hem gewoon via m’n wifi netwerk bereiken en ook via 4G.

Is jouw publieke IP adres ook het IP adres dat in die .ovpn bij “remote” vermeld wordt?

Ja, ik het het even nagekeken, maar het is gewoon mijn publieke IP adres. Zoals @obelisk al aangaf, dit gebeurd automatisch bij QNAP, wat mij wel verbaasde, want bij m’n oude Synology moest ik het .ovpn bestand daarop nog wijzigen.

@obelisk ik gebruik gewoon de default installatie van QNAP en heb ook geen SSL certificaat veranderd op de QNAP. Het is daarmee het default certificate.

Heb jij wel dit certificaat veranderd? Kan dit nog uitmaken?

Mooi, dan kunnen we issues met NAT loopback uitsluiten.

Dan staat dat ook goed.

Kan jij de inhoud van jouw .ovpn hier eens posten waarbij je het certificaat (indien embedded) weglaat en het IP adres even wegpoetst. 

Ik heb helemaal niets met dat certificaat gedaan, als ik aanlog aan het systeem kreeg ik dan ook security meldingen die ik gemakshalve gewoon negeer. Overigens heeft dat certificaat voor zover ik weet niets te maken met OpenVPN maar vooral voor de webgerelateerde zaken.

Het enige dat ik nu nog kan bedenken is uitsluiten dat de V10 iets raars doet met port 1194 of UDP. Je kan de OVPN server als test op TCP zetten (en de forward dus ook) en eventueel nog op een andere port.

Als dat het ook niet is breekt mijn spreekwoordelijke klomp.

Ter vergelijk, deze werkte bij mij out-of-the-box:

## How to setup OpenVPN client?
## 1. Install OpenVPN software on your platform.
## 2. Double click QNAS.ovpn file to create new connection profile.
## 3. Type username and password while connection.

client
dev tun
script-security 3
remote 84.xxx.xxx.xxx 1194
resolv-retry infinite
nobind
auth-nocache
auth-user-pass
remote-cert-tls server
reneg-sec 0
cipher AES-128-CBC
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA
comp-lzo
proto udp
explicit-exit-notify 1
<ca>
-----BEGIN CERTIFICATE-----
zou je wel willen ...
-----END CERTIFICATE-----
</ca>

@wjb hierbij de inhoud van mijn .ovpn bestand:

## How to setup OpenVPN client?
## 1. Install OpenVPN software on your platform.
## 2. Double click Q-Nas.ovpn file to create new connection profile.
## 3. Type username and password while connection.

client
dev tun
script-security 3
remote [PUBLIEK IP ADRES] 1194
resolv-retry infinite
nobind
auth-nocache
auth-user-pass
remote-cert-tls server
reneg-sec 0
cipher AES-128-CBC
tls-cipher [VERWIJDERD]
comp-lzo
proto udp
explicit-exit-notify 1
<ca>
-----BEGIN CERTIFICATE-----
[VERWIJDERD]
-----END CERTIFICATE-----
</ca>

@wjb .ovpn bestand ziet er precies zo uit zoals @obelisk ook heeft.

Ik heb helemaal niets met dat certificaat gedaan, als ik aanlog aan het systeem kreeg ik dan ook security meldingen die ik gemakshalve gewoon negeer. Overigens heeft dat certificaat voor zover ik weet niets te maken met OpenVPN maar vooral voor de webgerelateerde zaken.

Ja, aangezien ik ook de hele tijd die meldingen kreeg en de QNAP door die melding niet eens kan openen met Chrome (ik gebruik Firefox nu om de QNAP te beheren), dacht ik dat het misschien daaraan zou kunnen liggen.

Het enige dat ik nu nog kan bedenken is uitsluiten dat de V10 iets raars doet met port 1194 of UDP. Je kan de OVPN server als test op TCP zetten (en de forward dus ook) en eventueel nog op een andere port.

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

Geinig, de jouwe heet Q-Nas en niet QNAS … Voor de volledigheid, ik heb hier QVPN versie 2.2.661 (20191122) op een TS-431P2 met QTS versie 4.4.3.1439 (2020/09/25).

Ik had ondertussen ook een bericht uitstaan bij de helpdesk van QNAP met screenshots van alle instellingen. Dit kreeg ik als antwoord:

Dear Customer,

Thank you for contacting QNAP support.

the settings are correct on the NAS side if you are able to connect locally , so it has to be the router that is blocking the access or you might have setup an allow ip range locally so outside ip cant connect to the NAS 

Wat zouden ze bedoelen met de laatste zin “might have setup an allow ip range locally “ ?

Onderstaand mijn .ovpn waarmee ik mijn Synology NAS thuis benader.

dev tun
tls-client
remote xyz.synology.me 1194
redirect-gateway
pull
proto udp
script-security 2
reneg-sec 0
cipher AES-256-CBC
auth SHA256
auth-user-pass
comp-lzo
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>

Toen ik nog een V10 had werkte dit ook probleemloos.

Ik heb echter geen ervaring i.c.m. de laatste firmware van de V10 maar ik zou aan de andere kant ook niet weten waarom die problemen zou moeten geven.

Geen idee, die security → ‘allow/deny’ hadden we al uitgesloten in de zin dat alles standaard open staat.

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 dat normaal? En kan ik dan gewoon TCP gebruiken of heeft dat consequenties?

Daar komt bij dat de webserver op die QNAP wel benaderd kan worden vanaf Internet. Er staat mijns inziens dus eigenlijk niets die OpenVPN verbinding in de weg. Het wijzigen naar een TCP tunnel is een interessante wijziging waarvan ik benieuwd ben naar het resultaat.

Edit: Het resultaat is er al. 

Je kunt rustig TCP gebruiken.

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