Bug in laatste versie VPN Plus - 1.4.2-0533

[Babylonia]

Even een korte mededeling m.b.t. de   VPN Plus server   versie 1.4.2-0533   mocht je tegen onverklaarbare problemen oplopen.

Met een fix n.a.v. een eerder gevonden algemeen beveiligingsprobleem rondom "OpenSSL".
(Zie ook bericht op  Security.nl  en  vervolgberichten  m.b.t. OpenSSL),
is dat schijnbaar niet op alle punten goed bijgewerkt. Ik ondervind nu problemen onder het VPN "L2TP/IPSec" protocol.
(Nog geen problemen ondervonden met OpenVPN, en het Synology eigen SSL VPN).

Maar niet in alle gevallen.
Eigenlijk hoofdzakelijk als ik probeer als "VPN Client" onder "Android" met een smartphone connectie te leggen met de VPN-Plus server.
Maar er is verschil "rechtstreeks" (via de smartphone) of mogelijk indirect als tethered USB verbinding met Windows laptop of als WiFi hotspot.
Indirect via Windows (met verbinding op de WiFi hotspot) ervaar ik juist geen problemen.
(En in een andere setting dan ook weer "WEL" in combinatie als tethered USB verbinding met bijv. de Synology MR2200ac router).

En dat ook nog eens verschillend welk mobiel "APN toegangspunt" wordt gebruikt.  Daar waar dat eerder geen probleem vormde.
(Meer over APN toegangspunten zie o.a. de volgende reactie < HIER > ).

Die problemen zijn er weer NIET als ik verbind naar een "VPN server" geïnstalleerd op een NAS.
(Vandaar dat ik vooralsnog denk dat alleen VPN Plus ermee is begaan.
 Maar is uiteraard wel afhankelijk welke versie VPN-server op een NAS elders wordt gebruikt ?).

Wil dat eerst uitzoeken en in een schematisch overzicht uiteenzetten om beter inzicht te krijgen waar de problemen zitten.
Moet bijv. bij de verschillende VPN connecties naar elders eerst nalopen welke versie VPN servers op een NAS daar worden gebruikt.

[ EDIT ] ---> Elders bij de NAS onder DSM 6.2       (nog) VPN server - versie 1.3.13-2781   (per 5 oktober een jongere versie).
            ---> Nog een stuk ouder NAS onder DSM 5.0     VPN server - versie 1.2-2456

            Deze versies hebben dus geen problemen. Het lijkt dan vooral te zitten in de recente update m.b.t. "OpenSSL"
            die vooralsnog alleen nog bij de VPN Plus versie voor de Synology router is doorgevoerd.

De vraag komt daarbij ook naar boven of bepaalde services zoals "KPN als mobiele provider" en ook andere providers
inmiddels ook aanpassingen hebben gedaan in hun netwerk, om beveiligingsproblemen rondom "OpenSSL" op te lossen??

Dus nogal wat variabelen.      Maar goed, je bent gewaarschuwd. Ik kom er later uitgebreid op terug.
(Na het weekend of zo - heb ook nog een verjaardag van mijn dochter).

[ EDIT     2021-10-13]
Reeds hele reeksen aan testen gedaan.  Ben bezig (zeer uitgebreide) schema's op te zetten als algemene info.
De meeste gebruikers zullen er niet mee worden geconfronteerd, maar ironisch genoeg met name connecties onderling
tussen Synology routers, lopen tegen problemen aan met client / server verbindingen m.b.t. het L2TP/ IPSec VPN protocol.

[Babylonia]

Marathon VPN test:
Inmiddels een dag of 10 verder heb ik zaken grondig uitgezocht m.b.t. VPN
om erachter te komen wat wel of niet als mogelijke „bug“ opgevat zou kunnen worden.

Het is een soort van VPN „marathon“ test geworden, waarbij allerlei combinaties met diverse VPN methoden zijn uitgeprobeerd.
(Waaronder PPTP  -niet aan te bevelen door beperkte veiligheid, maar als "test"-,       L2TP/IPSec  -  OpenVPN  -  Synology SSL).
Bij elkaar zeker wel 40-50 VPN testen gedaan. (En nog eens opnieuw als ik tegen fouten aanliep).

               
Windows 10:                        OpenVPN Client                    Synology VPN Plus Client
                                             (oudere software versie)

               
Android (versie 11):                    VPN Client Pro                    Synology VPN Plus


