"Release Candidate" - SRM versie 1.3.1-9346 - Update 1

[Briolet]

Ik vind het heel vreemd dat ze er ongevraagd een subdomein voor zetten. Dan ben je plots ook niet meer bereikbaar op het internet, tenzij je dit subdomein ook bij je DNS provider toevoegt.

Het zal vast een instelling zijn die uit/aan te zetten is en waar je het subdomein kan kiezen.

ps: zo'n subdomein heeft toch niets met windows te maken? Dat moet dan ook zo zijn bij Android, iOS, MacOS, Linux etc.

[Babylonia]

Via Android kan het zijn dat men een andere methode volgt??  Want die heeft nog een oudere versie VPN Plus Client.

Binnen Windows, met dezelfde VPN Client software  versie 1.4.5-0684_X64  in een webbrowser, onder dezelfde web-pagina,
maar dan alleen het gebruik van een andere poort  (heb twee routers achter elkaar, en zou dan van beide SSL VPN kunnen benaderen.
Heeft alleen SRM 1.3.1 dat vervelende extra subdomein.  Vind inderdaad nergens info daarover terug.

Terugklikken naar de andere ingang voor SRM 1.2.5 werkt het weer direct.

Ben net bezig een support ticket aan te maken.

Maar met het hier schrijven van deze reactie en software versienummers VPN Client, krijg ik wel een extra idee.
Zal de vorige VPN Plus Client er eens op zetten. Geeft meteen inzicht of het misschien daar aan ligt?

EDIT:  Oudere VPN Client versie   1.4.4-0635_X64   geprobeerd - heeft dezelfde foutmelding voor SRM 1.3.1

https://archive.synology.com/download/Utility/VPNPlusClient

[Babylonia]

M.b.t.  SSL VPN    Ik ben eruit   -   opgelost !!
Hoewel het wel nodig is een support ticket in te sturen, want toch niet alles draait zoals het is bedoeld.

Enkele dagen terug heb ik wat zaken doorgenomen / getest m.b.t. VPN Plus server (voor verdere aanvulling handleiding RT6600ax).

Heb (voor mogelijk een schermafdruk?) daarbij  WebVPN  ingeschakeld.
Voor gebruik van dat  WebVPN  is wel een *wildcard* certificaat benodigd.  Dat is overigens al jaren zo !!
Maar heb erna dat  WebVPN  niet meer uitgeschakeld (en was dus nog actief).

Ondanks voor  WebVPN  expliciet een andere poort is ingesteld dan voor  SSL VPN.
En ik voor benadering naar het VPN portaal  de voor  SSL VPN  geldende poort invul,
wordt toch de login pagina methode voor  WebVPN  gebruikt.

Dat is inclusief die login prefix voor het domein:   https://login.[ NL domein ]:[ poort ]//webportal.cgi#/

Met uitschakelen van de  WebVPN  methode is de inlog via  SSL VPN  hersteld  =  zonder prefix.

Maar ja, er mag natuurlijk geen wisseling van een portaal login methode zijn bij verschillend gebruikte services en poorten.
Dus weer werk aan de winkel voor Synology.

De situatie van de twee VPN methoden (die alle twee een browser web-pagina portaal gebruiken):

         

[Birdy]

Bedankt maar weer voor het uitzoeken en testen .....zet ze maar weer aan het werk......

[Babylonia]

Kennelijk al een erg oude bug.   

Geprobeerd met  WebVPN  inschakelen onder  SRM 1.2.5   en ook daar komt hetzelfde probleem naar voren.
Terwijl de poort van  WebVPN  naar de 2e router waar ik nu gebruik van maak helemaal geen port forwarding heeft voor dat WebVPN.
Alleen  SSL VPN   (en andere VPN methoden).

Blijkbaar probeert niemand die twee VPN methoden naast elkaar uit door ze beide in te schakelen.
Anders was het beslist wel een keer door iemand te berde gebracht.

Maar ja, het is altijd de "gek" die het wel uitprobeert, om zo compleet mogelijk alle opties te doorgronden.      

[Briolet]

Alleen zie ik de noodzaak van een wildcard certificaat nog steeds niet.  Het subdomein is bekend en zelf in te stellen. Dan kun je toch ook gewoon een certificaat met dat subdomein gebruiken.

Ik heb stapels subdomeinen in gebruik (b.v. mail.domein.nl, smtp.domein.nl, dsm.domein.nl. etc) maar heb nog nooit een wildcard certificaat gebruikt.

NB: kun je dat prefix veld ook leeg laten?

[Briolet]

Ik ben nooit zo van dat 'wildcard" gedoe. Dat is vragen om een security issue omdat je dan plots elk subdomein geldig maakt.

Ik heb al voorbeelden van phishing mails gezien die daar misbruik van maken. b.v. *.legitiemesite.nl met een mooi spf protocol die specificeert wie mail mag versturen.

De phishers gebruikten vervolgens de gespoofde afzender "info@nep.legitiemesite.nl".  Dat is dan ook een legitiem adres en het opvragen van de spf geeft geen fout, alleen is er dan geen spf record. Deze gespoofde mail wordt door het ontbreken van een spf record op dit subdomein als authentiek aangemerkt.
Hier is wel tegen op te treden met een beter spf record op het hoofddomein, maar als je rondkijkt wordt dit meestal vergeten.

[Babylonia]

Alleen zie ik de noodzaak van een wildcard certificaat nog steeds niet.

Ik ben nooit zo van dat 'wildcard" gedoe. Dat is vragen om een security issue omdat je dan plots elk subdomein geldig maakt.

Daar ben ik het helemaal mee eens.  Maar zo werkt de  Synology WebVPN  methode nu eenmaal.
Het gaat daarbij niet zozeer om een sub-domein met de benaming  "login"  als prefix. Want die naam kun je veranderen.
(Het veld leeg laten wordt overigens niet geaccepteerd).

In een grijs verleden heb ik daar wel eens mee getest.
Door via een trucje even  www  als prefix in te vullen, in het  menu van WebVPN  waarmee ik dat stukje kon omzeilen,
omdat ik toen ook geen wildcard certificaat had.  www is een uitzondering.  Daarmee kon ik in ieder geval wel dat  WebVPN  activeren.
Van daaruit kon ik verder testen (en toen nog wel telkens uitzonderingen maken in de webbrowser bij elke stap verder).

Via die WebVPN methode worden er hele reeksen  "random" code  vóór een domeinnaam gezet,
als onderdeel van wellicht een beveiligingssleutel? (Zonder de juiste combinatie geen verbinding. Dus zo onveilig lijkt het niet te zijn).
Die wisselende codering als prefix, werkt alleen met een wildcard certificaat.

Vond dat WebVPN toen al geen interessante VPN methode.
(Men moest "per geopend tabblad" in een webbrowser controleren of de connectie via VPN of een normale internetverbinding liep).
Maar mag uiteraard niet verward worden met  SSL VPN,  een andere VPN methode.  Wat het nu wel doet als beide zijn geactiveerd.