Hallo,
zunächst versuche ich mein Problem mal zusammenzufassen:
Der OpenVPN-Server läuft auf unserer DS1817 (yay!), einige Clients (darunter ich selbst) können sich auch problemlos verbinden, bei einigen scheitert der TLS handshake jedoch. Mögliche Fehlerquellen sehe ich in Folgendem: Alle Nutzer bei denen es nicht klappt...
1) ... sind bei der Telekom (irgendwelche Provider-Vorgänge, die VPN-Verbindungen unterbinden?)
2) ... haben (neben IPv4) auch eine IPv6 (über die scheinbar das erste Paket gesendet wird)
3) ... haben einen Speedport als Router (vielleicht irgendwelche Firewall-Einstellungen Client-seitig?)
Ich vermute also dass mögliche Wege zur Lösung folgende wären:
1) aktive Unterstützung der Kontaktaufnahme per IPv6 (hier habe ich das Problem, dass unser Netzwerk hinter einem LANCOM-Router und einer Gateprotect-Firewall sitzt, da fummel ich extrem ungerne rum, aber wenn hier die einzige Lösung sitzt muss ich wohl, bisher werden keine Präfixe bereitgehalten.)
2) dem Client ausschließlich IPv4 zur Vebindung vorschreiben und hoffen, dass das auch von Telekom-/Speedport-Seite so umgesetzt wird (...?)
3) ...? Alle Client-Router zu konfigurieren würde ich als letztes erwägen...
Ich habe schon einiges versucht per SSH in der Config-Datei rumzuschreiben, bis mir irgendwann (dank eines anderen Posts in diesem Forum) aufgefallen ist, dass es (mindestens) zwei Orte mit einer openvpn.conf-Datei auf der DS gibt, in dem bis dato für mich unbekannten Ort sogar noch eine server.conf... Da aber meine Änderungen in der Datei /var/packages/VPNCenter/etc/openvpn/openvpn.conf zum Beispiel dazu geführt haben, dass ich eine log-Datei erstellen konnte, die zuvor nicht generiert wurde, gehe ich davon aus, dass das die richtige ist.
Daraus ergibt sich meine erste Zwischenfrage: Ist das so? Und was haben die beiden Dateien /var/packages/VPNCenter/target/etc/openvpn/openvpn.conf und /.../server.conf für eine Bewandnis?
Wenn diese Zwischenfrage mit "ja, nee, ist schon die richtige Datei" beantwortet werden kann, ergibt sich die Hauptfrage:
Kann jemand an den folgenden conf- und log-Dateien einen exakten oder zumindest wahrscheinlichen Grund für den Fehler finden?
CLIENT openvpn.conf:
Die Zeile proto udp4 stand zuvor auf proto udp, hat aber augenscheinlich nichts geändert
SERVER openvpn.conf
SERVER /var/log/openvpn.log
Wie bereits erwähnt läuft die Verbindung super für drei Clients. Derzeit sind zwei davon glücklich verbunden
. Das Zertifikat und die client openvpn.conf ist für alle gleich.
Noch eine Seitenfrage: bedeutet das TLS: Initial packet from [AF_INET6], dass – wie ich bisher annehme – die erste Kontaktaufnahme mit einer IPv6 erfolgt? Die Adresse nach ::ffff ist nämlich eine "normale" IPv4...
Ich wäre für sachdienliche Hinweise höchst dankbar!
EDIT (aka DISCLAIMER):
Ich hatte diese Frage mit einem etwas älteren Wissenstand auch schon hier geposted, da ich es aber inzwischen für wahrscheinlich halte, dass es auch etwas mit der scheinbar Synology-sepzifischen Fehlermeldung SYNO_ERR_CERT zu tun haben kann, würde ich euch gern zu Rate hinzuziehen.
EDIT2:
Inzwischen hat mir einer der Nutzer einen Auszug des Client-logs geschickt, falls der hilft füge ich ihn mal hier ein:
Das ist zwar nicht der selbe Versuch wie der, der oben im server log dargestellt ist, die beiden Vorgänge scheinen aber identisch im server log zu sein.
zunächst versuche ich mein Problem mal zusammenzufassen:
Der OpenVPN-Server läuft auf unserer DS1817 (yay!), einige Clients (darunter ich selbst) können sich auch problemlos verbinden, bei einigen scheitert der TLS handshake jedoch. Mögliche Fehlerquellen sehe ich in Folgendem: Alle Nutzer bei denen es nicht klappt...
1) ... sind bei der Telekom (irgendwelche Provider-Vorgänge, die VPN-Verbindungen unterbinden?)
2) ... haben (neben IPv4) auch eine IPv6 (über die scheinbar das erste Paket gesendet wird)
3) ... haben einen Speedport als Router (vielleicht irgendwelche Firewall-Einstellungen Client-seitig?)
Ich vermute also dass mögliche Wege zur Lösung folgende wären:
1) aktive Unterstützung der Kontaktaufnahme per IPv6 (hier habe ich das Problem, dass unser Netzwerk hinter einem LANCOM-Router und einer Gateprotect-Firewall sitzt, da fummel ich extrem ungerne rum, aber wenn hier die einzige Lösung sitzt muss ich wohl, bisher werden keine Präfixe bereitgehalten.)
2) dem Client ausschließlich IPv4 zur Vebindung vorschreiben und hoffen, dass das auch von Telekom-/Speedport-Seite so umgesetzt wird (...?)
3) ...? Alle Client-Router zu konfigurieren würde ich als letztes erwägen...
Ich habe schon einiges versucht per SSH in der Config-Datei rumzuschreiben, bis mir irgendwann (dank eines anderen Posts in diesem Forum) aufgefallen ist, dass es (mindestens) zwei Orte mit einer openvpn.conf-Datei auf der DS gibt, in dem bis dato für mich unbekannten Ort sogar noch eine server.conf... Da aber meine Änderungen in der Datei /var/packages/VPNCenter/etc/openvpn/openvpn.conf zum Beispiel dazu geführt haben, dass ich eine log-Datei erstellen konnte, die zuvor nicht generiert wurde, gehe ich davon aus, dass das die richtige ist.
Daraus ergibt sich meine erste Zwischenfrage: Ist das so? Und was haben die beiden Dateien /var/packages/VPNCenter/target/etc/openvpn/openvpn.conf und /.../server.conf für eine Bewandnis?
Wenn diese Zwischenfrage mit "ja, nee, ist schon die richtige Datei" beantwortet werden kann, ergibt sich die Hauptfrage:
Kann jemand an den folgenden conf- und log-Dateien einen exakten oder zumindest wahrscheinlichen Grund für den Fehler finden?
CLIENT openvpn.conf:
Rich (BBCode):
dev tun
tls-client
remote xxx.xxx.xxx.xxx 1194
float
pull
proto udp4
script-security 2
comp-lzo
reneg-sec 0
cipher AES-256-CBC
auth SHA512
auth-user-pass
<ca>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</ca>SERVER openvpn.conf
Rich (BBCode):
push "route 10.8.0.0 255.255.255.0"
dev tun
management 127.0.0.1 1195
server 10.8.0.0 255.255.255.0
dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key
max-clients 10
comp-lzo
persist-tun
persist-key
verb 4
log-append /var/log/openvpn.log
keepalive 10 60
reneg-sec 0
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn
status /tmp/ovpn_status_2_result 30
status-version 2
proto udp
port 1194
cipher AES-256-CBC
auth SHA512SERVER /var/log/openvpn.log
Rich (BBCode):
Fri Apr 3 11:12:55 2020 us=776692 ::ffff:xxx.xxx.xxx.xxx(42780) Re-using SSL/TLS context
Fri Apr 3 11:12:55 2020 us=776734 ::ffff:xxx.xxx.xxx.xxx(42780) LZO compression initialized
Fri Apr 3 11:12:55 2020 us=776875 ::ffff:xxx.xxx.xxx.xxx(42780) Control Channel MTU parms [ L:1602 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Fri Apr 3 11:12:55 2020 us=776907 ::ffff:xxx.xxx.xxx.xxx(42780) Data Channel MTU parms [ L:1602 D:1450 EF:102 EB:143 ET:0 EL:3 AF:3/1 ]
Fri Apr 3 11:12:55 2020 us=776962 ::ffff:xxx.xxx.xxx.xxx(42780) Local Options String: 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server'
Fri Apr 3 11:12:55 2020 us=776989 ::ffff:xxx.xxx.xxx.xxx(42780) Expected Remote Options String: 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
Fri Apr 3 11:12:55 2020 us=777053 ::ffff:xxx.xxx.xxx.xxx(42780) Local Options hash (VER=V4): 'aaa173e3'
Fri Apr 3 11:12:55 2020 us=777091 ::ffff:xxx.xxx.xxx.xxx(42780) Expected Remote Options hash (VER=V4): '9c102b00'
Fri Apr 3 11:12:55 2020 us=777155 ::ffff:xxx.xxx.xxx.xxx(42780) TLS: Initial packet from [AF_INET6]::ffff:xxx.xxx.xxx.xxx:42780, sid=12121212 12121212
Fri Apr 3 11:13:55 2020 us=509451 ::ffff:xxx.xxx.xxx.xxx(42780) TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Apr 3 11:13:55 2020 us=512363 ::ffff:xxx.xxx.xxx.xxx(42780) SYNO_ERR_CERT
Fri Apr 3 11:13:55 2020 us=512426 ::ffff:xxx.xxx.xxx.xxx(42780) TLS Error: TLS handshake failed
Fri Apr 3 11:13:55 2020 us=512564 ::ffff:xxx.xxx.xxx.xxx(42780) SIGUSR1[soft,tls-error] received, client-instance restartingWie bereits erwähnt läuft die Verbindung super für drei Clients. Derzeit sind zwei davon glücklich verbunden
. Das Zertifikat und die client openvpn.conf ist für alle gleich.Noch eine Seitenfrage: bedeutet das TLS: Initial packet from [AF_INET6], dass – wie ich bisher annehme – die erste Kontaktaufnahme mit einer IPv6 erfolgt? Die Adresse nach ::ffff ist nämlich eine "normale" IPv4...
Ich wäre für sachdienliche Hinweise höchst dankbar!
EDIT (aka DISCLAIMER):
Ich hatte diese Frage mit einem etwas älteren Wissenstand auch schon hier geposted, da ich es aber inzwischen für wahrscheinlich halte, dass es auch etwas mit der scheinbar Synology-sepzifischen Fehlermeldung SYNO_ERR_CERT zu tun haben kann, würde ich euch gern zu Rate hinzuziehen.
EDIT2:
Inzwischen hat mir einer der Nutzer einen Auszug des Client-logs geschickt, falls der hilft füge ich ihn mal hier ein:
Rich (BBCode):
Fri Apr 03 11:33:58 2020 WARNING: No server certificate verification method has been enabled. See [...]
Fri Apr 03 11:33:58 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194
Fri Apr 03 11:33:58 2020 UDPv4 link local (bound): [AF_INET][undef]:1194
Fri Apr 03 11:33:58 2020 UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Fri Apr 03 11:34:58 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connection)
Fri Apr 03 11:34:58 2020 TLS Error: TLS handshake failed
Fri Apr 03 11:34:58 2020 SIGUSR1[soft,tls-error]received, process restartingDas ist zwar nicht der selbe Versuch wie der, der oben im server log dargestellt ist, die beiden Vorgänge scheinen aber identisch im server log zu sein.
Zuletzt bearbeitet:
