Externe toegang openVPN en beveiliging

[haplx]

Mijn oude DS (415+) is kort geleden overleden en ben een nieuwe DS423+/DSM 7.2 aan het instellen.  Enige doel van externe toegang is alle mappen ook extern te mounten en te kunnen gebruiken. En verder natuurlijk om extern in te loggen op de DS Ik heb diverse draadjes hier gevolgd over externe toegang en heb besloten om het met openVPN te regelen. Dat lijkt me voor deze toepassing het beste (of niet?).
Het werkt eigenlijk allemaal. Ik heb wel wat open eindjes en vragen over veiligheid:

Waarom zit mijn DS op het VPN subnet?
De OpenVPN verbinding komt dus tot stand en de externe computer ziet mijn LAN. Ik zou verwacht hebben (en lees ook) dat je NAS dan nog steeds toegankelijk is op het oude IP op je subnet, dus bv 196….xxxx.  De DS echter alleen aanwezig op het door de openVPN gecreerde subnet dat je opgeeft bij VPNserver package (dus bv  op: 10.8.0.1). Klopt dat of doe ik iets fout? Ook zorgt de DNS van de router (fritz.box 5490) er in ieder geval niet voor de dat naam van de DS nog bekend is wanneer je inlogt via VPN. En hoe kom ik er achter waar de andere apparaten op dat 10.8... net uithangen?

Beveiliging van de DS
Ik heb de firewall ~opgezet zoals dat door Babylonia wordt aangereaden:

1.LAN IP bereik (dus: 196..) volledige toegang
2.openVPN IP bereik ( dus 10.8…) volledige toegang
3.eigen static IP van DS volledige toegang
4.toegang vanuit NL-IP’s alleen de services openVPN (1194) en Management UI http (5000).
Block de rest

Ik zou denken dat ik in regel 4 (Management UI http) 5000 nog weg kan laten, maar dat vindt de DS niet goed. Die killt je sessie die notabene plaatsvindt op LAN (en zonder VPN), even schrikken. Bij daarop volgende inlog is (Management UI http) 5000 teruggezet in de firewall.
Is die (Management UI http) 5000 al niet afgedekt door regel 1 (en 2) – omdat daar volledige toegang wordt gegeven?

Ik heb account van de VPN gebruiker op de DS nergens access gegeven, verder account blocking aangezet bij 4 pogingen in 1400 min. Verder heeft 2FA instellen voor de VPN gebruiker geen zin omdat de openVPN app daar niets mee doet. Zie ik iets over het hoofd?

Beveiliging van de openVPN verbinding zelf:
Ik run de openVPN nu zonder certificaat, dat lijkt me niet veilig. Ik run zonder certificaat omdat de openVPN app (win client v 3.5.1) op WIN 10 computer vraagt om laden certificaat, maar zegt: “Missing External Certificate. Please choose the external certificate for the profile”. Als je zegt “continue” werkt alles wel. 

De openVPN (.ovpn) file die is aangemaakt door de VPNserver applicatie van de DS bevat echter duidelijk een sectie met een certificaat. Dat moet het certificaat zijn dat door de VPNserver wordt gebruikt is. Dit is het self signed certificaat(?) (synology.com) …via: <control panel/security/certificate/settngs>. Zou dat dan niet voldoende zijn voor de openVPN app. Die heeft toch voldoende aan een self signed certificaat?

Misschien is een let’s encript certificaat een optie, maar is dat niet een beetje van de wal in sloot misshien, want waarom zou ik een een publieke toegang tot adverteren op een DDNS, die ik helemaal niet nodig heb en bovendien  moeizaam het let’s encript certificaat telkens moeten verlengen?

Graag jullie advies, gedachten hierover. 

[Babylonia]

Nogal wat vragen, dus haal wat stukjes aan tekst aan met beantwoording eronder.

Op een NAS heb je slechts de beperking over enkele VPN protocollen.
De meest logische keus is dan om inderdaad voor OpenVPN te kiezen.
(Synology zou eigenlijk meer moderne protocollen moeten toevoegen zoals Wiregard en IKEv2/IPSec ).

Waarom zit mijn DS op het VPN subnet?
De OpenVPN verbinding komt dus tot stand en de externe computer ziet mijn LAN. Ik zou verwacht hebben (en lees ook) dat je NAS dan nog steeds toegankelijk is op het oude IP op je subnet, dus bv 196….xxxx.

