OpenVPN - Kein Zugriff auf Geräte bei Verbindung zu NAS von Windows 10 PC (Anwendung Tunnelblick Mac funktioniert)

[SGE-2001]

Hallo,

ich habe ein Problem mit einer OpenVPN Verbindung, die ich mir nicht erklären kann.
Bevor ich ausführlich das Setup beschreibe versuche ich es mal mit einer kurzen Skizzierung des Aufbaus. Evtl. weiß ja sofort jemand, wo's hier hakt

1. Standort:

• Synology NAS, auf dem ein OpenVPN Server läuft.
• DSL-Anschluss mit öffentlicher IPv4 Adresse. IP des OpenVPN Netzes 10.22.22.0 (Synology NAS = 10.22.22.1)
• spdns.de Account

2. Standort

• VDSL-Anschluss ohne eigene, öffentliche IP (NAT)
• weiters Synology NAS, auf dem bei den Netzwerk-Einstellungen ein VPN-Profil konfiguriert ist
• Macbook mit Tunnelblick als VPN-Client
• Windows 10 PC mit OpenVPN als VPN Client

Über das Macbook sowie von dem Synology NAS lässt sich problemlos eine Verbindung herstellen und auf die Geräte am 1. Standort zugreifen.
Von dem Windows 10 PC verbindet sich der OpenVPN Client auch erfolgreich zum VPN-Server des NAS am 1. Standort.
Aber es ist kein Zugriff auf die Geräte am 1. Standort möglich (es soll auf die Konfigurationsoberfläche des NAS zugegriffen werden).
Auffällig ist auch, dass es von dem Windows 10 PC relativ lange dauert, bis die Verbindung hergestellt ist (ca. 40 Sekunden - auf dem MacBook geht es in ca. 10 Sekunden).

Die openvpn.ovpn Konfigurationsdatei von Tunnelblick am MacBook sowie von OpenVPN am Windows 10 PC ist genau die gleiche.


Ich vermute also irgendeine (Netzwerk)Konfiguration am Windows 10 PC als Grund für das Verhalten.
Hat hier jemand eine Idee, woran das liegen könnte? Fehlt hier evtl. irgend eine Route? Wobei das MacBook und das 2. Synology NAS ja auch keine benötigen...


sge-2001

 

[Raijin]

Es wäre hilfreich, wenn du uns das Verbindungs-Log sowie die server/client Config zeigst. Kompromittierende Details solltest du allerdings maskieren (zB öffentliche IPs bzw. dein DDNS). Lokale IPs bzw. etwaige Routen in der Config bitte so lassen, die stellen keine Gefahr dar, sind aber relevant für die Beurteilung.

 

[SGE-2001]

Ich bin nun einen Schritt weiter: Ich habe die ganze Zeit openVPN portable verwendet (Version 2.2.2; immer als Admin ausgeführt).
Damit besteht oben beschriebenes Verhalten. Mit dem normalen, also installierten openVPN Client (Version 2.4.6) hingegen funktioniert es einwandfrei.
Die ersten Zeilen im Log sind identisch. Bei der portable Version kommen dann irgendwann die unten angefügten Einträge.
Ich habe noch den Inhalt der openvpn.con-Datei des Clients angefügt.
Ist die Server-Config auch wichtig/ notwendig? An die komm ich momentan leider nicht dran da ich kein Zugriff auf das NAS habe.

Hat jemand eine Idee, warum es mit der portable nicht funktioniert?


Log openVPN portbale

Mon Oct 15 17:31:32 2018 Warning: route gateway is not reachable on any active network adapters: 10.22.22.5
 OK!
Mon Oct 15 17:31:32 2018 Warning: route gateway is not reachable on any active network adapters: 10.22.22.5
 OK!