MR2200ac router
SRM versie 1.2.5-8227-2

Of bij providers toevallig ook net wat aanpassingen zijn doorgevoerd m.b.t. OpenSSL, of dat er anderszins „tijdelijke“ storingen waren?
Heb inmiddels met VPN-connecties nu minder problemen opgemerkt als eerder.
En daar waar wel problemen waren/zijn, de vinger op de zere plek weten te vinden.

Echter zijn er nog steeds wel problemen.
Het betreft typisch een fout bij VPN connecties tussen de ene Synology router als „VPN Client“,
met een andere Synology router als „VPN (Plus) Server“ voor het L2TP/IPSec protocol.
En hetzelfde vanuit een Synology NAS als  „VPN Client“, met de router „VPN (Plus) Server“ (L2TP/IPSec).

Een aanwijsbaar probleem (bug) wat door Synology opgelost moet worden.
(Als jezelf die combinatie niet gebruikt zul je er weinig van merken bij gebruik van VPN naar een VPN Plus server toe).

Div. ingestelde VPN Clients in de MR2200ac router.  (Ook o.a. het niet aan te raden VPN - PPTP protocol even als test).
OpenVPN en PPTP als connectie naar mijn eigen thuis-server leveren geen probleem op, alleen L2TP/IPSec.



Gevoeligheid voor storingen m.b.t. VPN:
Bij het testen heb ik een aantal algemene zaken opgemerkt, die het vermelden waard zijn.

O.a. de gevoeligheid voor storingen „ergens“ in de hele keten van aan elkaar geknoopte connecties van Client naar Server.
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 systeemlaag / niveau plaats).  Zijn VPN-verbindingen relatief gezien instabiel,
komen moeizamer tot stand, of in mogelijke gevallen soms helemaal niet.

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.

Goede netwerkspullen gebruiken:
Gebruik goede kwaliteit kabels van een betrouwbare leverancier met "koperen" kerndraden en voldoende "twisting".
(Dat wil tegenwoordig nog wel eens van aluminium zijn met een dun laagje koper erover   --->   CCA ).
Bij zelf samenstellen, de juiste pluggen gebruiken (solid versus "stranded"), en controleren met een kabeltester.

Firmware:
Firmware / software versies kunnen bepalend zijn in wel of geen goede VPN afhandeling.
En dan niet alleen van het VPN-server package, maar ook het gebruikte systeem OS van PC of smartphone
welke eigen VPN Client mogelijkheden hebben ingebouwd.  Voor OpenVPN packages van verschillende leveranciers.
(Met inmiddels een update voor de Synology „NAS“ VPN-server versie 1.3.14-2782, zit daar ook een verbetering in).

Herstart apparaten:
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.  Voor een NAS „op afstand“ ben je meestal niet ter plekke.
(Heb NAS'sen via de ene VPN methode kunnen bereiken om te herstarten, waarna erna ook de andere VPN-methode weer werkt).

Mobiel APN toegangspunt:
Bij gebruik van een smartphone kan het gebruik van een meer uitgebreider APN toegangspunt,
de connectiemogelijkheden verruimen of gevoeligheid op storingen met VPN methoden beperken.
Bijv. bij het KPN mobiele netwerk kiezen voor  „advancedinternet“  tegenover  „internet“ (standaard)
lijkt toegeeflijker te zijn in het opbouwen van een VPN-connectie.
Houd er wel wel rekening mee dat  „advancedinternet“  een aanzienlijk hoger accuverbruik geeft.
(Na gebruik weer terugschakelen naar standaard „internet“).  Meer informatie zie o.a. < HIER >

Andere optie is om de instelling van het standaard gebruikte APN toegangspunt waarbij IPv4 en IPv6 is ingeschakeld,
de instelling aan te passen naar alleen gebruik van IPv4.


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


Verbinding schema’s van diverse internet connectie methoden en VPN-verbindingen:
Om beter inzicht te krijgen in de mogelijkheden (en onmogelijkheden). Hier een opsomming wat er zoal is uitgetest.

VPN Servers zijn geïnstalleerd op mijn eigen router (RT2600ac), en op Synology NAS’sen bij vrienden en familie
die gebruik maken van internetverbindingen bij verschillende providers.  (KPN, Ziggo, T-Mobile, Solcon).
En in een enkel geval een VPN-server op een "DrayTek Vigor 2865" router (achter een KPN glasvezel aansluiting).

VPN Clients op Smartphone (Android 11), Laptop met Windows 10, en mogelijkheden met Synology routers MR2200ac en RT1900ac.

Diverse VPN methoden, en connectie „ketens“:

- Via WiFi hotspot of thethered USB verbinding van een laptop met een smartphone.
  Om dan via het mobiele netwerk verbinding te hebben met internet naar een VPN-server naar elders of thuis.
  De VPN opgebouwd vanuit VPN Clients op de laptop. (Een redelijk vaak voorkomende werksituatie voor „onderweg“).

- Zelfstandige VPN opbouw vanuit een smartphone zelf (en dan via het mobiele netwerk).
  Toegepast hoofdzakelijk om data van thuis op de telefoon te bekijken / beluisteren.
  VPN Client op de smartphone NIET toepasbaar als VPN gateway voor aangekoppelde laptop’s (WiFi hotspot / tethered USB).
  Mensen die denken op die manier een VPN verbinding met een laptop op te bouwen grijpen mis.
  Die houden in dat geval een aparte „normale“ mobiele internetverbinding.
  (Tenzij je op de laptop ook weer een VPN Client inschakelt).  Voor VPN Gateway zie volgende optie hieronder.

- Via WiFi met een Synology MR2200ac router welke op zijn beurt weer is verbonden met een USB tethered smartphone.
  Als een soort van „meeneem“ draadloos mini netwerkje met router functies voor op reis / vakantie adres / camper / camping.
  -  Vanuit een VPN client individueel opgebouwd bijv. vanuit een laptop (en dan via de MR2200ac router).
  -  VPN Client op de MR2200ac als VPN gateway voor alle draadloze apparaten.

- MR2200ac als „2e“ router achter een bestaand netwerk  -NAT achter NAT-  glasvezel (elders).
  met vergelijkbare opties als net hiervoor beschreven voor wat betreft VPN, maar dan vanuit vast netwerk.
  -  Vanuit een VPN client individueel opgebouwd bijv. vanuit een laptop (en dan via de MR2200ac router).
  -  VPN Client op de MR2200ac als VPN gateway voor alle draadloze apparaten.

[Babylonia]

Het heeft even geduurd, (ben er ook niet dagelijks mee bezig), maar we zijn eruit m.b.t. de volgende situatie:

Echter zijn er nog steeds wel problemen.
Het betreft typisch een fout bij VPN connecties tussen de ene Synology router als „VPN Client“,
met een andere Synology router als „VPN (Plus) Server“ voor het L2TP/IPSec protocol.
En hetzelfde vanuit een Synology NAS als  „VPN Client“, met de router „VPN (Plus) Server“ (L2TP/IPSec).

Synology France:
Een zoektocht middels ingezonden ticket naar Synology Support.  Aanvankelijk met eerstelijns Support via Synology "France".

Om het probleem te tackelen door mezelf een ander voorstel aangediend dan aanvankelijk door Synology geopperd.
Waarbij Synology dezelfde weg bewandelt naar connectie naar mijn VPN-server, als wat ik hier zelf doe.
Dus vanuit een vergelijkbare set-up met VPN Client ingesteld op hun Synology routers (in Frankrijk) met VPN connectie naar mijn server.

Met vooraf aangemaakt extra gebruikers account  +  wachtwoord en voor de test aangepast "preshared key" voor het L2TP/IPSec protocol.

Daarmee kan support "dezelfde gebruikservaring opdoen".
En..... kwam niet als verrassing. Ook Synology aan dezelfde fouten die ik ook tref.  Dus een repeteerhaar probleem.
Vreemd was wel dat hij  (Laurent)  daarop ook ging testen naar vergelijkbare situaties met andere Synology routers.
En daarbij NIET op het probleem stuitte.
Hij vermoedde een afwijking door de (KPN) PPPoE aanmelding van mijn internetverbinding, terwijl die bij hun niet van toepassing is.
Maar kon er verder weinig advies in geven.  Het ticket werd doorgezet naar de echte jongens (meisjes) van Synology Support "Taiwan".

Synology Taiwan:
Kwam uiteindelijk uit bij "Jenny",  de dame waar ik vorig jaar en begin dit jaar intensief mee heb gecommuniceerd,
die als intermediair fungeerde voor de aanpassingen van de firmware om te komen tot een werkende KPN IPTV "routed mode" oplossing.
(Vandaar mogelijk de wat meer amicale begroeting in haar reacties).

Na opnieuw een gedegen test, uiteindelijk toch een betrekkelijk eenvoudige oplossing. (Dat is meestal als je de oplossing eenmaal weet).
Lange weg van uitzoeken omdat de oplossing binnen het "vaste" gegeven aan verbindingen geen consequente uitkomsten gaf,
in verbindingen opgezet via bijv. een VPN Client onder Windows, of dezelfde verbinding opgezet als Client met een Synology router.

Waar komt het uiteindelijk op neer?

Inlognamen en wachtwoorden van een gebruikers account waarbij een hekje  "#"  of   spatie " "   worden gebruikt,
werken NIET / geven géén positieve verbinding, via die specifieke L2TP/IPSec VPN verbinding,
vanuit de ene Synology router (of via het NAS DSM OS) gebruikt als VPN client,
als verbinding naar de VPN (Plus) server op een andere Synology router.

Bij alle andere VPN methoden werkt het WEL met die speciale karakters ingezet. Maar dat niet alleen !!
Ook als VPN Client met het L2TP/IPSec protocol vanuit een  Windows OS  of  Android OS  werkt het met die speciale karakters.
En bij alle andere inlog methode zoals via het SRM web management, WebDAV, en SMB File Station.

Of Synology daar nog iets op kan aanpassen in volgende firmware moeten we maar even afwachten?



Nog wat uitgebreider getest, blijkt dat het gebruik van die speciale karakters met hekje  "#"  of   spatie " "
gebruikt in de "preshared key" voor het L2TP/IPSec protocol dan weer WEL kan.
(Niet in gebruikersnaam / wachtwoord, maar wel in die "preshared key" = extra verbindingssleutel).

Normaal in wachtwoorden of preshared keys gebruik ik geen spaties (wel bij gebruikersnamen),
maar typisch zo'n hekje "#" is nu net datgene wat ik eigenlijk al vele jaren gebruik in wachtwoorden.
(Vandaar dat het juist mij overkomt om dat dan op te merken als kennelijk een niet goed werkend karakter bij VPN         ).

In ieder geval wel hele specifieke gebruiksmethoden / aanpassingen om te onthouden mocht je vergelijkbare problemen tegenkomen.

[Bobo]

Knap stukkie werk 

[Birdy]

Heb je weer goed gedaan, samen met Synology 

[Babylonia]

Het is schijnbaar toch niet een echt algemeen bekend fenomeen, ook niet bij Synology zelf, want met die speciale karakters,
de Synology Support medewerker in Frankrijk, die de gebruikersgegevens van mijzelf heeft gekregen voor zijn test account,
inclusief die speciale karakters, had het niet opgemerkt.

(Moet de oplossing nog wel netjes vertalen naar het Engels en doorsturen.  Hebben we nog het weekend voor).

[Birdy]

Het is schijnbaar toch niet een echt algemeen bekend fenomeen, ook niet bij Synology zelf, want met die speciale karakters,

Van Synology Taiwan kan ik het enigszins  wel begrijpen, maar Frankrijk?

[Babylonia]

Synology Taiwan benoemt specifiek een hekje en spatie als uitzondering,
maar adviseert bijv. wel het dollar teken  $  (USA Engels karakter).
Zelf gebruik ik bijv. ook     !    @    -    _

Maar heb het niet uitgeprobeerd of in Frankrijk gebruikte karakters zoals  é  -  è  -  ê  -  à  -  ç   dan wel zouden werken?
Als die dan typisch misschien wel zouden werken, valt het niet werken van een hekje eigenlijk niet op?

[aliazzz]

Mijns inziens zou elk UTF8 of UTF16 karakters geldig moeten zijn in een password 

open deurtje ;-)