Via VPN is de NAS gewoon bereikbaar op het gebruikelijke "oude" LAN IP subnet ---> 196….xxxx
Adressen van apparaten zou je dan ook beter gewoon binnen dat sub-net  benaderen.

Het benodigde VPN "tunnel" IP netwerkbereik (jouw voorbeeld 10.8.0.1/24), is alleen nodig voor de VPN connectie zelf.
(En als de tunnel is opgezet nog wel als "neven VPN IP-adres" vanuit een ander subnet wel toegang moet hebben binnen je thuisnetwerk.
 Vandaar dat firewall regels in de NAS daar wel op moeten zijn afgestemd).

Het nadeel van OpenVPN en een ander VPN tunnel sub-net dan het "gewone" LAN IP sub-net is,
dat je via VPN niet kunt inloggen met de NAS host-naam (of hostnamen van andere apparaten om die te bereiken).
Maar alleen met het geldende "vaste" LAN IP-adres van de NAS of die van andere apparaten thuis binnen het "normale" thuis netwerk.
Omdat hostnamen van apparaten niet worden meegenomen over verschillende sub-netwerken heen.

Misschien dat je met opzet van een eigen DNS-server daar nog iets in zou kunnen bewerkstelligen??
Heb dat zelf nooit uitgeprobeerd.
Maar vermoed eigenlijk niet, omdat ook daar hostnamen over een ander netwerk heen getild moeten worden.

Houd het hier gewoon op de vastgelegde IP-adressen van apparaten zelf van het "gewone" thuisnetwerk.
 

4.toegang vanuit NL-IP’s alleen de services openVPN (1194) en Management UI http (5000).
Block de rest

Ik zou denken dat ik in regel 4 (Management UI http) 5000 nog weg kan laten,.....

Die zou je in principe ook weg kunnen laten.  Een VPN verbinding kan ook zonder Management UI functioneren.
Maar "als" je al wel de  Management UI  zou willen activeren, dan niet via de  onversleutelende  http verbinding.
In ieder geval dan met poort 5001 (https),  en zou daar tegenwoordig dan zeker nog alternatieve poorten voor inzetten.
Omdat die standaard poorten van een NAS erg in de belangstelling staan van hackers.

Beveiliging van de openVPN verbinding zelf:
......Dit is het self signed certificaat(?) (synology.com) …via: <control panel/security/certificate/settngs>.
.....
Misschien is een let’s encript certificaat een optie, maar is dat niet een beetje van de wal in sloot misschien,

Let’s Encrypt  is zeker een optie, en dat zou je dan kunnen gaan inzetten.
Maak eerst een  Synology "Quickconnect"  ID aan.
Daarmee heeft je NAS - vanuit de NAS zelf in ieder geval een connectie met de Synology servers.

Op basis van die connectie en dit  "Synology" sub-domein kun je een  Let’s Encrypt  certificaat aanmaken.
Dat bovendien elke 3 maanden automatisch wordt verlengd.  Daar hoef je helemaal niets voor te doen.
Zonder ook maar enige andere actieve externe connectie met ingestelde port forwarders voor services op de NAS in te hoeven stellen.

Als je dan alleen je NAS van buiten wilt benaderen via OpenVPN.
Kies je voor port forwarding alleen voor die VPN connectie.  (Standaard poort 1194)

Bij gebruik van het  "Synology" QuickConnect sub-domein ID - met gerelateerd Let’s Encrypt  certificaat.

Heeft mogelijk ook een nadeel?
Ben nu zelf even aan het testen hier, of de gegevens binnen het OpenVPN configuratiebestand na 3 maanden wel hetzelfde blijven?
Daar kom ik later dan nog op terug.  Want krijg nu met het testen hier nu even geen VPN-connectie.
Heb hier nogal wat verschillende VPN-verbindingen en opties in het gebruik, en sommige enkel maar als "test"  -  "zo nu en dan".
Daar kunnen in de loop van tijd best wel eens andere configuraties om de hoek kijken. (Zie "marathon" VPN test).

Voorbeeld van een NAS apparaat hier die alleen via VPN benaderbaar zou moeten zijn.
Met gebruik van QuickConnect  en daaraan gekoppeld een  Let’s Encrypt  "QuickConnect" certificaat.   (Zie vervolg reactie).

[Babylonia]

.......
Ben nu zelf even aan het testen hier.......
Daar kom ik later dan nog op terug.
......
Heb hier nogal wat verschillende VPN-verbindingen en opties in het gebruik, en sommige enkel maar als "test"  -  "zo nu en dan".
Daar kunnen in de loop van tijd best wel eens andere configuraties om de hoek kijken.

De situatie in mijn voorgaande  "zo nu en dan"   NAS  test set-up  was inderdaad gewijzigd.
Ik kon op basis van die configuratie daarbij namelijk geen VPN verbinding leggen.
(Vandaar dat ik er op terug wilde komen).

Bij verdere bestudering bleek nu ook het waarom.
Alle applicaties bleken nog gekoppeld te zijn aan een ander (NL) domein (buiten de afbeelding gehouden in de vorige reactie).
De NAS nu bovendien in een "dubbel" NAT netwerk configuratie (twee routers achter elkaar, en daar de NAS nog achteraan).

Bij aanpassen van de set-up, door alle services met o.a. de VPN-server te koppelen aan het   Synology   QuickConnect  domein.
Waar het  Let's Encrypt  SSL certificaat aan is gekoppeld.
Opnieuw export van het OpenVPN configuratiebestand, en gebruikelijke aanpassing ervan.  Bleek alles nu prima te werken.

Belangrijke opmerking daarbij !!    WEL met port forwarding van de VPN services (dus voor poort 1194 naar de NAS).
Zoals ook in mijn vorige reactie beschreven.   Omdat een VPN-connectie zelf  NIET  via een QuickConnectie kan lopen.

Met de export van het OpenVPN  configuratiebestand bleken daar nu ook twee certificaten in te staan en een kleiner persoonlijk Key bestand.
Vanuit ervaring met andere OpenVPN configuraties met twee certificaten, wat overeenkomt met een algemeen "Intermediair certificaat".
(Die twee ingesloten certificaten zijn voor alle Let's Encrypt uitgegeven certificaten hetzelfde).
Hoef je het bestand na 3 maanden NIET aan te passen bij vernieuwing van het Let's Encrypt certificaat.
Het ingesloten "Key" bestand bestand, is een uniek persoonlijk uitgegeven sleutel. Per NAS apparaat (of na fabieksreset) verschillend.

Let er wel op dat je het  QuickConnect  ID  in het OpenVPN configuratiebestand bovenaan bij  remote YOUR_SERVER_IP 1194
Precies zo overneemt zoals het in het certificaat is weergegeven.
Cryptisch beschreven als:  [ zelf gegeven naam ].direct.quickconnect.to

Die QuickConnect naam is reeds beschreven - onderste regel van het configuratiebestand achter:   verify-x509-name
Kun je met kopieer en plak overnemen (zonder aanhalingstekens), en dan bovenin in het configuratiebestand daar neerzetten.
(Had Synology net zo goed zodanig hebben kunnen programmeren, dat het ook reeds bovenin werd vastgelegd).




VPN connectie uitgetest door mijn laptop via hotspot te verbinden met mijn smartphone,
met alleen mobiele data-connectie ingeschakeld. (Ofwel test via een "externe locatie").

[haplx]

Bedankt voor de snelle reactie Babylonia, ik heb veel gehad aan alle info die je hebt staan op het forum.

Veel vragen inderdaad, maar zijn bijna alle beantwoord:


“Waarom zit mijn DS op het VPN subnet?”
Ok, mooi, openVPN is voor binnen de DS wereld ook de beste keus, Wireguard zou mooier zijn, maar ja.
Prima, dat ik de hostname niet kan gebruiken is dus normaal, begrijp ik van je.

Wat extra info over effect dat ik zag: de DS heeft op mijn LAN (196..) een vast adres. Dat adres kon ik niet pingen wanneer ik een openVPN verbinding met de DS heb. Wel kon ik daarentegen 10.8.0.1 pingen en daar zat dan tot mijn verassing de DS. Alles werkte gelukkig, bv ik kon folders mounten, inloggen etc, maar was wat vreemd. Andere apparaten zijn er ook op dat subnet. Op diverse adressen laat de ping zien dat er wat zit, ik kan alleen niet achterhalen wat. Het originele LAN net 196.. kon ik helemaal niet bereiken lijkt het, in de pogingen die ik gedaan heb.

Maar Probleem gevonden ) de optie “Enable Multiple GateWays” moet uitstaan (in:Control Panel/general/Manually Coonfigure DNS server/advanced options). Daarna zit de DS weer op zijn normale plek ook als je VPN gebruikt. Maar let op de DS zit ook nog steeds op:  10.8.0.1.