SYSTEM ROUTING TABLE
0.0.0.0 0.0.0.0 192.168.22.254 p=0 i=10 t=4 pr=3 a=338671 h=0 m=25/0/0/0/0
10.22.22.0 255.255.255.0 10.22.22.5 p=0 i=10 t=4 pr=3 a=0 h=0 m=26/0/0/0/0
10.22.22.1 255.255.255.255 10.22.22.5 p=0 i=10 t=4 pr=3 a=0 h=0 m=26/0/0/0/0
127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=2 a=338677 h=0 m=331/0/0/0/0
127.0.0.1 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=338677 h=0 m=331/0/0/0/0
127.255.255.255 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=338677 h=0 m=331/0/0/0/0
192.168.22.0 255.255.255.0 192.168.22.20 p=0 i=10 t=3 pr=2 a=338671 h=0 m=281/0/0/0/0
192.168.22.20 255.255.255.255 192.168.22.20 p=0 i=10 t=3 pr=2 a=338671 h=0 m=281/0/0/0/0
192.168.22.255 255.255.255.255 192.168.22.20 p=0 i=10 t=3 pr=2 a=338671 h=0 m=281/0/0/0/0
224.0.0.0 240.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=2 a=338677 h=0 m=331/0/0/0/0
224.0.0.0 240.0.0.0 192.168.22.20 p=0 i=10 t=3 pr=2 a=338674 h=0 m=281/0/0/0/0
255.255.255.255 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=338677 h=0 m=331/0/0/0/0
255.255.255.255 255.255.255.255 192.168.22.20 p=0 i=10 t=3 pr=2 a=338674 h=0 m=281/0/0/0/0
SYSTEM ADAPTER LIST
Realtek PCIe GBE Family Controller
  Index = 10
  GUID = {hier_stand_die_GUID}
  IP = 192.168.22.20/255.255.255.0
  MAC = hier_stand_die_Mac-Adresse
  GATEWAY = 192.168.22.254/255.255.255.255
  DHCP SERV = 192.168.22.254/255.255.255.255
  DHCP LEASE OBTAINED = Mon Oct 15 17:17:40 2018
  DHCP LEASE EXPIRES  = Thu Jan 01 01:00:00 1970
  DNS SERV = 192.168.22.254/255.255.255.255
TAP-Win32 Adapter V9
  Index = 25
  GUID = {hier_stand_die_GUID}
  IP = 0.0.0.0/0.0.0.0
  MAC = hier_stand_die_Mac-Adresse
  GATEWAY = 0.0.0.0/255.255.255.255
  DHCP SERV = 
  DHCP LEASE OBTAINED = Mon Oct 15 17:31:32 2018
  DHCP LEASE EXPIRES  = Thu Jan 01 01:00:00 1970
  DNS SERV = 
Mon Oct 15 17:31:32 2018 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )

openvpn.con Client

dev tun
tls-client

hier_stand_die_dyndns_Adresse 1194

# The "float" tells OpenVPN to accept authenticated packets from any address,
# not only the address which was specified in the --remote option.
# This is useful when you are connecting to a peer which holds a dynamic address
# such as a dial-in user or DHCP client.
# (Please refer to the manual of OpenVPN for more information.)

#float

# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)

#redirect-gateway

# dhcp-option DNS: To set primary domain name server address.
# Repeat this option to set secondary DNS server addresses.

#dhcp-option DNS DNS_IP_ADDRESS

pull

# If you want to connect by Server's IPv6 address, you should use
# "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode
proto udp

script-security 2
ca ca.crt
comp-lzo
reneg-sec 0
auth-user-pass

 

[Raijin]

In Anbetracht dessen, dass sich der Client ganz offensichtlich alle verbindungsspezifischen Optionen "pull"t, ist die Server.conf entscheidend. Dort steht nämlich drin was in die pull-Anweisung des Clients ge"push"t wird. Zum Beispiel redirect-gateway.

Dennoch lässt sich dem Log zumindest im Ansatz entnehmen, dass besagtes Gateway eben nicht erreichbar ist. Das deutet darauf hin, dass mit der IP-Vergabe seitens des OpenVPN DHCP und/oder mit dem Routing etwas nicht stimmt. Das kann zB passieren, wenn der Server noch mit "topology net30" bzw gänzlich ohne topology läuft (net30=Standard). Dabei wird jeder Client mit dem Server in ein separates /30 Subnetz gepackt und der Server ist dann nicht mehr die x.y.z.1 und ist darüber dann auch nicht mehr als Gateway erreichbar. Empfohlen wird daher die Servereinstellung "topology subnet".

 

[SGE-2001]

Ich würde jetzt ungern versuchsweise an der Server Config was anpassen wollen, da ja dem Grunde nach alles läuft.
"Nur" mit der portable openVPN nicht. Demnach kann es ja an der Config eigentlich nicht liegen...
Hast du da vielleicht einen Tipp?

 

[Raijin]

Portable Versionen von Software, die zudem vergleichsweise tief ins Betriebssystem eingreifen muss - wie zB ein virtuelles Netzwerk - können durchaus an fehlenden Berechtigungen scheitern. Abgesehen davon, die portable Version explizit als Admin auszuführen, würde mir spontan nichts einfallen.

 

[SGE-2001]

Ok, danke für die ganzen Antworten.
Ich werde es dann erst mal bei dem installiertem openVPN Client belaassen.