31.05.2019, aktualisiert am 03.06.2019

4309

OpenVPN Konfiguration PING und Freigaben antworten

Servus Zusammen -

Derzeit probiere ich mich an OpenVPN heran und muss immer an einer Stelle den Dienst quittieren, egal mit welcher Konfirmation der Server gestartet wird:

Die Verbindung wird am Client aufgebaut (grün), dies wird auch am Server verzeichnet.
Dann: keine Daten werden ausgetauscht.
Der Ping auf einen Server (x.y.0.2) oder auch auf den VPN (x.y.0.33) wird damit beendet:

Für mich stellt sich die Frage, wo ich einen Denkfehler habe?

Anbei ein paar Auszüge:

local 192.168.0.33
port 1194
proto udp
dev tap

dh "C:\\Program Files\\OpenVPN\\server-keys\\dh2048.pem"  
ca "C:\\Program Files\\OpenVPN\\server-keys\\ca.crt"  
cert "C:\\Program Files\\OpenVPN\\server-keys\\server.crt"  
key "C:\\Program Files\\OpenVPN\\server-keys\\server.key"  


ifconfig-pool-persist "C:\\Program Files\\OpenVPN\\ipp.txt"  
client-to-client

client-config-dir "C:\\Program Files\\OpenVPN\\ccd"  
push "route 192.168.0.0 255.255.255.0"  
push "dhcp-option DNS 192.168.0.1"  

keepalive 10 120
comp-lzo
persist-key
persist-tun

server 192.168.10.0 255.255.255.0 #Subnetz
ifconfig-pool-persist ipp.txt


#client-to-client
#server-bridge

mode server


status "C:\\Program Files\\OpenVPN\\log\\openvpn-status.log"  
log "C:\\Program Files\\OpenVPN\\log\\openvpn.log"  
log-append "C:\\Program Files\\OpenVPN\\log\\openvpn.log"  
verb 3

C:\Users\USER>route print
===========================================================================
Schnittstellenliste
 28...00 ff 1c 78 a8 14 ......TAP-Windows Adapter V9
 17...c0 f8 da 9e a5 c7 ......Microsoft Virtual WiFi Miniport Adapter
 12...c0 f8 da 9e a5 c7 ......Broadcom 802.11n-Netzwerkadapter
 10...20 6a 8a 43 dd 1d ......Broadcom NetXtreme Gigabit Ethernet
  1...........................Software Loopback Interface 1
 11...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 18...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #2
 27...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter
 20...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #3
 31...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #4
 51...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #5
 33...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #6
 34...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #7
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0     192.168.11.1    192.168.11.66     25
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      192.168.0.0    255.255.255.0     192.168.10.1     192.168.10.3     11
     192.168.10.0    255.255.255.0   Auf Verbindung      192.168.10.3    266
     192.168.10.3  255.255.255.255   Auf Verbindung      192.168.10.3    266
   192.168.10.255  255.255.255.255   Auf Verbindung      192.168.10.3    266
     192.168.11.0    255.255.255.0   Auf Verbindung     192.168.11.66    281
    192.168.11.66  255.255.255.255   Auf Verbindung     192.168.11.66    281
   192.168.11.255  255.255.255.255   Auf Verbindung     192.168.11.66    281
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.10.3    265
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.11.66    281
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.10.3    266
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.11.66    281
===========================================================================
Ständige Routen:
  Keine

C:\Users\USER>ping 192.168.0.2

Ping wird ausgeführt für 192.168.0.2 mit 32 Bytes Daten:
Antwort von 62.155.242.200: Zielnetz nicht erreichbar.
Antwort von 62.155.242.200: Zielnetz nicht erreichbar.
Antwort von 62.155.242.200: Zielnetz nicht erreichbar.
Antwort von 62.155.242.200: Zielnetz nicht erreichbar.

Ping-Statistik für 192.168.0.2:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust)