Dus dat is opgelost.

"Beveiliging van de DS"
Ben het eens met je opmerking over 5000 port. Ik zou die het liefst weglaten, maar dat gaat dus niet, raar genoeg. Ik zal in ieder geval naar HTTPS gaan en onder een ander port number gebruiken. Maar  het blijft voor mij onduidelijk wat er aan de hand is → is dit iets voor een ticket, wat denk jij?

Beveiliging van de openVPN verbinding zelf:

Ik begrijp je aanwijzingen niet helemaal:

Ik heb inderdaad al een quick connect ID. Dus dat is ok.
     

“Op basis van connectie en dit “Synology” sub-domein kun je een Let’s encrypt certificate aanmaken”

Ik zie niet waar ik dat in DSM moet doen. Ik zie onder External Access/DDNS wel een ‘let’s encrypt optie, als je een entry zou maken
bedoel je dat? Dan krijg ik natuurlijk wel een xxxxx. sinology.me domain name. Die mijn DS overal bekend gaat maken (via DNS servers). Terwijl ik zelf dat adres nooit ga gebruiken;  ik en anderen kunnen immers via openVPN direct bij mijn DS.
 
Je noemt verder het xxx.direct.quickconnect.to certificaat. Dat heb ik inderdaad ook al staan in mijn DS. Geen idee hoe ik gekregen heb ?? bij aanmelden voor de quickconnect verbinding?? Het is ook 3 maanden geldig, trouwens. Ik heb nu het certificaat voor VPNserver gewisseld van Synology.com naar Quickconnect certificaat, een nieuw ovpn file gemaakt etc. Ik blijft dezelfde melding zien bij de openVPN client. Aan de andere kant zie ik in de log van de VPN client dat er wel (!) degelijke en handshake op basis van het Quickconnect certificate plaatsvindt. Kun jij beoordelen of dit ons vertelt dat het eigenlijk wel goed gaat met de veiligheid van de VPN verbinding en dat de open VPN client paniek maakt voor niets. Dan ben ik wel klaar, voorlopig. In de log zie ik deze regel:

?[Oct 19, 2024, 23:31:33] SSL Handshake: peer certificate: CN=xxx.direct.quickconnect.to, 2048 bit RSA, cipher: TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD

Ik kan ook de hele log erin zetten als je dat helpt.

Bedankt voor je suggesties en meedenken!

[Babylonia]

-
        “Enable Multiple GateWays” moet uitstaan (in:Control Panel/general/Manually Coonfigure DNS server/advanced options).

Moest het hier terugzoeken om het te kunnen vinden. (In mijn geval van Nederlands even omzetten naar Engels) -> één menu vergeten.
Control Panel -> Network -> (tab-menu) General -> bij: Manually Configure DNS server -> (knop) Advanced Settings

Nederlands:
Configuratieschem -> Netwerk -> (tab-menu) Algemeen -> bij: DNS server handmatig configureren -> (knop) Geavanceerde instellingen

"Beveiliging van de DS"
Ben het eens met je opmerking over 5000 port. Ik zou die het liefst weglaten, maar dat gaat dus niet, raar genoeg.
Ik zal in ieder geval naar HTTPS gaan en onder een ander port number gebruiken.

Configuratieschem -> Externe Toegang -> (tab-menu) Geavanceerd

Daar vind je de gebuikte NAS standaard poorten waar je voor ieder een ander poortnummer zou kunnen invullen.
Je hoeft de poortnummers daarbij niet "weg te laten".  (Want de NAS gebruikt ze alle twee).

Alleen had je het in je eerste reactie over een externe connectie vanuit NL:

        4.toegang vanuit NL-IP’s alleen de services openVPN (1194) en Management UI http (5000).

"Als" je al van buitenaf "direct" je NAS zou willen benaderen via het DSM Management UI  (zonder gebruik van VPN).
Daarvoor gebruik je dan  NIET  de onversleutelende  poort om daarvoor in de router een port forwarder in te stellen.
Maar alleen een port forwarder voor de versleutelde  https  poort.