[Babylonia]

Waarom denk je dat ik met Synology Support contact heb over deze kwestie?   

Maar afgezien of je wel of niet vindt dat elk karakter vanuit een karakterset gebruikt zou moeten kunnen worden,
kan ik me wel voorstellen dat voor bepaalde processen dat niet altijd goed haalbaar is om te implementeren of zelfs wenselijk zou zijn.
Diverse karakters worden binnen een programmeertaal vaak ingezet als aanzet voor het starten van een heel andere functie.
Die karakters zullen programmeurs het liefst willen mijden in dit soort situaties.
Het is vaak een bron van fouten en onstabiliteit bij de minste storing binnen een netwerkproces als je die juist "wel" gaat gebruiken.
Het kan dan juist aanleiding zijn tot systeemfouten op heel ander gebied, omdat iets wordt opgevat als een ander te starten functie.

Heb dat soort verdergaande consequenties bij vergelijkbare andere situaties wel vaker gezien.
     (o.a. bij een NAS, een "Apple gebruiker" die  t/m  in naamgeving van mapjes zette,
     waarbij met storing in de connectie dat schuine / streepje werd opgevat als "deelstreepje" van mapjes van een directory,
     waardoor die hele directory indeling anders werd opgepakt).

Dan kun je beter dat soort risico's vermijden en een aantal restricties inbouwen omwille van de stabiliteit,
dan proberen tot in den treure alle karakters wel te willen ondersteunen, met toenemende onbetrouwbaarheid als consequentie.
Dat mogelijk ook nog eens afgezet tegen wellicht slechts een handjevol mensen die het misschien zouden gaan inzetten?