Fri May 31 13:51:32 2019 OpenVPN 2.4.7 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Fri May 31 13:51:32 2019 Windows version 6.1 (Windows 7) 32bit
Fri May 31 13:51:32 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Enter Management Password:
Fri May 31 13:51:32 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri May 31 13:51:32 2019 Need hold release from management interface, waiting...
Fri May 31 13:51:32 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri May 31 13:51:32 2019 MANAGEMENT: CMD 'state on'  
Fri May 31 13:51:32 2019 MANAGEMENT: CMD 'log all on'  
Fri May 31 13:51:32 2019 MANAGEMENT: CMD 'echo all on'  
Fri May 31 13:51:32 2019 MANAGEMENT: CMD 'bytecount 5'  
Fri May 31 13:51:32 2019 MANAGEMENT: CMD 'hold off'  
Fri May 31 13:51:32 2019 MANAGEMENT: CMD 'hold release'  
Fri May 31 13:51:32 2019 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Fri May 31 13:51:32 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]{extern}:1194
Fri May 31 13:51:32 2019 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri May 31 13:51:32 2019 UDP link local: (not bound)
Fri May 31 13:51:32 2019 UDP link remote: [AF_INET]{extern}:1194
Fri May 31 13:51:32 2019 MANAGEMENT: >STATE:1559303492,WAIT,,,,,,
Fri May 31 13:51:32 2019 MANAGEMENT: >STATE:1559303492,AUTH,,,,,,
Fri May 31 13:51:32 2019 TLS: Initial packet from [AF_INET]{extern}:1194, sid=29a718fa ec8df4f4
Fri May 31 13:51:33 2019 VERIFY OK: depth=1, C=DE, ST=NW, L=xyz, O=xyz GmbH, OU=IT-Connections, CN=xyz.de, name=xyz GmbH OpenVPN, emailAddress=vpn@xyzde
Fri May 31 13:51:33 2019 VERIFY OK: depth=0, C=DE, ST=NW, L=xyz, O=xyz GmbH, OU=IT-Connections, CN=xyz.de, name=xyz GmbH OpenVPN, emailAddress=vpn@xyzde
Fri May 31 13:51:33 2019 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1573', remote='link-mtu 1574'  
Fri May 31 13:51:33 2019 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'  
Fri May 31 13:51:33 2019 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Fri May 31 13:51:33 2019 [xyz.de] Peer Connection Initiated with [AF_INET]{extern}:1194
Fri May 31 13:51:34 2019 MANAGEMENT: >STATE:1559303494,GET_CONFIG,,,,,,
Fri May 31 13:51:34 2019 SENT CONTROL [xyz.de]: 'PUSH_REQUEST' (status=1)  
Fri May 31 13:51:34 2019 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,dhcp-option DNS 192.168.0.1,route-gateway 192.168.10.1,ping 10,ping-restart 120,ifconfig 192.168.10.3 255.255.255.0,peer-id 0,cipher AES-256-GCM'  
Fri May 31 13:51:34 2019 OPTIONS IMPORT: timers and/or timeouts modified
Fri May 31 13:51:34 2019 OPTIONS IMPORT: --ifconfig/up options modified
Fri May 31 13:51:34 2019 OPTIONS IMPORT: route options modified
Fri May 31 13:51:34 2019 OPTIONS IMPORT: route-related options modified
Fri May 31 13:51:34 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri May 31 13:51:34 2019 OPTIONS IMPORT: peer-id set
Fri May 31 13:51:34 2019 OPTIONS IMPORT: adjusting link_mtu to 1656
Fri May 31 13:51:34 2019 OPTIONS IMPORT: data channel crypto options modified
Fri May 31 13:51:34 2019 Data Channel: using negotiated cipher 'AES-256-GCM'  
Fri May 31 13:51:34 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Fri May 31 13:51:34 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Fri May 31 13:51:34 2019 interactive service msg_channel=0
Fri May 31 13:51:34 2019 ROUTE_GATEWAY 192.168.0.225/255.255.255.255 I=32 HWADDR=00:00:00:00:00:00
Fri May 31 13:51:34 2019 open_tun
Fri May 31 13:51:34 2019 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{1C78A814-E26B-4CB1-AE4D-CF599993C180}.tap
Fri May 31 13:51:34 2019 TAP-Windows Driver Version 9.23 
Fri May 31 13:51:34 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.10.3/255.255.255.0 on interface {1C78A814-E26B-4CB1-AE4D-CF599993C180} [DHCP-serv: 192.168.10.0, lease-time: 31536000]
Fri May 31 13:51:34 2019 Successful ARP Flush on interface [28] {1C78A814-E26B-4CB1-AE4D-CF599993C180}
Fri May 31 13:51:34 2019 MANAGEMENT: >STATE:1559303494,ASSIGN_IP,,192.168.10.3,,,,
Fri May 31 13:51:39 2019 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Fri May 31 13:51:39 2019 MANAGEMENT: >STATE:1559303499,ADD_ROUTES,,,,,,
Fri May 31 13:51:39 2019 C:\Windows\system32\route.exe ADD 192.168.0.0 MASK 255.255.255.0 192.168.10.1
Fri May 31 13:51:39 2019 ROUTE: route addition failed using CreateIpForwardEntry: Ein oder mehrere Argumente sind ungültig.   [status=160 if_index=28]
Fri May 31 13:51:39 2019 Route addition via IPAPI failed [adaptive]
Fri May 31 13:51:39 2019 Route addition fallback to route.exe
Fri May 31 13:51:39 2019 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem
Fri May 31 13:51:39 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri May 31 13:51:39 2019 Initialization Sequence Completed
Fri May 31 13:51:39 2019 MANAGEMENT: >STATE:1559303499,CONNECTED,SUCCESS,192.168.10.3,{extern},1194,,

siehe sonst auch:
OpenVPN - Ethernet-Tunnel - VERIFY ERROR...

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 457456

Url: https://administrator.de/contentid/457456

Ausgedruckt am: 22.11.2024 um 04:11 Uhr

13 Kommentare

Neuester Kommentar

Hallo,

Zitat von @Midivirus:
egal mit welcher Konfirmation der Server gestartet wird:

Da ein VPN nichts mit Konfirmation zu tun hat, oder ein Geistliches VPN is, meinst du sicherlich Konfiguration, oder?

Der Ping auf einen Server (x.y.0.2) oder auch auf den VPN (x.y.0.33) wird damit beendet:

Wenn du hier versuchst deine Privaten IPs (Millionen anderer nutzen die auch) zu verschleiern, mach das bitte auch in den Weitere Verlauf, obwohl fast jeder sich für x= 192 und y=168 wérwärmen könnte.
https://de.wikipedia.org/wiki/Private_IP-Adresse
https://simple.wikipedia.org/wiki/Private_network

local 192.168.0.33

Wohl doch keine x.y.0.33

Ping wird ausgeführt für 192.168.0.2 mit 32 Bytes Daten:
Antwort von 62.155.242.200: Zielnetz nicht erreichbar.

Dein Ping wird ins Internet weitergeleitet. Konfiguration. Oder betreibs du Geräte im 62.155.242.xy/xy Netz? Gibt es weitere Router?

Gruß,
Peter

Die Verbindung wird am Client aufgebaut (grün), dies wird auch am Server verzeichnet.

Ahem...eine Binsenweisheit ! Sinnfrei sowas in einem Administrator Forum zu betonen. Jedem Netzwerk Admin ist das klar.

Das ist also völlig normal oder dachtest du das der Server die Verbindung zum Client initiiert, sprich also das Pferd von hinten aufzäumt ?!!

Dann: keine Daten werden ausgetauscht.

Warum auch ?? Wenn du keine Daten für die andere Seite generierst die über den Tunnel laufen werden logischerweise auch keine ausgetauscht. Auch das ist also völlig normal.
Wo ist denn nun dein wirkliches Problem ??

Der Ping auf einen Server (x.y.0.2) oder auch auf den VPN (x.y.0.33)

Bahnhof ? Ägypten ? Wer oder was soll "VPN" sein ??? Und WIE sind deine IP Adressen zu verstehen ??
Grundlagen zu dem Thema findest du wie immer im OVPN Tutorial hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

Abbrechen tut auch gar nix, denn dein Client meldet "Initialization Sequence Completed" was zeigt das der Tunnel fehlerfrei aufgebaut wurde !!! Du hast also soweit alles richtig gemacht wenn man mal von den kosmetischen Fehlern wie dem nicht beidseitigen "comp-lzo" und der ungleichen Link MTU absieht. Das ist erstmal nur kosmetisch.
Die große Frage ist WO ist dein Server ?? Im internen LAN, im Internet ??? Und WO ist der Client ?
Eine kurze Skizze hätte hier allen in der Community geholfen dein Design zu verstehen.
Nur so viel...
Wenn du remote (Winblows) Rechner nicht pingen kannst hat das in der Regel 4 Gründe:

Du hast die lokale Firewall NICHT angepasst. Die blockt alles was aus fremden IP netzen kommt und dein VPN Client hat eine Absender IP von 192.168.10.0. Solcher Traffic wird geblockt
ICMP (Ping, Traceroute) wird generell per Default geblockt. Wie man das freischaltet kannst du hier nachlesen: https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Das virtuelle TAP Interface hat oft ein falsches Windows Firewall Profil ! Durch die fehlende Gateway Discovery deklariert Winblows das Interface als Public und blockiert damit jeglichen eingehnden Traffic. Das TAP Interface musst du also auf ein Private Profil setzen in den Firewall Settings !
Der OVPN Server ist im lokalen LAN. Dann fehlt oft eine statische Route auf dem Internet Router die dann zwingend erforderlich ist. Siehe auch hier:

OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Deshalb pingt man also immer die lokalen Router Interface oder Drucker usw. also Geräte die keine lokale Firewall haben !!
Checke diese 4 Punkte, dann kommt das auch sofort zum Fliegen !

Besten Dank für den Hinweis, die grüne Signalisierung nichts bedeutet.
Das ist fast klar, erst wenn etwas tatsächlich funktioniert, werden Statusmeldungen anerkannt.

Wo ist denn nun dein wirkliches Problem ??

Der Tunnel wird aufgebaut, wie erkannt, allerdings können keine Daten fließen.

Du hast also soweit alles richtig gemacht wenn man mal von den kosmetischen Fehlern wie dem nicht beidseitigen "comp-lzo" und der ungleichen Link MTU absieht.

Das dachte ich mir.

Die große Frage ist WO ist dein Server ?? Im internen LAN, im Internet ??? Und WO ist der Client ?

Der Server steht hinter NAT mit 192.168.0.33/24
Der Client extern hinter NAT mit 192.168.11.66/24
Beide stehen geographisch an zwei unterschiedlichen Standorten und haben entsprechend jeweils eine andere öffentliche IPv4 Adresse

Es gibt noch einen Drucker 192.168.0.111 - welcher aktuell die 'ping' ohne Antwort lässt.

Getestet, wenn Server die Adressen aus dem gleichen Subnetz vergibt:

server-bridge 192.168.0.33 255.255.255.0 192.168.0.60 192.168.0.70

In der Zwischenzeit arbeite ich die (verlinkten) Anleitungen durch.

es ist gerade leicht peinlich:

Starte ich den OpenVPN Server mit den unten eingestellten Informationen:

server-bridge 192.168.0.33 255.255.255.0 192.168.0.60 192.168.0.70

Gibt es eine Verbindung.
Ich kann den Drucker erreichen und diverse andere Ziele.

Weil aktuell das 'comp-lzo' zu einem Problem führte, habe ich es temporär auskommentiert.

Was mich nur stutzig macht, warum 2 unterschiedliche Zertifikate den Ping sehr stark beeinflussen.
111 (Printserver) und 222 (direkt) sind Drucker und eine Windowskiste auf 2

Aktueller Status:
Es funktioniert, mehr aber noch nicht.

Der Server steht hinter NAT mit 192.168.0.33/24 Der Client extern hinter NAT mit 192.168.11.66/24

Nicht ganz !
NAT gilt ausschliesslich nur für den Traffic ins Internet NICHT aber für den durch den VPN Tunnel. Dort macht man sinnigerweise kein NAT und routet immer transparent.
Das Server Bridge Statement ist tödlich !
Damit verbindest du deine 3 unterschiedlichen IP Netzwerke über eine Layer 2 Bridge.
https://openvpn.net/community-resources/ethernet-bridging/
Sowas Gruseliges mach man sich gar nicht vorstellen.... Damit wird jegliche Sicherheit ausgehebelt.
Sinnvoll wäre es mal wenn du die Routing Tabellen hier postest um zu sehen das die IP Netze auch sauber propagiert werden.
Die Firewall und ICMP Settings hast du umgesetzt ?

NAT gilt ausschliesslich nur für den Traffic ins Internet NICHT aber für den durch den VPN Tunnel. Dort macht man sinnigerweise kein NAT und routet immer transparent.

So ist es - Aussage galt als Erklärung.

Route Client:

===========================================================================
Schnittstellenliste
 28...00 ff 1c 78 a8 14 ......TAP-Windows Adapter V9
 17...c0 f8 da 9e a5 c7 ......Microsoft Virtual WiFi Miniport Adapter
 12...c0 f8 da 9e a5 c7 ......Broadcom 802.11n-Netzwerkadapter
 10...20 6a 8a 43 dd 1d ......Broadcom NetXtreme Gigabit Ethernet
  1...........................Software Loopback Interface 1
 11...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 18...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #2
 27...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter
 20...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #3
 32...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #4
 31...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #5
 49...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #6
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0     192.168.11.1    192.168.11.66     25
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      192.168.0.0    255.255.255.0   Auf Verbindung      192.168.0.61    266
     192.168.0.61  255.255.255.255   Auf Verbindung      192.168.0.61    266
    192.168.0.255  255.255.255.255   Auf Verbindung      192.168.0.61    266
     192.168.11.0    255.255.255.0   Auf Verbindung     192.168.11.66    281
    192.168.11.66  255.255.255.255   Auf Verbindung     192.168.11.66    281
   192.168.11.255  255.255.255.255   Auf Verbindung     192.168.11.66    281
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.0.61    266
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.11.66    281
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.0.61    266
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.11.66    281
===========================================================================
St„ndige Routen:
  Keine

Route SERVER:

===========================================================================
Schnittstellenliste
 18...02 25 90 37 4f f2 ......MAC Bridge Miniport
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter
 14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.0.1     192.168.0.11     10
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      192.168.0.0    255.255.255.0   Auf Verbindung      192.168.0.11    266
     192.168.0.11  255.255.255.255   Auf Verbindung      192.168.0.11    266
    192.168.0.255  255.255.255.255   Auf Verbindung      192.168.0.11    266
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.0.11    266
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.0.11    266
===========================================================================
St„ndige Routen:
  Keine

Verbindung steht, Drucker und Freigaben können erreicht werden.

Irgendwas stimmt da aber grundsätzlich nicht bei dir !!
Wo ist denn dein internes OpenVPN Netzwerk ?? Das IP Netz was du mit server 192.168.10.0 255.255.255.0 definierst muss ja am Tunnel Interface anliegen. Der Server hat immer die .1 und die Route im Client MUSS auf diesen Adapter bzw. auf diese IP Adresse zeigen. Genau DAS ist bei dir nicht der Fall !

Das sieht so aus als ob du da irgendwie ein Bridging machst statt Routing und falscxhe Adapter benutzt.

Mach dochmal ein ganz einfache und banale Server Konfig:
port 1194
proto udp
dev tun0
ca /tmp/openvpn/ca.crt (Master Zertifikat)
cert /tmp/openvpn/cert.pem (Server Zertifikat)
key /tmp/openvpn/key.pem (Server Key)
dh /tmp/openvpn/dh.pem (DH Parameter)
server 192.168.10.0 255.255.255.0
push "route 192.168.0.0 255.255.255.0"
keepalive 10 120
persist-key
persist-tun
verb 3

Und Client:
client
dev tun
proto udp
remote x.y.z.a 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca C:/Programme/OpenVPN/easy-rsa/keys/ca.crt
cert C:/Programme/OpenVPN/easy-rsa/keys/client1.crt
key C:/Programme/OpenVPN/easy-rsa/keys/client1.key
ns-cert-type server
comp-lzo
verb 3

Im Testbetrieb ohne VPN-Netz gelassen (192.168.0.0 DHCP 60-70)

Route Print vom Client:

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0     192.168.11.1    192.168.11.66     25
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      192.168.0.0    255.255.255.0     192.168.10.5     192.168.10.6     10
     192.168.10.1  255.255.255.255     192.168.10.5     192.168.10.6     10
     192.168.10.4  255.255.255.252   Auf Verbindung      192.168.10.6    266
     192.168.10.6  255.255.255.255   Auf Verbindung      192.168.10.6    266
     192.168.10.7  255.255.255.255   Auf Verbindung      192.168.10.6    266
     192.168.11.0    255.255.255.0   Auf Verbindung     192.168.11.66    281
    192.168.11.66  255.255.255.255   Auf Verbindung     192.168.11.66    281
   192.168.11.255  255.255.255.255   Auf Verbindung     192.168.11.66    281
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.11.66    281
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.10.6    266
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.11.66    281
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.10.6    266
===========================================================================

route print server

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.0.1     192.168.0.11     10
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      192.168.0.0    255.255.255.0   Auf Verbindung      192.168.0.11    266
     192.168.0.11  255.255.255.255   Auf Verbindung      192.168.0.11    266
    192.168.0.255  255.255.255.255   Auf Verbindung      192.168.0.11    266
     192.168.10.0    255.255.255.0     192.168.10.2     192.168.0.11     11
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.0.11    266
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.0.11    266
===========================================================================