Maar omdat ik hiervoor al een oplossing heb gegeven om de NAS überhaupt niet voor de DSM Management UI en port forwarders
van buitenaf te laten benaderen zonder gebruik van VPN.  Blijft die benadering al helemaal buiten beeld.
Verder hangt het ook af welke services je wel of niet koppelt aan benadering via het QuickConnect domein ID / certificaat.

Je kunt het allemaal zo instellen dat er helemaal geen services van buiten via QuickConnect zijn te benaderen - zonder port forwarding.
(Daar wordt QuickConnect doorgaans voor ingezet, om zonder port forwarding toch bepaalde services te kunnen benaderen).
Alleen nu voor connectie via VPN wel.

.....ik en anderen kunnen immers via openVPN direct bij mijn DS.

Nee dat kunnen ze niet, want anderen hebben geen geldend OpenVPN configuratiebestand die men "perse" geïnstalleerd moet hebben,
waarin opgenomen "jou" unieke key / beveiligingssleutel (en certificaat). Tevens kennen anderen jou gebruikers login gegevens helemaal niet.
Waarbij andere beveiligingsmaatregelen van je NAS bij teveel "verkeerde" inlogpogingen, dat al zouden afblokken.
Je zou daarbij "als extra" ook nog een alternatieve poort voor de OpenVPN verbinding zelf kunnen instellen (1294 - 1394 - 1400... ?).

Hoe / waar je aan een QuickConnect ID een Let's Encrypt certificaat aankoppelt:
https://kb.synology.com/nl-nl/DSM/help/DSM/AdminCenter/connection_certificate?version=7

Maar dat heb je kennelijk al gedaan afgaande op het vervolg van je reactie.

Bij verbinden via OpenVPN krijg je eerst een lijst aan "log-regels" te zien, waarin je kunt opmaken hoe de connectie opbouw verloopt.
Als het allemaal netjes verloopt, wordt de VPN verbinding tot stand gebracht, en is het klaar. En sluit het venster zich.

Als er dingen NIET kloppen, wordt dat in een venster met rode tekst weergegeven, wat er dan fout gaat.
En kun je bij bestudering van die log-regels vinden waarom het fout gaat.  (Verkeerde inlognaam / wachtwoord combnatie etc.)

Komt je VPN verbinding nu tot stand of niet?  (Laatste plaatje van mijn vorige reactie)

