Unroutable control packet / could not read Auth

[pven]

Ik heb al sinds ik OpenVPN op mijn DS410 gebruik last van dit probleem. Meestal connecteert ie, maar niet altijd. Het lijkt random te zijn. Uiteraard wil ik graag dat ie altijd connecteert.

In de logging van een gefaalde connectie staat het volgende (IP is gescrambled):

Code: [Selecteer]

Fri Apr 01 09:44:57 2016 OpenVPN 2.3.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Dec  1 2014
Fri Apr 01 09:44:57 2016 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
Enter Management Password:
Fri Apr 01 09:44:57 2016 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Fri Apr 01 09:44:58 2016 UDPv4 link local (bound): [undef]
Fri Apr 01 09:44:58 2016 UDPv4 link remote: [AF_INET]11.22.33.44:1194
Fri Apr 01 09:45:00 2016 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Apr 01 09:45:02 2016 [synology.com] Peer Connection Initiated with [AF_INET]11.22.33.44:1194
Fri Apr 01 09:45:04 2016 AUTH: Received control message: AUTH_FAILED
Fri Apr 01 09:45:04 2016 SIGUSR1[soft,auth-failure] received, process restarting
Fri Apr 01 09:45:06 2016 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Fri Apr 01 09:45:06 2016 UDPv4 link local (bound): [undef]
Fri Apr 01 09:45:06 2016 UDPv4 link remote: [AF_INET]11.22.33.44:1194
Fri Apr 01 09:45:06 2016 TLS Error: Unroutable control packet received from [AF_INET]11.22.33.44:1194 (si=3 op=P_CONTROL_V1)
Fri Apr 01 09:45:13 2016 [synology.com] Peer Connection Initiated with [AF_INET]11.22.33.44:1194
Fri Apr 01 09:45:15 2016 AUTH: Received control message: AUTH_FAILED
Fri Apr 01 09:45:15 2016 SIGUSR1[soft,auth-failure] received, process restarting
Fri Apr 01 09:45:17 2016 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Fri Apr 01 09:45:17 2016 UDPv4 link local (bound): [undef]
Fri Apr 01 09:45:17 2016 UDPv4 link remote: [AF_INET]11.22.33.44:1194
Fri Apr 01 09:45:17 2016 TLS Error: Unroutable control packet received from [AF_INET]11.22.33.44:1194 (si=3 op=P_CONTROL_V1)
Fri Apr 01 09:45:25 2016 ERROR: could not read Auth username/password/ok/string from management interface
Fri Apr 01 09:45:25 2016 Exiting due to fatal error

Iemand een idee wat er gaande is? Ik lees iets over het samenvoegen van certificaten / bestandjes, maar dat lijkt me pas van toepassing als het nooit werkt?

Kortom: help

[Pippin]

Controleer de tijd op alle betrokken apparaten, daar mag niet teveel verschil tussen zitten.
Indien mogelijk, gebruik op alle apparaten dezelfde tijd server.

Inline (samenvoegen) certificaten staat hier los van.

[pven]

Nu je het zegt: het is sinds dit weekend een stuk erger. Vanavond kijk ik er naar (ik kom nu helemaal niet bij mijn DS), en dan laat ik het hier weten. Dank!

[Briolet]

Ik heb net ook OpenVPN getest na de 6.0 update. In elk geval zie ik in het log dat hij nu een ander certificaat is gaan gebruiken, terwijl ik heel bewust daar niets veranderd heb op de nas.

Na het exporteren van het huidige certificaat en verbinden blijft hij tijdens de inlog ook hangen op:

Code: [Selecteer]

2016-04-02 22:31:24 TLS Error: Unroutable control packet received from [AF_INET]217.121.xxx.xxx:1194 (si=3 op=P_CONTROL_V1)
2016-04-02 22:31:24 TLS Error: Unroutable control packet received from [AF_INET]217.121.xxx.xxx:1194 (si=3 op=P_ACK_V1)

Edit: Ik was verbonden via IP 62.145.204.203. (De Ziggo WifiSpot). Het IP 217.121.xxx.xxx is het IP van de vpn server,

[Pippin]

Neem aan dat je de tijd tussen cliënt en server gecontroleerd hebt.
Het kan denk ik ook zijn dat men te snel na een mislukte poging probeert te verbinden.

Wat betreft het andere certificaat heb ik gelezen dat het nu mogelijk zou zijn om certificaten aan bepaalde Apps toe te wijzen, of iets in die trend. Vraag mij af of mijn "tot vervelend toe" mailtjes daaraan bijgedragen hebben 
Maar waar dat zit in de WebUI.....of in de App zelf...

[Briolet]

Misschien zit bij mij het probleem in het certificaat want ik vind ook in het log;

Code: [Selecteer]

2016-04-03 09:11:36 VERIFY ERROR: depth=0, error=unable to get local issuer certificate: C=NL, ST=Overijssel, L=xxx, O=xxx, CN=xxx.nl, emailAddress=info@xxx.nl
2016-04-03 09:11:36 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
2016-04-03 09:11:36 TLS Error: TLS object -> incoming plaintext read error
2016-04-03 09:11:36 TLS Error: TLS handshake failed

Dit is het certificaat dat ik zelf gemaakt heb voor al mijn nas functies gebruikte. Misschien dat hij een instelling mist om voor vpn gebruikt te kunnen worden. Voorheen had ik als test eens een certificaat gemaakt via de Synology site. (met de naam fake). Nadat ik echter mijn eigen certificaat terug geplaatst had, bleef hij dat certificaat van Synology voor vpn gebruiken. Dit certificaat was via de GUI niet zichtbaar.

Nu, met dsm 6.0, is dat Synology self-signed certificaat geheel weg en heeft dsm mijn eigen self-signed certificaat aan OpenVPN gekoppeld.

Ik zou nog eens het Let's Encrypt certificaat kunnen proberen, maar ben bang dat ik dan elke 8 week als het certificaat op de nas geupdate wordt, ook de config file met public key op mijn laptop moet aanpassen.

[Briolet]

Ik heb het certificaat nu op die van Let's Encrypt gezet en dan heb ik zo een OpenVPN verbinding. Zet ik het certificaat terug op mijn eigen certificaat, dan komen de foutmeldingen terug. Mijn eigen certificaat mist blijkbaar de optie om dit soort verbindingen te certificeren.

[Pippin]

Misschien zit bij mij het probleem in het certificaat

Daar lijkt het wel op afgaande op de log melding, een mismatch tussen server en client certificaat.

[Briolet]

Nu snap ik het helemaal niet meer, maar dat kan ook aan mijn cliënt liggen. (TunnelBlick)

Omdat het oude Synology certificaat wel werkte, heb ik nu weer een bij Synology aangemaakt. Ik zie dat je daar nu ook multidomein certificaten kunt aanmaken.

Als ik OpenVPN dit certificaat laat gebruiken, krijg ik dezelfde fouten als bij mijn eigen certificaat. Ik had een exportfile aangemaakt en de certificaten in mijn sleutelhanger geïmporteerd. In het log zie ik wel dat hij het Synology certificaat wil gebruiken.

Stel ik in DSM weer het Let's Encrypt certificaat in, werkt het weer. Nog vreemder: Met de settings die ik in mijn cliënt voor het Synology certificaat aangemaakt heb, verbind hij dan met het Let's Encrypt certificaat.

Ik heb een paar keer tussen certificaten gewisseld op de nas en tig keer een exportfile gemaakt. Alleen met het Let's Encrypt certificaat krijg ik de verbinding. (Ik zal nu eerst weer iets anders gaan doen, want ik kijk waarschijnlijk ergens overheen.)

[Pippin]

Heb geen DSM 6 maar wat ik lees is dat je aan moet geven dat OpenVPN het certificaat moet gebruiken.
Dat schijnt echter niet goed te werken:

The trouble is, it would still generate the cert based off the 3rd party cert and not the self-signed one, regardless of settings

https://forum.synology.com/enu/viewtopic.php?f=173&t=116453

[Briolet]

Interessant die link, maar niet volledig correct. Het was me wel opgevallen dat er twee certificaten geëxporteerd worden.

De een is: ca.crt Dat is het root certificaat dat je zelf aangemaakt hebt.
De andere is: ca_bundel.crt. Dat ding snapte ik niet, want dat is een root certificaat van "Digital Signature trust co" [Edit: Dit is het root certificaat dat door Let's Encrypt gebruikt wordt en had er dus niet mogen staan.]



De opvn config file wijst echter naar die ca_bundel.crt. Naar aanleiding van de link heb ik de config file aangepast zodat hij naar het 'ca.crt' certificaat wijst. Ik heb geen certificaat files vervangen. Na inladen van de configuratie werkte het nog steeds niet. Toen heb ik de VPN cliënt gestop en weer gestart. Weer de oude configuratie weggegooid en de nieuwe ingeladen.

En nu werkt het.

Dus mijn cliënt zorgde ook mede de problemen omdat hij volledig gestopt moest zijn voor de import van een configuratie. Als ik het echt wil weten moet ik het nog eens herhalen met de default export, na herstarten van mijn vpn cliënt.

[Briolet]

…Als ik het echt wil weten moet ik het nog eens herhalen met de default export, na herstarten van mijn vpn cliënt.

Ik heb het nog eens met de originele export file geprobeerd na opstarten van mijn vpn cliënt (TunnelBlick, laatste versie). Dat lukt niet. Het andere certificaat in de config file benoemen werkt wel. Dus het certificaat in de export klopt wel, maar de config wijst er niet naar toe.

[pven]

Controleer de tijd op alle betrokken apparaten, daar mag niet teveel verschil tussen zitten.
Indien mogelijk, gebruik op alle apparaten dezelfde tijd server.

Inline (samenvoegen) certificaten staat hier los van.

Op mijn laptop en DS410 is de tijd exact gelijk. Op mijn ADSL-modem heb ik volgens mij weinig invloed. Net probeer ik het overigens weer, en nu heb ik meteen connectie. Dit weekend heb ik het thuis via 4G ook geprobeerd, ook dan heb ik meteen connectie.

Maar het probleem treedt vaker op ...

[Pippin]

Kan het zijn dat de DS in slaapstand is de keren dat het mislukt?
Of misschien is op dat moment de DS te druk met iets anders.
Als laatste denk ik nog aan een hoge latency.

[Briolet]

Het probleem van het verkeerde certificaat in de export file heb ik als Ticket #789701 ingediend. Als antwoord kreeg ik vandaag de reactie:

This has been confirmed as a known issue and we will try to fix this issue in further DSM release.

Dit zal een probleem zijn van velen oplossen die een nieuwe OpenVPN configuratie maken via de export functie. Het is echter niet het probleem van TS.