Verder zit men ook vast aan reeds lang in gebruik zijnde specificaties / protocollen van netwerksystemen van bestaande interventies.
Systemen die door andere ontwikkelaars / leveranciers worden aangeleverd.  OpenVPN is een heel andere insteek als bijv. L2TP/IPSec.

Het is om die reden niet ongebruikelijk om slechts een aantal speciale karakters toe te staan.
Die beperkingen ziet men vaak genoeg in handleidingen van apparaten, toegang van accounts etc. vernoemd.


Aanvullende test n.a.v. de eerdere bevindingen:

Nu heb ik toevallig net wat verder aanvullende testen afgesloten, welke speciale karakters dan wel of niet gebruikt kunnen worden.
Uitgangspunt is een in Nederland gebruikelijk toetsenbord (Qwerty met US toetsenbord indeling).


Situatie VPN Client vanuit de ene Synology router, naar de VPN Plus server op andere Synology router:

Als "wachtwoord" voor een gebruikers account, met werkende L2TP/IPSec VPN verbinding op de wijze zoals eerder vernoemd,
kan de volgende "geteste" reeks worden ingezet. (Eveneens getest voor de VPN protocollen OpenVPN en PPTP waar het ook mee werkt).

Alfanumeriek van A t/m Z  (a t/m z)  +  0 t/m 9     verder de volgende karakters (die op het toetsenbord zijn te vinden):

          123AbC_`~!@$%^&()-+?{}[]|;:<>,./

Speciale karakters welke (nu) NIET kunnen worden ingezet voor L2TP/IPSec.:        spatie   en de karakters   # \ ' "

Verder ook géén taal afhankelijke karakters zoals in mijn vorige reactie aangehaald:      é  -  è  -  ê  -  à  -  ç

Typische bij de L2TP/IPSec VPN protocol in te zetten extra "preshared key" als extra wachtwoord.
Is wel veel ruimer in te zetten. Heb daar enkele aanvullende karakter testen mee gedaan.

Buiten de eerder hiervoor genoemde reeks voor het "gewone" wachtwoord:

          123AbC_`~!@$%^&()-+?{}[]|;:<>,./

Kunnen tevens daarbij wel die Franse taal afhankelijke karakters gebruikt worden. Getest met:

          é  è  ê  à  ç     daarnaast een willekeurige reeks:   ¼  ½  ¾  æ  ß  ©  ®  ¢  £  ¥

Gaat me te ver om alle andere mogelijkheden daarin uit te proberen. Dat mogen gebruikers zelf doen. 


Situatie VPN Client vanuit Windows10 naar de VPN Plus server op de Synology router:  (Met het L2TP/IPSec protocol).

Voor het wachtwoord van de gebruikersnaam gelden daarbij géén restricties m.b.t.    spatie   en de karakters   # \ ' "
De volledige reeks aan karakters te vinden op een Qwerty US toetsenbord kan worden ingezet:

          123AbC_`~!@$%^&()-+?{}[]|;:<>,./ #\' "

Eveneens positief resultaat met:

          123AbC éèêàç      en      123AbC ¼½¾æß©®¢£¥


Slot evaluatie:
Die verschillen in mogelijk te gebruiken karakters, welke wel, welke niet, en verwarring die het kan opleveren,
is doorgegeven aan het achterliggende ontwikkelteam bij Synology voor verdere discussie / evaluatie.
Het is afwachten wat ze met deze info dan verder gaan doen.