Bij een geldende VPN verbinding kun je altijd nog je "thuis WAN IP-adres" controleren. Via OpenVPN - alleen onder IPv4
(Als tenminste in het configuratiebestand de code    redirect-gateway def1   actief is opgenomen = zonder voorafgaand # ).
https://www.watzijnmijnips.nl


Overigens gebruik ikzelf wel een andere OpenVPN Client versie dan jij.  Mijn bevindingen zijn daarop gebaseerd.
(Vermoed vooral een andere gebruikers interface).

OpenVPN GUI versie 11.50.0.0      -       OpenVPN v 2.6.12     -      datum: 18 juli 2024
https://openvpn.net/community-downloads    Is aanzienlijk compacter met een (download) programma omvang van ruim 5 MB

Tegenover iets van 100 MB  aan programma omvang van een 3.5.1  Windows Client versie met wellicht onnodige "toeters en bellen".
Waarbij op de keper beschouwd die omvangrijke versie toch echt niks anders doet dan gewoon "een OpenVPN" verbinding opzetten.
https://openvpn.net/client/client-connect-vpn-for-windows


....Daarnaast heb ik voor connectie met de een of andere  "oudere"  OpenVPN "server" versie  implementatie
die bij familie- en kennissen worden gebruikt, nog enkele extra "code" regels toegevoegd in het OpenVPN configuratiebestand.
Welke standaard niet worden gegenereerd, vanuit de opties vanuit de Synology "export" configuratie bestanden voor OpenVPN.

Dat kan mogelijk een belangrijk detail zijn in de voortdurende wisselwerking van updates van het OpenVPN platform.
Waarbij implementaties bij "externe partners" (zoals Synology) die er gebruik van maken, achter lopen op de actuele stand van zaken.

Bijvoorbeeld:
In het OpenVPN configuratiebestand wordt standaard de mate van encryptie / AES beveiligings codering meegegeven
cipher AES-256-CBC              ------->  standaard opgenomen (volgens keus binnen het OpenVPN menu van de VPN server op de NAS)
data-ciphers AES-256-CBC     ------->  extra regel toegevoegd met variant op het voorvoegsel
                                              zonder die toevoeging kreeg ik (voor div. VPN-servers) bij "Windows" nog wel eens een foutmelding

Andere meer gebruikelijk geactiveerde toevoegingen in het OpenVPN configuratiebestand:
float                            ------->  gebruik laptop in de trein met mobiele verbinding, wisseling van zendmast naar andere zendmast
auth-nocache               ------->  login wachtwoorden worden niet bewaard in de cache van een laptop (bij diefstal van een laptop)
explicit-exit-notify        ------->  uitleg via  OpenVPN referenties  (ook als referentie voor de andere commando's hiervoor genoemd)

Voor zeer expliciete implementaties zou men beter de  OpenVPN  bronnen zelf en forum daarbij kunnen raadplegen.

Zelf houd ik me met name bezig met "algemene" bereikbaarheid van  OpenVPN  servers bij familie en kennissen.

Maar evengoed gebruik ik "OpenVPN" Client opties (of alternatieve VPN methoden) ook voor....

• Connectie via een strikt beveiligde VPN met de NAS "only". (Niet nog eens extra via VPN het internet op).
• Via VPN mogelijk de aanpassing van instellingen van een router die in het thuisnetwerk "ervoor" zit, en middels VPN te bereiken.
• Via VPN "op een andere locatie" extra services mogelijk te maken die "WAN" IP-adres zijn gerelateerd, zoals IP-TV en VOIP services.
  Er zijn voorbeelden bekend waarbij familie in Zuid-Afrika via VPN en Nederlands geldend telefoon account gewoon contact hebben
  met alle "Nederlandse" kennissen en familie - voor kosten tegen normaal intern "Nederlands" telefoonverkeer.
• "Regio" gebonden services.  VPN naar "Duitsland" om Duitse TV-zenders voor die uitzonderingen, die voor Nederland worden geblokt,
  ook "hier" te kunnen bekijken. Dat geldt ook bij uitzonderingen voor "Arte TV", terwijl het eigenlijk een Europese "open" zender is.

[haplx]

Alleen had je het in je eerste reactie over een externe connectie vanuit NL

Inderdaad, dit was de situatie en de vraag:
1.   Ik wil de DS extern alleen met openVPN benaderen en met Quickconnect (maar die regelt alles zelf gelukkig).

2.   De Firewall regels in mijn DS zijn:
   Ports    Protocol        Source          IP                                        Action
   regel 1:All                 All                 196.x.x.0/255.255.255.0     Allow        
   regel 2:All                 All                 10.8.x.0/255.255.255.0       Allow        
   regel 3:All                 All                 IP van mijn DS                     Allow
   regel 4:1194,5000   OpenVPN,etc IP in NL                                Allow
   regel 5:All      All           All                                         Deny   

3.   Ik dacht laten we poort 5000 uitschakelen in regel 4 voor de veiligheid en    alleen de openVPN port openhouden. De DS staat me niet toe. Op dat moment was ik thuis ingelogd vanuit LAN zonder VPN (dus val ik op dat moment onder regel 1). Vraag was: waarom is dat zo, want in regel 1 worden alle services toegestaan?

Nee dat kunnen ze niet

Ik bedoelde anderen die gebruik van VPN om connectie te maken met DS, nadat ze een ovpn file hebben gekregen, een openVPN client hebben, Login hebben gekregen, etc. Een alternatieve port voor openVPN is een prima suggestie. Ga ik doen.

Komt je VPN verbinding nu tot stand of niet?

Je krijgt van de 3.5.1 openVPN client (windows 11) de volgende melding:
 
" alt="" class="bbc_img" />

als je dan doorklikt bij “continue”, komt de VPN verbinding netjes tot stand en werkt volledig. De VPN log laat zien dat alle connecties worden gemaakt, encryptie wordt aangezet, etc. “Waszijnmijnips.nl” laat dan nog zien dat ik inderdaad op mijn eigen LAN zit.
Conclusie: Alles ok, onduidelijk dus wat de melding van de openVPN client betekent, die is niet van belang.

Ik ga naar die compacter openVPN client van jou kijken.

[Babylonia]

    Ik dacht laten we poort 5000 uitschakelen in regel 4 voor de veiligheid en
    alleen de openVPN port openhouden. De DS staat me niet toe.

Beetje verwarrende wijze van Firewall regel beschrijvingen.
Ik moest meerdere keren lezen en terugkijken in een NAS met wat er nu werkelijk staat.  (Of tekst veel beter uitlijnen).

Vraag me af, of je begrijpt hoe firewall regels functioneren?

Jou firewall regel 3 is volledig overbodig.  Dus weghalen.
Bij de eerste regel heb je namelijk al toestemming gegeven om voor bronnen  binnen je eigen thuisnetwerk  alles toe te staan.
(Geen restricties voor verkeer binnen je eigen thuisnetwerk).   Dat overlapt dus ook het IP-adres van je NAS.

Waarom je voor je eigen thuisnetwerk alles toestaat (eerste firewall regel).
Omdat er in een thuisnetwerk veel meer achterliggende services draaien dan wat mensen doorgaans in de gaten hebben.
Zoals netwerk protocollen (poorten 137, 138, 139, 445), multicast gerelateerde poorten (Bonjour - AirPlay) - etc.
https://kb.synology.com/nl-nl/DSM/tutorial/What_network_ports_are_used_by_Synology_services


Jou firewall regel 4:       1194,5000   OpenVPN,etc IP in NL       Echt helemaal verkeerd !!

Het enige wat je "van buiten" (extern) wilt toestaan is de service voor OpenVPN (poort 1194) - en dat voor Nederland, niets anders.
En al helemaal geen onversleutelde poort 5000.   (Meerdere keren uitgelegd)  of andere  etc  services.

Gewoon de firewall regels volgen zoals < HIER >  beschreven.  (Doorverwijzing onderaan de eerste reactie van Firewall onderwerp).

Nee dat kunnen ze niet

Ik bedoelde anderen die gebruik van VPN om connectie te maken met DS, nadat ze een ovpn file hebben gekregen, een openVPN client hebben, Login hebben gekregen, etc......

Ik weet niet hoeveel mensen je een OpenVPN verbinding wilt geven, maar daar ligt nu juist ook weer een beveiligings-risico.
Hoe zorgvuldig zijn die mensen in het bewaren van data?  Zou je dat voor iedere gebruiker in de gaten moeten houden.

Gaat het één keer verkeerd, of iemand is "uit de gratie" kun je voor die gebruiker diens NAS gebruikers account wel verwijderen.
Dan kan die bewuste persoon er niet meer in.  Maar de "persoonlijke" beveiligingssleutel / key, van het OpenVPN configuratiebestand
heeft die persoon dan nog wel steeds in zijn bezit.  (Of degene moet onder jou toeziend oog het configuratiebestand wissen).

De kans is klein dat die key en verdere gegevens van een configuratiebestand in verkeerde handen valt. Ondenkbeeldig is het niet.

Als dat allemaal wat verder weg ligt, moet je de volledige OpenVPN voor iedereen stopzetten, een andere persoonlijke key aanmaken,
en voor ieder ander die je dan weer alsnog opnieuw een OpenVPN verbinding wilt geven,
weer nieuwe OpenVPN configuratie bestanden verstrekken.  Maak je het voor jezelf wel heel erg moeilijk.

Zou ik toch eerder voor andere externe connectiemethoden kiezen,
en verder rechten beperken met wat gebruikers op je NAS mogen doen.
(Vaak wil je familie / kennissen alleen "leesrechten" geven voor data op een NAS.
 Daar heb je helemaal geen VPN verbinding voor nodig).

Die   class="bbc_img"    foutmelding is wel heel vreemd.
Zou denken dat het iets te maken heeft met een "plaatje" (img) van een gebruikers interface ??

[Birdy]

Die   class="bbc_img"    foutmelding is wel heel vreemd.
Zou denken dat het iets te maken heeft met een "plaatje" (img) van een gebruikers interface ??

Er staat n.l.:

Code: [Selecteer]

[img]http://[attachimg=1][/img]

[Babylonia]

Ah, snapte het al niet.      

Van een gepost plaatje hier op het forum,
de achterliggende ingevoegde code bij opmaken van het bericht enkele karakters per ongeluk weggehaald.

We lezen het wel weer opnieuw terug, met wat de topic starter ermee bedoelt.
Maar aangezien er nogal wat tegenstrijdigheden in de firewall regels zitten, lijkt me dat zinvoller om die eerst aan te passen.