jetzt kommt am Client wieder dieser Fehler:

Wed Jun 05 09:22:38 2019 Bad LZO decompression header byte: 42
Wed Jun 05 09:22:48 2019 Bad LZO decompression header byte: 42
Wed Jun 05 09:22:59 2019 Bad LZO decompression header byte: 42
Wed Jun 05 09:23:09 2019 Bad LZO decompression header byte: 42
Wed Jun 05 09:23:11 2019 Bad LZO decompression header byte: 96
Wed Jun 05 09:23:11 2019 Bad LZO decompression header byte: 96
Wed Jun 05 09:23:11 2019 Bad LZO decompression header byte: 96
Wed Jun 05 09:23:21 2019 Bad LZO decompression header byte: 42
Wed Jun 05 09:23:31 2019 Bad LZO decompression header byte: 42
Wed Jun 05 09:23:41 2019 Bad LZO decompression header byte: 42

ping auf Drucker 192.168.0.111 ohne Rückmeldung

Das sieht so aus als ob du da irgendwie ein Bridging machst statt Routing und falscxhe Adapter benutzt.

Das könnte also die Ursache sein, dass ich in einer ganz früheren Anleitung eine Brücke erstellen sollte (...).

OK, jetzt stimmt das wenigstens mit den IP Netzen in der Routing Tabelle.
Das mit dem LZO Fehler kannst du ignorieren. Lösche das "comp-lzo" aus der Server und Client Konfig, dann verschwindet das ! Damit ist dann Kompression erstmal komplett deaktiviert.

Was verwundert ist deine Bridge dort in den Winblows Adaptern !! Die hat da nichts zu suchen. OpenVPN sollte man immer routen. Also weg damit !
Du darfst keines der Interfaces irgendwie in eine Bridge oder "Netzwerkbrücke" einbinden !!!
Hier nochmal die Punkte die zu beachten sind:

Keinerlei Bridges. Sollten alle gelöscht sein !
Das Tunnel Interface (tap) muss ein Privates Firewall Profil haben
VPN Tunnelaufbau sollte mit "Intizialisation sequence completed" abschliessen, was dann zeigt das der Tunnel erfolgreich etabliert wurde.

Den Drucker remote zu pingen ist schonmal richtig, denn der hat ja keine Firewall die dir ein Bein stellen kann !

Allerdings musst du folgendes dazu absolut sicherstellen:

Drucker MUSS ein Default Gateway definiert haben !
Default Gateway sollte der Internet Router sein. (Normal wenn der Drucker eine DHCP IP vom Router bekommt)
Der Internet Router MUSS eine statische Route auf das interne OVPN IP Netz (bei dir 192.168.0.0 /24) haben wenn der OVPN Server im lokalen LAN ist !

Siehe hier:

Tue so also ob das NAS In der Zeichnung dein Drucker ist und ersetze das dort interne 10.10.10.0 /24 Netz mit deinem 192.168.0.0 /24
Das ist ja das gleiche Design was du hast !
Wichtig eben die statische Route, denn wenn der Drucker(NAS) auf die Ping Pakete mit der internen OVPN IP Absenderadresse antwortet schickt er das erst an sein Default Gateway, der Internet Router.
Der muss es natürlich dann an die lokale LAN IP des OVPN Servers routen, der es dann wiederum in sein internes Tunnelnetz routet.
Deshalb diese 3 wichtigen Punkte:

Windows OVPN Server muss IPv4 Forwarding (Routing) aktiviert haben !!
Firewall Profil des tap Interface muss Privat sein.
Statische Route Internet Router: Zielnetz: 192.168.0.0, Maske: 255.255.255.0, Gateway: <LAN_IP_OVPN-Server>

So wird ein Schuh draus !

nach einiger Zeit auch eine Rückmeldung:

Fri Jun 07 10:10:33 2019 (extern):55854 peer info: IV_GUI_VER=OpenVPN_GUI_11
Fri Jun 07 10:10:33 2019 (extern):55854 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1542'  
Fri Jun 07 10:10:33 2019 (extern):55854 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'  
Fri Jun 07 10:10:33 2019 (extern):55854 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Fri Jun 07 10:10:33 2019 (extern):55854 [Client01] Peer Connection Initiated with [AF_INET](extern):55854
Fri Jun 07 10:10:33 2019 MULTI: new connection by client 'Client01' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.  
Fri Jun 07 10:10:33 2019 MULTI_sva: pool returned IPv4=192.168.10.6, IPv6=(Not enabled)
Fri Jun 07 10:10:33 2019 MULTI: Learn: 192.168.10.6 -> Client01/(extern):55854
Fri Jun 07 10:10:33 2019 MULTI: primary virtual IP for Client01/(extern):55854: 192.168.10.6
Fri Jun 07 10:10:34 2019 Client01/(extern):55854 PUSH: Received control message: 'PUSH_REQUEST'  
Fri Jun 07 10:10:34 2019 Client01/(extern):55854 SENT CONTROL [Client01]: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 192.168.10.1,topology net30,ping 10,ping-restart 120,ifconfig 192.168.10.6 192.168.10.5,peer-id 1,cipher AES-256-GCM' (status=1)  
Fri Jun 07 10:10:34 2019 Client01/(extern):55854 Data Channel: using negotiated cipher 'AES-256-GCM'  
Fri Jun 07 10:10:34 2019 Client01/(extern):55854 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Fri Jun 07 10:10:34 2019 Client01/(extern):55854 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Fri Jun 07 10:10:39 2019 Client01/(extern):55854 IP packet with unknown IP version=15 seen
Fri Jun 07 10:10:44 2019 Client01/(extern):55854 IP packet with unknown IP version=15 seen
Fri Jun 07 10:10:49 2019 Client01/(extern):55854 IP packet with unknown IP version=15 seen

Gibt es einen Kniff, dem 'mytap' was anderes zuzuweisen?

(In der Oberfläche klappt es zumindest nicht)

Drucker MUSS ein Default Gateway definiert haben !

DHCP :Þ Gateway ist wegen Maildienste bereits hinterlegt.

Ich denke, diese Route ist gemeint (Digitalisierungsbox Premium)
Hinweis:
In der Grafik ist ein Zahlendreher 245 vs 254

Vermutlich hängt es da auch noch !!!

Fri Jun 07 10:56:20 2019 SIGUSR1[soft,tls-error] received, process restarting
Fri Jun 07 10:56:20 2019 MANAGEMENT: >STATE:1559897780,RECONNECTING,tls-error,,,,,
Fri Jun 07 10:56:20 2019 Restart pause, 160 second(s)
Fri Jun 07 10:59:00 2019 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Fri Jun 07 10:59:00 2019 TCP/UDP: Preserving recently used remote address: [AF_INET](extern):1194
Fri Jun 07 10:59:00 2019 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Jun 07 10:59:00 2019 UDP link local: (not bound)
Fri Jun 07 10:59:00 2019 UDP link remote: [AF_INET](extern):1194
Fri Jun 07 10:59:00 2019 MANAGEMENT: >STATE:1559897940,WAIT,,,,,,

die config ist jedenfalls jetzt so gemacht worden, dass gar nichts mehr geht.

Habe da vermutlich kein Verständnis für, jedoch interessant, warum man dafür extra Netze aufspannen soll.
Vorher ging es ja :Þ

Werde in den nächsten Tagen sehr wenig Zeit haben (...).

Vermutlich, Laptop / Rechner steht geographisch woanders, gibt es jetzt immer einen BlueScreen und Neustart, nachdem die Verbindung zustande gekommen ist.

Dies gab es früher mal - mit einer ersten Konfiguration und ist danach nicht mehr aufgetaucht.

Der Computer wurde nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x000000d1 (0x00000020, 0x00000002, 0x00000000, 0x8c6abece).

Zwischenmeldung

Hallo,

Zitat von @Midivirus:
Der Computer wurde nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x000000d1 (0x00000020, 0x00000002, 0x00000000, 0x8c6abece).

Und? Schon mal geschaut was evtl. für ein Treiber da verrücktspielt? Schon mal geschaut was bei 0x000000d1 zu tun ist?

https://www.google.com/search?q=0x000000d1

Gruß,
Peter

Hier:

Client01/(extern):55854 IP packet with unknown IP version=15 seen

stimmt ja auch schon grundsätzlich was nicht. Die ganze Konfig scheint ein einziger Murks zu sein.

https://askubuntu.com/questions/233396/openvpn-logs-ip-packet-with-unkno ...
Irgendwas mit der Tunnel Interface Defintion in der Konfig Datei ist hier also falsch !

Irgendwie alle unverständlich...