08.02.2018

5493

OpenVPN Installation Routing Problem

Huhu,

ich habe Schwierigkeiten bei der Installation von OpenVPN auf einen Win10 Rechner.
Auf dem Rechner ist eine Software installiert, die dann auch von außerhalb bedient werden soll.

Ich habe laut den alten Anleitungen von datasearch und dem HOWTO auf der Seite, die Installation durchgeführt mit den jeweiligen Zertifikaten (ca,vars, server.ovpn, client.ovpn, dh).

Auch OpenSSL installiert, da es laut den Anleitungen auch mir nicht ganz klar war wie ich die openssl.cnf konfigurieren soll.

Beigefügt das Netzwerk in dem der Rechner ist und das Log von dem Rechner außerhalb der darauf zugreifen soll.

Ich vermute der Fehler liegt beim Routing bzw. bei der Portfreigabe bei den beiden Routern.

Auf der Fritzbox hab ich den UDP Port freigeben aber kann leider nicht die Route zum 10.8.8.1 OVPN Netzwerk freigeben (Fehlermeldung: Die Route ist nicht zulässig).

Müsste ich beim Zyxel Router auch den UDP Port freigeben bzw. auch die Route zum OVPN Netzwerk?

Danke für die Rückmeldungen schon mal.

Gruß
intane

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

Content-ID: 364105

Url: https://administrator.de/forum/openvpn-installation-routing-problem-364105.html

Ausgedruckt am: 28.12.2024 um 05:12 Uhr

48 Kommentare

Neuester Kommentar

Hallo intane,

wenn du eine Routerkaskade hast (so sehe ich das zumindest im Bild), musst du auf beiden Routern den Port durchreichen...

Gruß Walle

Alles klar, also bei beiden den UDP Port.

Dachte aber, dass auch die Route wichtig ist, so habe ich zumindest bei anderen Konfigurationen gesehen.

Gruß
intane

Hi,
handelt es sich um einen OpenVPN-Client auf dem Win10-PC, ist ein durchreichen des UDP-Ports nicht notwendig. Bei einem OpenVPN-Server schon und das auf beiden Routern.

...mit den jeweiligen Zertifikaten.

...hier wird wohl Dein Problem liegen. (selbst erstellt?) Du kannst an den Log-Einträgen einen TLS-Fehler erkennen, der wohl ein Problem mit Deinen Zertifikaten vermuten lässt.
Gruss orcape

Sieh dir doch mal dein Log an !
Dein TLS Key Handshake scheitert beim VPN Aufbau !!
Es kommt also erst gar kein VPN Tunnel zustande ! Kollege orcape hats oben schon gesagt: Da stimmt also was mit deinen Zertifikaten nicht.
Port Forwarding scheint zu gehen, denn sonst würdest du die Log Einträge gar nicht erst sehen !

Ggf. hilft dir dieses Tutorial weiter was die Zertifikatsgenerierung anbetrifft. Die ist auf allen OVPN Plattformen immer gleich !
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

handelt es sich um einen OpenVPN-Client auf dem Win10-PC, ist ein durchreichen des UDP-Ports nicht notwendig. Bei einem OpenVPN-Server schon und das auf beiden Routern.

ah ok das ist schon mal gut zu wissen.

...hier wird wohl Dein Problem liegen. (selbst erstellt?) Du kannst an den Log-Einträgen einen TLS-Fehler erkennen, der wohl ein Problem mit Deinen Zertifikaten vermuten lässt.

Zertifikate noch einmal neu erstellt, leider Fehler besteht.

Dein TLS Key Handshake scheitert beim VPN Aufbau !!
Es kommt also erst gar kein VPN Tunnel zustande ! Kollege orcape hats oben schon gesagt: Da stimmt also was mit deinen Zertifikaten nicht.

Ggf. hilft dir dieses Tutorial weiter was die Zertifikatsgenerierung anbetrifft. Die ist auf allen OVPN Plattformen immer gleich !
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

Zertifikate noch einmal neu erstellt, leider der selbe Fehler.
Anbei diesmal auch das Server Log.

Options error: --cert fails with 'c:programmeopenvpneasy-rsakeysserver(Name geändert).crt': No such file or directory (errno=2)
WARNING: cannot stat file 'c:programmeopenvpneasy-rsakeysserver.key': No such file or directory (errno=2)
Options error: --key fails with 'c:programmeopenvpneasy-rsakeys//server.key'
Options error: Please correct these errors.

Außerdem..pkcs11_protected_authentication = DISABLED
Tue Feb 13 13:37:43 2018 us=303614 Could not determine IPv4/IPv6 protocol. Using AF_INET
Tue Feb 13 13:37:43 2018 us=303614 Socket Buffers: R=[65536->65536] S=[65536->65536]
Tue Feb 13 13:37:43 2018 us=303614 TCP/UDP: Socket bind failed on local address [AF_INET]192.168.188.105:1194
Tue Feb 13 13:37:43 2018 us=303614 Exiting due to fatal error

Der CN muss bei der CA und beim Server Zertifikat gleich sein, richtig?
Muss die CA irgendwie signiert werden? Weil nur beim Server Zertifikat am Ende gefragt wird..

Bevor ich das Server Zertifikat erstelle, kommt der folgende Hinweis:
Using configuration from ...\easy-rsa\openssl.cnf

Diese config habe ich nicht selber erstellt..

Sonnst habe ich die die dh2048 in dem Config Ordner gespeichert zusammen mit der server.ovpn Datei, das Server und Client Zertifikat im Ordner keys gelassen

Vermute ob ich mit SSL etwas noch einstellen muss...

Danke für die Beiträge bisher !

TCP/UDP: Socket bind failed on local address

Das zeugt NICHT von einem Zertifikatsproblem !
Da stimmt irgendwas grundsätzlich mit dem Zugriff auf die Adapter Hardware nicht !
Kann das sein das du den OVPN ohne Admin Rechte laufen lässt ?? Das scheitert dann natürlich da der unzureichende Rechte für die Systemkomponenten besitzt !

Vermute ob ich mit SSL etwas noch einstellen muss...

Nein ! Zertifikatsfehler tauchen ja laut Log nicht auf.
Nur wenn der OVPN Server hinter einem NAT Router steht musst du UDP 1194 auf die lokale OVPN Server LAN IP am Router forwarden. Guckst du auch hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

Da stimmt irgendwas grundsätzlich mit dem Zugriff auf die Adapter Hardware nicht !
Kann das sein das du den OVPN ohne Admin Rechte laufen lässt ?? Das scheitert dann natürlich da der unzureichende Rechte für die Systemkomponenten besitzt !

Beim Client richte ich grundsätzlich immer ein, dass OVPN als Administrator gestartet werden soll.

Der Tunneladapter ist auf der Host Seite mit "openvpn" gekennzeichnet und auf Client Seite mit "TAP" auf der Server.ovpn dann dementsprechend mit "dev tap" und "dev-node openvpn".

Thu Feb 15 15:03:30 2018 us=173655 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Thu Feb 15 15:03:30 2018 us=173655 Windows version 6.2 (Windows 8 or greater) 64bit
Thu Feb 15 15:03:30 2018 us=173655 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Thu Feb 15 15:03:30 2018 us=248693 Diffie-Hellman initialized with 2048 bit key
Thu Feb 15 15:03:30 2018 us=248693 TLS-Auth MTU parms [ L:1654 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Thu Feb 15 15:03:30 2018 us=248693 interactive service msg_channel=0
Thu Feb 15 15:03:30 2018 us=248693 open_tun
Thu Feb 15 15:03:30 2018 us=248693 TAP-WIN32 device [openvpn] opened: \\.\Global\{98A1110C-AE97-41E6-8A4A-88D4559A8C5E}.tap
Thu Feb 15 15:03:30 2018 us=248693 TAP-Windows Driver Version 9.21 
Thu Feb 15 15:03:30 2018 us=248693 TAP-Windows MTU=1500
Thu Feb 15 15:03:30 2018 us=248693 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.8.1/255.255.255.0 on interface {98A1110C-AE97-41E6-8A4A-88D4559A8C5E} [DHCP-serv: 10.8.8.0, lease-time: 31536000]
Thu Feb 15 15:03:30 2018 us=248693 Sleeping for 10 seconds...
Thu Feb 15 15:03:40 2018 us=254038 Successful ARP Flush on interface [5] {98A1110C-AE97-41E6-8A4A-88D4559A8C5E}
Thu Feb 15 15:03:40 2018 us=254038 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Feb 15 15:03:40 2018 us=254038 Data Channel MTU parms [ L:1654 D:1472 EF:122 EB:411 ET:32 EL:3 ]
Thu Feb 15 15:03:40 2018 us=254038 Could not determine IPv4/IPv6 protocol. Using AF_INET
Thu Feb 15 15:03:40 2018 us=254038 Socket Buffers: R=[65536->65536] S=[65536->65536]
Thu Feb 15 15:03:40 2018 us=254038 TCP/UDP: Socket bind failed on local address [AF_INET]192.168.188.105:1194
Thu Feb 15 15:03:40 2018 us=254038 Exiting due to fatal error
Thu Feb 15 15:03:40 2018 us=254038 Closing TUN/TAP interface
Thu Feb 15 15:03:40 2018 us=268832 TAP: DHCP address released
Thu Feb 15 15:03:50 2018 us=372410 Current Parameter Settings:
Thu Feb 15 15:03:50 2018 us=372410   config = 'C:\Program Files\OpenVPN\config\Server.ovpn'  
Thu Feb 15 15:03:50 2018 us=372410   mode = 1
Thu Feb 15 15:03:50 2018 us=372410   show_ciphers = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   show_digests = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   show_engines = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   genkey = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   key_pass_file = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   show_tls_ciphers = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   connect_retry_max = 0
Thu Feb 15 15:03:50 2018 us=372410 Connection profiles :
Thu Feb 15 15:03:50 2018 us=372410   proto = udp
Thu Feb 15 15:03:50 2018 us=372410   local = '192.168.188.105'  
Thu Feb 15 15:03:50 2018 us=372410   local_port = '1194'  
Thu Feb 15 15:03:50 2018 us=372410   remote = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   remote_port = '1194'  
Thu Feb 15 15:03:50 2018 us=372410   remote_float = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   bind_defined = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   bind_local = ENABLED
Thu Feb 15 15:03:50 2018 us=372410   bind_ipv6_only = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   connect_retry_seconds = 5
Thu Feb 15 15:03:50 2018 us=372410   connect_timeout = 120
Thu Feb 15 15:03:50 2018 us=372410   socks_proxy_server = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   socks_proxy_port = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   tun_mtu = 1500
Thu Feb 15 15:03:50 2018 us=372410   tun_mtu_defined = ENABLED
Thu Feb 15 15:03:50 2018 us=372410   link_mtu = 1500
Thu Feb 15 15:03:50 2018 us=372410   link_mtu_defined = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   tun_mtu_extra = 32
Thu Feb 15 15:03:50 2018 us=372410   tun_mtu_extra_defined = ENABLED
Thu Feb 15 15:03:50 2018 us=372410   mtu_discover_type = -1
Thu Feb 15 15:03:50 2018 us=372410   fragment = 1472
Thu Feb 15 15:03:50 2018 us=372410   mssfix = 1472
Thu Feb 15 15:03:50 2018 us=372410   explicit_exit_notification = 0
Thu Feb 15 15:03:50 2018 us=372410 Connection profiles END
Thu Feb 15 15:03:50 2018 us=372410   remote_random = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   ipchange = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   dev = 'tap'  
Thu Feb 15 15:03:50 2018 us=372410   dev_type = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   dev_node = 'openvpn'  
Thu Feb 15 15:03:50 2018 us=372410   lladdr = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   topology = 1
Thu Feb 15 15:03:50 2018 us=372410   ifconfig_local = '10.8.8.1'  
Thu Feb 15 15:03:50 2018 us=372410   ifconfig_remote_netmask = '255.255.255.0'  
Thu Feb 15 15:03:50 2018 us=372410   ifconfig_noexec = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   ifconfig_nowarn = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   ifconfig_ipv6_local = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   ifconfig_ipv6_netbits = 0
Thu Feb 15 15:03:50 2018 us=372410   ifconfig_ipv6_remote = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   shaper = 0
Thu Feb 15 15:03:50 2018 us=372410   mtu_test = 0
Thu Feb 15 15:03:50 2018 us=372410   mlock = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   keepalive_ping = 10
Thu Feb 15 15:03:50 2018 us=372410   keepalive_timeout = 120
Thu Feb 15 15:03:50 2018 us=372410   inactivity_timeout = 0
Thu Feb 15 15:03:50 2018 us=372410   ping_send_timeout = 10
Thu Feb 15 15:03:50 2018 us=372410   ping_rec_timeout = 240
Thu Feb 15 15:03:50 2018 us=372410   ping_rec_timeout_action = 2
Thu Feb 15 15:03:50 2018 us=372410   ping_timer_remote = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   remap_sigusr1 = 0
Thu Feb 15 15:03:50 2018 us=372410   persist_tun = ENABLED
Thu Feb 15 15:03:50 2018 us=372410   persist_local_ip = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   persist_remote_ip = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   persist_key = ENABLED
Thu Feb 15 15:03:50 2018 us=372410   passtos = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   resolve_retry_seconds = 1000000000
Thu Feb 15 15:03:50 2018 us=372410   resolve_in_advance = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   username = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   groupname = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   chroot_dir = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   cd_dir = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   writepid = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   up_script = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   down_script = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   down_pre = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   up_restart = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   up_delay = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   daemon = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   inetd = 0
Thu Feb 15 15:03:50 2018 us=372410   log = ENABLED
Thu Feb 15 15:03:50 2018 us=372410   suppress_timestamps = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   machine_readable_output = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   nice = 0
Thu Feb 15 15:03:50 2018 us=372410   verbosity = 4
Thu Feb 15 15:03:50 2018 us=372410   mute = 0
Thu Feb 15 15:03:50 2018 us=372410   gremlin = 0
Thu Feb 15 15:03:50 2018 us=372410   status_file = 'openvpn-status.log'  
Thu Feb 15 15:03:50 2018 us=372410   status_file_version = 1
Thu Feb 15 15:03:50 2018 us=372410   status_file_update_freq = 60
Thu Feb 15 15:03:50 2018 us=372410   occ = ENABLED
Thu Feb 15 15:03:50 2018 us=372410   rcvbuf = 0
Thu Feb 15 15:03:50 2018 us=372410   sndbuf = 0
Thu Feb 15 15:03:50 2018 us=372410   sockflags = 0
Thu Feb 15 15:03:50 2018 us=372410   fast_io = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   comp.alg = 2
Thu Feb 15 15:03:50 2018 us=372410   comp.flags = 1
Thu Feb 15 15:03:50 2018 us=372410   route_script = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   route_default_gateway = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=372410   route_default_metric = 0
Thu Feb 15 15:03:50 2018 us=372410   route_noexec = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   route_delay = 0
Thu Feb 15 15:03:50 2018 us=372410   route_delay_window = 30
Thu Feb 15 15:03:50 2018 us=372410   route_delay_defined = DISABLED
Thu Feb 15 15:03:50 2018 us=372410   route_nopull = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   route_gateway_via_dhcp = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   allow_pull_fqdn = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   management_addr = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   management_port = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   management_user_pass = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   management_log_history_cache = 250
Thu Feb 15 15:03:50 2018 us=377415   management_echo_buffer_size = 100
Thu Feb 15 15:03:50 2018 us=377415   management_write_peer_info_file = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   management_client_user = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   management_client_group = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   management_flags = 0
Thu Feb 15 15:03:50 2018 us=377415   shared_secret_file = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   key_direction = 0
Thu Feb 15 15:03:50 2018 us=377415   ciphername = 'BF-CBC'  
Thu Feb 15 15:03:50 2018 us=377415   ncp_enabled = ENABLED
Thu Feb 15 15:03:50 2018 us=377415   ncp_ciphers = 'AES-256-GCM:AES-128-GCM'  
Thu Feb 15 15:03:50 2018 us=377415   authname = 'SHA1'  
Thu Feb 15 15:03:50 2018 us=377415   prng_hash = 'SHA1'  
Thu Feb 15 15:03:50 2018 us=377415   prng_nonce_secret_len = 16
Thu Feb 15 15:03:50 2018 us=377415   keysize = 0
Thu Feb 15 15:03:50 2018 us=377415   engine = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   replay = ENABLED
Thu Feb 15 15:03:50 2018 us=377415   mute_replay_warnings = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   replay_window = 64
Thu Feb 15 15:03:50 2018 us=377415   replay_time = 15
Thu Feb 15 15:03:50 2018 us=377415   packet_id_file = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   use_iv = ENABLED
Thu Feb 15 15:03:50 2018 us=377415   test_crypto = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   tls_server = ENABLED
Thu Feb 15 15:03:50 2018 us=377415   tls_client = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   key_method = 2
Thu Feb 15 15:03:50 2018 us=377415   ca_file = 'c://programme//openvpn//easy-rsa//keys//ca.crt'  
Thu Feb 15 15:03:50 2018 us=377415   ca_path = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   dh_file = 'c://programme//openvpn//config//dh2048.pem'  
Thu Feb 15 15:03:50 2018 us=377415   cert_file = 'c://programme//openvpn//easy-rsa//keys//server.crt'  
Thu Feb 15 15:03:50 2018 us=377415   extra_certs_file = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   priv_key_file = 'c://programme//openvpn//easy-rsa//keys//server.key'  
Thu Feb 15 15:03:50 2018 us=377415   pkcs12_file = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   cryptoapi_cert = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   cipher_list = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   tls_verify = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   tls_export_cert = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   verify_x509_type = 0
Thu Feb 15 15:03:50 2018 us=377415   verify_x509_name = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   crl_file = 'c://programme//openvpn//config//crl.pem'  
Thu Feb 15 15:03:50 2018 us=377415   ns_cert_type = 0
Thu Feb 15 15:03:50 2018 us=377415   remote_cert_ku[i] = 0
Thu Feb 15 15:03:50 2018 us=377415   remote_cert_eku = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   ssl_flags = 0
Thu Feb 15 15:03:50 2018 us=377415   tls_timeout = 2
Thu Feb 15 15:03:50 2018 us=377415   renegotiate_bytes = -1
Thu Feb 15 15:03:50 2018 us=377415   renegotiate_packets = 0
Thu Feb 15 15:03:50 2018 us=377415   renegotiate_seconds = 3600
Thu Feb 15 15:03:50 2018 us=377415   handshake_window = 60
Thu Feb 15 15:03:50 2018 us=377415   transition_window = 3600
Thu Feb 15 15:03:50 2018 us=377415   single_session = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   push_peer_info = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   tls_exit = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   tls_auth_file = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   tls_crypt_file = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   pkcs11_protected_authentication = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   pkcs11_protected_authentication = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   pkcs11_private_mode = 00000000
Thu Feb 15 15:03:50 2018 us=377415   pkcs11_cert_private = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   pkcs11_pin_cache_period = -1
Thu Feb 15 15:03:50 2018 us=377415   pkcs11_id = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   pkcs11_id_management = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   server_network = 0.0.0.0
Thu Feb 15 15:03:50 2018 us=377415   server_netmask = 0.0.0.0
Thu Feb 15 15:03:50 2018 us=377415   server_network_ipv6 = ::
Thu Feb 15 15:03:50 2018 us=377415   server_netbits_ipv6 = 0
Thu Feb 15 15:03:50 2018 us=377415   server_bridge_ip = 0.0.0.0
Thu Feb 15 15:03:50 2018 us=377415   server_bridge_netmask = 0.0.0.0
Thu Feb 15 15:03:50 2018 us=377415   server_bridge_pool_start = 0.0.0.0
Thu Feb 15 15:03:50 2018 us=377415   server_bridge_pool_end = 0.0.0.0
Thu Feb 15 15:03:50 2018 us=377415   push_entry = 'route 192.168.188.0 255.255.255.0 10.8.8.1 1'  
Thu Feb 15 15:03:50 2018 us=377415   push_entry = 'dhcp-option DNS 10.8.8.1'  
Thu Feb 15 15:03:50 2018 us=377415   push_entry = 'dhcp-option DNS 192.168.188.1'  
Thu Feb 15 15:03:50 2018 us=377415   push_entry = 'dhcp-option DNS 192.168.188.105'  
Thu Feb 15 15:03:50 2018 us=377415   push_entry = 'ping 10'  
Thu Feb 15 15:03:50 2018 us=377415   push_entry = 'ping-restart 120'  
Thu Feb 15 15:03:50 2018 us=377415   ifconfig_pool_defined = ENABLED
Thu Feb 15 15:03:50 2018 us=377415   ifconfig_pool_start = 10.8.8.2
Thu Feb 15 15:03:50 2018 us=377415   ifconfig_pool_end = 10.8.8.250
Thu Feb 15 15:03:50 2018 us=377415   ifconfig_pool_netmask = 0.0.0.0
Thu Feb 15 15:03:50 2018 us=377415   ifconfig_pool_persist_filename = 'ipp.txt'  
Thu Feb 15 15:03:50 2018 us=377415   ifconfig_pool_persist_refresh_freq = 600
Thu Feb 15 15:03:50 2018 us=377415   ifconfig_ipv6_pool_defined = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   ifconfig_ipv6_pool_base = ::
Thu Feb 15 15:03:50 2018 us=377415   ifconfig_ipv6_pool_netbits = 0
Thu Feb 15 15:03:50 2018 us=377415   n_bcast_buf = 256
Thu Feb 15 15:03:50 2018 us=377415   tcp_queue_limit = 64
Thu Feb 15 15:03:50 2018 us=377415   real_hash_size = 256
Thu Feb 15 15:03:50 2018 us=377415   virtual_hash_size = 256
Thu Feb 15 15:03:50 2018 us=377415   client_connect_script = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   learn_address_script = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   client_disconnect_script = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   client_config_dir = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   ccd_exclusive = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   tmp_dir = 'C:\WINDOWS\TEMP\'  
Thu Feb 15 15:03:50 2018 us=377415   push_ifconfig_defined = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   push_ifconfig_local = 0.0.0.0
Thu Feb 15 15:03:50 2018 us=377415   push_ifconfig_remote_netmask = 0.0.0.0
Thu Feb 15 15:03:50 2018 us=377415   push_ifconfig_ipv6_defined = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   push_ifconfig_ipv6_local = ::/0
Thu Feb 15 15:03:50 2018 us=377415   push_ifconfig_ipv6_remote = ::
Thu Feb 15 15:03:50 2018 us=377415   enable_c2c = ENABLED
Thu Feb 15 15:03:50 2018 us=377415   duplicate_cn = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   cf_max = 0
Thu Feb 15 15:03:50 2018 us=377415   cf_per = 0
Thu Feb 15 15:03:50 2018 us=377415   max_clients = 20
Thu Feb 15 15:03:50 2018 us=377415   max_routes_per_client = 256
Thu Feb 15 15:03:50 2018 us=377415   auth_user_pass_verify_script = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   auth_user_pass_verify_script_via_file = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   auth_token_generate = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   auth_token_lifetime = 0
Thu Feb 15 15:03:50 2018 us=377415   client = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   pull = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   auth_user_pass_file = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   show_net_up = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   route_method = 0
Thu Feb 15 15:03:50 2018 us=377415   block_outside_dns = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   ip_win32_defined = ENABLED
Thu Feb 15 15:03:50 2018 us=377415   ip_win32_type = 3
Thu Feb 15 15:03:50 2018 us=377415   dhcp_masq_offset = 0
Thu Feb 15 15:03:50 2018 us=377415   dhcp_lease_time = 31536000
Thu Feb 15 15:03:50 2018 us=377415   tap_sleep = 10
Thu Feb 15 15:03:50 2018 us=377415   dhcp_options = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   dhcp_renew = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   dhcp_pre_release = DISABLED
Thu Feb 15 15:03:50 2018 us=377415   domain = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   netbios_scope = '[UNDEF]'  
Thu Feb 15 15:03:50 2018 us=377415   netbios_node_type = 0
Thu Feb 15 15:03:50 2018 us=377415   disable_nbt = DISABLED
Thu Feb 15 15:03:50 2018 us=377415 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Thu Feb 15 15:03:50 2018 us=377415 Windows version 6.2 (Windows 8 or greater) 64bit
Thu Feb 15 15:03:50 2018 us=377415 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Thu Feb 15 15:03:50 2018 us=452451 Diffie-Hellman initialized with 2048 bit key
Thu Feb 15 15:03:50 2018 us=452451 TLS-Auth MTU parms [ L:1654 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Thu Feb 15 15:03:50 2018 us=452451 interactive service msg_channel=0
Thu Feb 15 15:03:50 2018 us=452451 open_tun
Thu Feb 15 15:03:50 2018 us=452451 TAP-WIN32 device [openvpn] opened: \\.\Global\{98A1110C-AE97-41E6-8A4A-88D4559A8C5E}.tap
Thu Feb 15 15:03:50 2018 us=452451 TAP-Windows Driver Version 9.21 
Thu Feb 15 15:03:50 2018 us=452451 TAP-Windows MTU=1500
Thu Feb 15 15:03:50 2018 us=452451 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.8.1/255.255.255.0 on interface {98A1110C-AE97-41E6-8A4A-88D4559A8C5E} [DHCP-serv: 10.8.8.0, lease-time: 31536000]
Thu Feb 15 15:03:50 2018 us=452451 Sleeping for 10 seconds...
Thu Feb 15 15:04:00 2018 us=457838 Successful ARP Flush on interface [5] {98A1110C-AE97-41E6-8A4A-88D4559A8C5E}
Thu Feb 15 15:04:00 2018 us=457838 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Feb 15 15:04:00 2018 us=457838 Data Channel MTU parms [ L:1654 D:1472 EF:122 EB:411 ET:32 EL:3 ]
Thu Feb 15 15:04:00 2018 us=457838 Could not determine IPv4/IPv6 protocol. Using AF_INET
Thu Feb 15 15:04:00 2018 us=457838 Socket Buffers: R=[65536->65536] S=[65536->65536]
Thu Feb 15 15:04:00 2018 us=457838 TCP/UDP: Socket bind failed on local address [AF_INET]192.168.188.105:1194
Thu Feb 15 15:04:00 2018 us=462639 Exiting due to fatal error
Thu Feb 15 15:04:00 2018 us=462639 Closing TUN/TAP interface
Thu Feb 15 15:04:00 2018 us=472635 TAP: DHCP address released

noch ein aktueller Ausschnitt vom Serverlog

Das Problem "Could not determine IPv4/IPv6 protocol. Using AF_INET" resultiert daraus das deine Server Konfig nicht sauber ist in der Beziehung das du NICHT genau spezifiziert hast welches Protokoll v4 oder v6 OVPN binden soll. Siehe auch:
https://forums.openvpn.net/viewtopic.php?t=23451

Dazu gibt es 2 Lösungen:
1.) Du entfernst komplett den IPv6 Support von den Interfaces
2.) Du spezifizierst genau welche Protokoll du verwenden willst im Server. proto udp4

Letzterer ist natürlich die saubere Variante. Bei dir weiß OVPN nicht welches Protkoll es nehmen soll und nimmt dann das was das OS bevorzugt wenn du mit Dual Stack arbeitest. Bei Winblows ist das dann IPv6 wofür dir dann aber wiederum weitere Konfig Parameter fehlen.
Deshalb geht das Binding bei dir schief und damit dann das ganze VPN.

2.) Du spezifizierst genau welche Protokoll du verwenden willst im Server. proto udp4

Auf der server.ovpn und client.ovpn eingerichtet, leider immer noch nicht weiter gekommen.

Die server.ovpn

local 192.168.188.105
port 1194

;proto tcp-server
proto udp4
mode server
tls-server

dev tap
;dev tun

dev-node openvpn

ca c://programme//openvpn//easy-rsa//keys//ca.crt
cert c://programme//openvpn//easy-rsa//keys//server.crt
key c://programme//openvpn//easy-rsa//keys//server.key  

dh c://programme//openvpn//config//dh2048.pem

;server 10.8.8.1 255.255.255.0
ifconfig 10.8.8.1 255.255.255.0
ifconfig-pool 10.8.8.2 10.8.8.250

ifconfig-pool-persist ipp.txt

;server-bridge 192.168.8.4 255.255.255.0 192.168.8.20 192.168.8.30

;push "route-gateway 10.8.8.1"  
push "route 192.168.188.0 255.255.255.0 10.8.8.1 1"  

;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
;learn-address ./script

;push "redirect-gateway"  

push "dhcp-option DNS 10.8.8.1"  
push "dhcp-option DNS 192.168.188.1"  
push "dhcp-option DNS 192.168.188.105"  
;push "dhcp-option WINS 192.168.8.1"  

client-to-client

;duplicate-cn

keepalive 10 120

;tls-auth ta.key 0 
;cipher BF-CBC        
;cipher AES-128-CBC   
;cipher DES-EDE3-CBC  

comp-lzo

max-clients 20

;user nobody
;group nobody

persist-key
persist-tun

status openvpn-status.log

log-append  openvpn.log

verb 4

;mute 20
tun-mtu 1500
tun-mtu-extra 32
fragment 1472
mssfix
crl-verify c://programme//openvpn//config//crl.pem
ip-win32 dynamic
;route-method exe
;route-delay 5

Die client.ovpn

client
dev tap
dev-node TAP
proto udp4
remote 35.14.21.23 1194
resolv-retry infinite
nobind
persist-key
persist-tun
tls-client
ca 'C:\\Program Files\\OpenVPN\\config\\ca.crt'  
cert 'C:\\Program Files\\OpenVPN\\config\\client2.crt'  
key 'C:\\Program Files\\OpenVPN\\config\\client2.key'  
ns-cert-type server
comp-lzo
verb 3
script-security 2
mute 50
pull
tun-mtu 1500
tun-mtu-extra 32
fragment 1472
mssfix
auth-nocache

Bei Server und Client Adaptern die ipv6 Option deaktiviert.

Beim Server Client ist allerdings der Adapter entfernt, ist das normal wenn da keine Verbindung besteht?

Nun kennen wir erst einmal die Server- und Client.conf von OpenVPN, gibt es da vielleicht auch schon Routing-Protokolle, die auf ein Zustande kommen eines Tunnels hinweisen?
Im übrigen baust Du mit "client-to-client einen Multiclienttunnel auf, ist das so beabsichtigt? Wenn nicht, ist das kontraproduktiv.
Einen ccd-Eintrag, der auf ein File hinweist, dessen Inhalt auf ein zu erreichendes Netz hinter der Fritzbox verweist, gibt es in der Server.conf auch nicht.
Du hast hier wohl nicht nur ein Problem, warum das ganze nicht funktioniert.
Auch wenn Dein Windows10 OpenVPN kann, würde ich das über die Routerkaskade etwas anders angehen, es sei denn, es ist ein Laptop mit dem die Verbindung auch unterwegs notwendig wäre. Ich würde den OpenVPN-Client auf dem, der Fritte vorgelagerten Router terminieren und den Zugriff auf den Win10 per Routing und Firewall sicherstellen.
Die Frage stellt sich nur, ob der Zyxel das kann oder ob er per alternativer Firmware (DD-WRT / OpenWRT) dazu gebracht werden kann.
Gruss orcape

Nun kennen wir erst einmal die Server- und Client.conf von OpenVPN, gibt es da vielleicht auch schon Routing-Protokolle, die auf ein Zustande kommen eines Tunnels hinweisen?

Leider noch nicht

Im übrigen baust Du mit "client-to-client einen Multiclienttunnel auf, ist das so beabsichtigt? Wenn nicht, ist das kontraproduktiv.

Die Server.conf wurde von einer bestehenden funktionierenden OVPN Verbindung übernommen und halt angepasst..
Bei der bestehenden Verbindung ist der Unterschied, dass sie mittels WinServer zustande kommt.

Einen ccd-Eintrag, der auf ein File hinweist, dessen Inhalt auf ein zu erreichendes Netz hinter der Fritzbox verweist, gibt es in der Server.conf auch nicht.

Wie würde so ein Eintrag in der conf aussehen?

Auch wenn Dein Windows10 OpenVPN kann, würde ich das über die Routerkaskade etwas anders angehen, es sei denn, es ist ein Laptop mit dem die Verbindung auch unterwegs notwendig wäre.

Ne ist ein Standrechner.
Was wäre optimierungsbedürftig?

Ich würde den OpenVPN-Client auf dem, der Fritte vorgelagerten Router terminieren und den Zugriff auf den Win10 per Routing und Firewall sicherstellen.
Die Frage stellt sich nur, ob der Zyxel das kann oder ob er per alternativer Firmware (DD-WRT / OpenWRT) dazu gebracht werden kann.

Leider darf ich den Zyxel nicht allzu viel konfigurieren, außer halt das nötige Routing, da er von einer anderen Firma bereitgestellt wird.
Routing wurde aber bisher auf dem Zyxel noch nicht vorgenommen. Also wäre ein Routing vom Zyxel zur Fritzbox bzw. zum Rechner dann doch sinnvoll.

Die Server.conf wurde von einer bestehenden funktionierenden OVPN Verbindung übernommen und halt angepasst..

Die Konf und die Änderungen wären sehr hilfreich für einen zielführende Hilfe hier !

Leider darf ich den Zyxel nicht allzu viel konfigurieren,

Ein Port Forwarding des OVPN Ports UDP 1194 ist da aber zwingend notwendig !!
Routing ist nicht erforderlich wenn die Kaskade 2maliges NAT macht, also doppelte Adress Translation.
Routen muss man nur wenn der Kaskaden Router kein NAT macht.
Hier werden dir diese beiden Szenarien und die Unterschiede der Konfig genau erklärt:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Also wäre ein Routing vom Zyxel zur Fritzbox bzw. zum Rechner dann doch sinnvoll.

Einzig nur dann wenn der kaskadierte Router KEIN NAT macht am WAN Port der zum Zyxel geht !!! Nur dann (und wirklich nur dann !) ist ein Routing auf dem Zyxel erforderlich.
Macht er NAT ist ein Routing am Zyxel überflüssig und auch Unsinn !
Siehe Tutorial !! (Thema ICS)

Die Konf und die Änderungen wären sehr hilfreich für einen zielführende Hilfe hier !

anbei die "funktionierende Server conf, folgend von deren client.conf

Windows Server 2008r2

local 192.168.77.100

port 1194

proto udp
mode server
tls-server

dev tap
dev-node openvpn

ca c://programme//openvpn//keys//ca.crt
cert c://programme//openvpn//keys//server.crt
key c://programme//openvpn//keys//server.key

dh c://programme//openvpn//config//dh2048.pem

ifconfig 10.8.8.1 255.255.255.0
ifconfig-pool 10.8.8.2 10.8.8.250

ifconfig-pool-persist ipp.txt

push "route 192.168.77.0 255.255.255.0 10.8.8.1 1"  

push "dhcp-option DOMAIN random"  
push "dhcp-option DNS 10.8.8.1"  
push "dhcp-option DNS 192.168.77.100"  
push "dhcp-option DNS 192.168.77.101"  

client-to-client

keepalive 10 120

comp-lzo

max-clients 20

persist-key
persist-tun

status openvpn-status.log

log-append  openvpn.log

verb 4

tun-mtu 1500
tun-mtu-extra 32
fragment 1472
mssfix
crl-verify c://programme//openvpn//config//crl.pem
ip-win32 dynamic

client
dev tap
dev-node TAP
proto udp
remote 34.87.81.19 1194
resolv-retry infinite
nobind
persist-key
persist-tun
tls-client
ca 'C:\\Program Files\\OpenVPN\\config\\ca.crt'  
cert 'C:\\Program Files\\OpenVPN\\config\\client2.crt'  
key 'C:\\Program Files\\OpenVPN\\config\\client2.key'  
ns-cert-type server
comp-lzo
verb 3
script-security 2
mute 50
pull
tun-mtu 1500
tun-mtu-extra 32
fragment 1472
mssfix
auth-nocache

Die neu erzeugte server.conf mit ihrer client.conf.

Windows 10 x64

local 192.168.188.105

port 1194

proto udp4
mode server
tls-server

dev tap
dev-node openvpn

ca c://programme//openvpn//easy-rsa//keys//ca.crt
cert c://programme//openvpn//easy-rsa//keys//server.crt
key c://programme//openvpn//easy-rsa//keys//server.key

dh c://programme//openvpn//config//dh2048.pem

ifconfig 10.8.8.1 255.255.255.0
ifconfig-pool 10.8.8.2 10.8.8.250

ifconfig-pool-persist ipp.txt

push "route 192.168.188.0 255.255.255.0 10.8.8.1 1"  


push "dhcp-option DNS 10.8.8.1"  
push "dhcp-option DNS 192.168.188.1"  
push "dhcp-option DNS 192.168.188.105"  

client-to-client

keepalive 10 120

comp-lzo

max-clients 20

persist-key
persist-tun

status openvpn-status.log

log-append  openvpn.log

verb 4

tun-mtu 1500
tun-mtu-extra 32
fragment 1472
mssfix
crl-verify c://programme//openvpn//config//crl.pem
ip-win32 dynamic

client
dev tap
dev-node TAP
proto udp4
remote 35.14.21.23 1194
resolv-retry infinite
nobind
persist-key
persist-tun
tls-client
ca 'C:\\Program Files\\OpenVPN\\config\\ca.crt'  
cert 'C:\\Program Files\\OpenVPN\\config\\client2.crt'  
key 'C:\\Program Files\\OpenVPN\\config\\client2.key'  
ns-cert-type server
comp-lzo
verb 3
script-security 2
mute 50
pull
tun-mtu 1500
tun-mtu-extra 32
fragment 1472
mssfix
auth-nocache

Die Änderungen sind lediglich, dass die Domain wegfällt und proto udp4..

Was ein tun/tap-Device ist, solltest Du wissen.
https://www.thomas-krenn.com/de/wiki/OpenVPN_Grundlagen
Ich glaube hier ist in den configs so einige im argen.
Du musst Dich entscheiden, ob Du das tap-Device verwenden möchtest, welches eine Verbindung auf Layer 2 Basis darstellt, oder ob Du routen willst und das tun-Device nimmst.
Beides in einem Tunnel wird wohl nicht funktionieren.
Gruss orcape

Von tap kann man nur dringenst abraten. Das ist dann Layer 2 Bridging und damit holt man sich den gesamten Broad- und Unicast Traffic des Netzes mit auf den VPN Tunnel was dann zu massiven Performance Problemen führen kann.
Selbst das offizielle OpenVPN HowTo rät deshalb dringenst davon ab und es nur dann einzusetzen wenn man es wirklich zwingend muss und das ist so gut wie nie der Fall.

Sry für die späte Antwort, in der letzten Zeit bisschen mit FritzVPN beschäftigt und da die Möglichkeiten recherchiert.

Die OpenVPN Verbindung klappt nun nach paar Modifikationen (Zyxel Router rausgenommen, FritzBox direkt ans Netz gehängt).
Leider halt mit TAP. Da ich noch keine Erfahrung mit TUN bisher hatte.

Wie realisiert sich der Umstieg auf TUN, einfach im Editor, TUN aktivieren und den Adapter umbenennen?

Anbei nun der funktionierende Log.

Server

Wed Mar 14 12:18:40 2018 OpenVPN 2.4.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jan 31 2017
Wed Mar 14 12:18:40 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Mar 14 12:18:40 2018 library versions: OpenSSL 1.0.2k  26 Jan 2017, LZO 2.09
Wed Mar 14 12:18:40 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Mar 14 12:18:40 2018 Need hold release from management interface, waiting...
Wed Mar 14 12:18:40 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Mar 14 12:18:41 2018 MANAGEMENT: CMD 'state on'  
Wed Mar 14 12:18:41 2018 MANAGEMENT: CMD 'log all on'  
Wed Mar 14 12:18:41 2018 MANAGEMENT: CMD 'hold off'  
Wed Mar 14 12:18:41 2018 MANAGEMENT: CMD 'hold release'  
Wed Mar 14 12:18:41 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]35.14.21.23:1194
Wed Mar 14 12:18:41 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Mar 14 12:18:41 2018 UDPv4 link local: (not bound)
Wed Mar 14 12:18:41 2018 UDPv4 link remote: [AF_INET]35.14.21.23:1194
Wed Mar 14 12:18:41 2018 MANAGEMENT: >STATE:1521026321,WAIT,,,,,,
Wed Mar 14 12:18:41 2018 MANAGEMENT: >STATE:1521026321,AUTH,,,,,,
Wed Mar 14 12:18:41 2018 TLS: Initial packet from [AF_INET]35.14.21.23:1194, sid=95b92eb2 61462e93
Wed Mar 14 12:18:41 2018 VERIFY OK: depth=1, C=de, ST=nrw, L=bochum, O=o, OU=ou, CN=server, name=server, emailAddress=server@test.de
Wed Mar 14 12:18:41 2018 VERIFY OK: nsCertType=SERVER
Wed Mar 14 12:18:41 2018 VERIFY OK: depth=0, C=de, ST=nrw, L=bochum, O=o, OU=ou, CN=server, name=server, emailAddress=server@test.de
Wed Mar 14 12:18:41 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Wed Mar 14 12:18:41 2018 [server] Peer Connection Initiated with [AF_INET]35.14.21.23:1194
Wed Mar 14 12:18:42 2018 MANAGEMENT: >STATE:1521026322,GET_CONFIG,,,,,,
Wed Mar 14 12:18:42 2018 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)  
Wed Mar 14 12:18:42 2018 PUSH: Received control message: 'PUSH_REPLY,route 192.168.188.0 255.255.255.0 10.8.8.1 1,dhcp-option 10.8.8.1,dhcp-option 192.168.188.1,dhcp-option 192.168.188.105,ping 10,ping-restart 120,ifconfig 10.8.8.3 255.255.255.0,peer-id 1,cipher AES-256-GCM'  
Wed Mar 14 12:18:42 2018 Options error: --dhcp-option: unknown option type '10.8.8.1' or missing or unknown parameter  
Wed Mar 14 12:18:42 2018 Options error: --dhcp-option: unknown option type '192.168.188.1' or missing or unknown parameter  
Wed Mar 14 12:18:42 2018 Options error: --dhcp-option: unknown option type '192.168.188.105' or missing or unknown parameter  
Wed Mar 14 12:18:42 2018 OPTIONS IMPORT: timers and/or timeouts modified
Wed Mar 14 12:18:42 2018 OPTIONS IMPORT: --ifconfig/up options modified
Wed Mar 14 12:18:42 2018 OPTIONS IMPORT: route options modified
Wed Mar 14 12:18:42 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Mar 14 12:18:42 2018 OPTIONS IMPORT: peer-id set
Wed Mar 14 12:18:42 2018 OPTIONS IMPORT: adjusting link_mtu to 1661
Wed Mar 14 12:18:42 2018 OPTIONS IMPORT: data channel crypto options modified
Wed Mar 14 12:18:42 2018 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key  
Wed Mar 14 12:18:42 2018 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key  
Wed Mar 14 12:18:42 2018 interactive service msg_channel=0
Wed Mar 14 12:18:42 2018 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 I=10 HWADDR=b9:77:5f:d5:e1:37
Wed Mar 14 12:18:42 2018 open_tun
Wed Mar 14 12:18:42 2018 TAP-WIN32 device [TAP] opened: \\.\Global\{F25781DE-AB88-4C05-9A3A-1C7B425DDA67}.tap
Wed Mar 14 12:18:42 2018 TAP-Windows Driver Version 9.21 
Wed Mar 14 12:18:42 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.8.3/255.255.255.0 on interface {F25781DE-AB88-4C05-9A3A-1C7B425DDA67} [DHCP-serv: 10.8.8.0, lease-time: 31536000]
Wed Mar 14 12:18:42 2018 Successful ARP Flush on interface [17] {F25781DE-AB88-4C05-9A3A-1C7B425DDA67}
Wed Mar 14 12:18:42 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Wed Mar 14 12:18:42 2018 MANAGEMENT: >STATE:1521026322,ASSIGN_IP,,10.8.8.3,,,,
Wed Mar 14 12:18:47 2018 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Wed Mar 14 12:18:47 2018 MANAGEMENT: >STATE:1521026327,ADD_ROUTES,,,,,,
Wed Mar 14 12:18:47 2018 C:\WINDOWS\system32\route.exe ADD 192.168.188.0 MASK 255.255.255.0 10.8.8.1 METRIC 1
Wed Mar 14 12:18:47 2018 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Wed Mar 14 12:18:47 2018 Route addition via IPAPI succeeded [adaptive]
Wed Mar 14 12:18:47 2018 Initialization Sequence Completed
Wed Mar 14 12:18:47 2018 MANAGEMENT: >STATE:1521026327,CONNECTED,SUCCESS,10.8.8.3,35.14.21.23,1194,,

Client

Wed Mar 14 12:18:41 2018 us=848791 MULTI: multi_create_instance called
Wed Mar 14 12:18:41 2018 us=848791 35.14.21.23:9720 Re-using SSL/TLS context
Wed Mar 14 12:18:41 2018 us=848791 35.14.21.23:9720 LZO compression initializing
Wed Mar 14 12:18:41 2018 us=848791 35.14.21.23:9720 Control Channel MTU parms [ L:1658 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Wed Mar 14 12:18:41 2018 us=848791 35.14.21.23:9720 Data Channel MTU parms [ L:1658 D:1472 EF:126 EB:412 ET:32 EL:3 ]
Wed Mar 14 12:18:41 2018 us=848791 35.14.21.23:9720 Fragmentation MTU parms [ L:1658 D:1472 EF:125 EB:412 ET:33 EL:3 ]
Wed Mar 14 12:18:41 2018 us=848791 35.14.21.23:9720 Local Options String (VER=V4): 'V4,dev-type tap,link-mtu 1578,tun-mtu 1532,proto UDPv4,comp-lzo,mtu-dynamic,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'  
Wed Mar 14 12:18:41 2018 us=848791 35.14.21.23:9720 Expected Remote Options String (VER=V4): 'V4,dev-type tap,link-mtu 1578,tun-mtu 1532,proto UDPv4,comp-lzo,mtu-dynamic,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'  
Wed Mar 14 12:18:41 2018 us=848791 35.14.21.23:9720 TLS: Initial packet from [AF_INET]35.14.21.23:9720, sid=541c2a9c 9a19d234
Wed Mar 14 12:18:42 2018 us=51908 35.14.21.23:9720 VERIFY OK: depth=1, C=DE, ST=NRW, L=bochum, O=o, OU=ou, CN=server, name=server, emailAddress=server@test.de
Wed Mar 14 12:18:42 2018 us=51908 35.14.21.23:9720 VERIFY OK: depth=0, C=DE, ST=NRW, L=bochum, O=o, OU=it, CN=client2, name=client2, emailAddress=client2@test.com
Wed Mar 14 12:18:42 2018 us=130042 35.14.21.23:9720 peer info: IV_VER=2.4.0
Wed Mar 14 12:18:42 2018 us=130042 35.14.21.23:9720 peer info: IV_PLAT=win
Wed Mar 14 12:18:42 2018 us=130042 35.14.21.23:9720 peer info: IV_PROTO=2
Wed Mar 14 12:18:42 2018 us=130042 35.14.21.23:9720 peer info: IV_NCP=2
Wed Mar 14 12:18:42 2018 us=130042 35.14.21.23:9720 peer info: IV_LZ4=1
Wed Mar 14 12:18:42 2018 us=130042 35.14.21.23:9720 peer info: IV_LZ4v2=1
Wed Mar 14 12:18:42 2018 us=130042 35.14.21.23:9720 peer info: IV_LZO=1
Wed Mar 14 12:18:42 2018 us=130042 35.14.21.23:9720 peer info: IV_COMP_STUB=1
Wed Mar 14 12:18:42 2018 us=130042 35.14.21.23:9720 peer info: IV_COMP_STUBv2=1
Wed Mar 14 12:18:42 2018 us=130042 35.14.21.23:9720 peer info: IV_TCPNL=1
Wed Mar 14 12:18:42 2018 us=130042 35.14.21.23:9720 peer info: IV_GUI_VER=OpenVPN_GUI_11
Wed Mar 14 12:18:42 2018 us=223801 35.14.21.23:9720 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Wed Mar 14 12:18:42 2018 us=223801 35.14.21.23:9720 [client2] Peer Connection Initiated with [AF_INET]35.14.21.23:9720
Wed Mar 14 12:18:42 2018 us=223801 client2/35.14.21.23:9720 MULTI_sva: pool returned IPv4=10.8.8.3, IPv6=(Not enabled)
Wed Mar 14 12:18:43 2018 us=286443 client2/35.14.21.23:9720 PUSH: Received control message: 'PUSH_REQUEST'  
Wed Mar 14 12:18:43 2018 us=286443 client2/35.14.21.23:9720 SENT CONTROL [client2]: 'PUSH_REPLY,route 192.168.188.0 255.255.255.0 10.8.8.1 1,dhcp-option 10.8.8.1,dhcp-option 192.168.188.1,dhcp-option 192.168.188.105,ping 10,ping-restart 120,ifconfig 10.8.8.3 255.255.255.0,peer-id 1,cipher AES-256-GCM' (status=1)  
Wed Mar 14 12:18:43 2018 us=286443 client2/35.14.21.23:9720 Data Channel: using negotiated cipher 'AES-256-GCM'  
Wed Mar 14 12:18:43 2018 us=286443 client2/35.14.21.23:9720 Data Channel MTU parms [ L:1586 D:1472 EF:54 EB:412 ET:32 EL:3 ]
Wed Mar 14 12:18:43 2018 us=286443 client2/35.14.21.23:9720 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Wed Mar 14 12:18:43 2018 us=286443 client2/35.14.21.23:9720 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Wed Mar 14 12:18:43 2018 us=505217 client2/35.14.21.23:9720 MULTI: Learn: 00:ff:b3:58:81:de -> client2/35.14.21.23:9720
Wed Mar 14 12:18:49 2018 us=711246 client2/35.14.21.23:9720 PID_ERR replay-window backtrack occurred [1] [SSL-0] [0_0000000000_111111111111222222222222223333333333333333333333444] 0:98 0:97 t=1521026329 r=[-1,64,15,1,1] sl=[30,64,64,528]

Auffälig ist der Fehler: PID_ERR replay-window backtrack occurred
und dhcp-option: unknown option type.

Bridging mit tap ist tödlich für die Performance. Ist auch klar, denn dann belastet der gesamten Broad- und Multicast Traffic beider Seiten massiv den VPN Tunnel.
Deshalb rät auch OpenVPN immer vom Bridging ab und empfiehlt grundsätzlich ein Routing über tun Interfaces.
Es gilt die alte Regel: "Route where you can, bridge where you must" !

Wie realisiert sich der Umstieg auf TUN, einfach im Editor, TUN aktivieren und den Adapter umbenennen?

Ja !
Halte dich an dies Tutorial:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die OVPN Konfig ist auf allen Plattformen immer gleich.

Ja !

Alles klar, werde mal angehen.

Die OVPN Konfig ist auf allen Plattformen immer gleich.

Alles klar, mir sind ein paar Änderungen aufgefallen auf deinem Tutorial.

Auf der Server Konfig

tls-server

Fehlt bei dir, ist das nicht notwendig in einem Netzwerk ohne Server?

dev-node openvpn

Fehlt auch, bei TUN nicht notwendig?

client-to-client

Fehlt auch, denke nicht erforderlich.

Client Konfig

dev-node TAP

Fehlt denke auch weil du bei der Server Konfig es weggelassen hast.

tls-client

Fehlt ebenfalls wie auch oben bei der Server Konfig.

Seit gestern habe ich auch die neue OVPN Version 2.4.5 installiert allerdings konnte keine Verbindung aufbauen, deswegen wieder auf die ältere zurückgesetzt.

Die Fehlermeldungen waren:

Tue Mar 20 09:16:46 2018 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Tue Mar 20 09:16:46 2018 OpenSSL: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
Tue Mar 20 09:16:46 2018 MANAGEMENT: Client disconnected
Tue Mar 20 09:16:46 2018 Cannot load certificate file C:\\Program Files\\OpenVPN\\config\\Zumtesten.crt
Tue Mar 20 09:16:46 2018 Exiting due to fatal error

Müsste ich die CA neu erstellen mit einer neueren OpenSSL Version?

Fehlt bei dir, ist das nicht notwendig in einem Netzwerk ohne Server?

Was genau meinst du mit "Netzwerk ohne Server" ??? Ohne VPN Server ? Sowas gibts ja nicht ?
Aber was für einen "Server" meinst du denn ??
VPNs gehören eigentlich auch niemals ins Netz sondern auf die Peripherie wie Router oder Firewall. Logisch, denn mit einem internen Server musst du Löcher in die Firewall bohren um Internet Traffic (VPN) auf den Server zu lassen.
Immer ein suboptimales Design wie du dir denken kannst !
Die TLS Role Zuweisung kann man machen...muss es aber nicht. In eine klassische Konfig muss es nicht zwingend rein:
https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
Der dev-node ist überflüssig wenn man empfohlenermaßen routet mit tun, kann also ersatzlos entfallen.
client-to-client muss nur rein wenn man auch eine direkte Kommunikation der VPN Clients untereinander will.
Bei einem rein zentralisierten VPN also Client immer auf Server kann das natürlich entfallen. Ist auch immer eine Security Frage und muss man nach Anwendung und Sicherheit immer individuell entscheiden.

Die CA muss normalerweis enicht neu wenn du Root Zert. sowie Server und Client Zert gesichert hast. Es kann aber nicht schaden.
Deinen Fehlermeldung sagt das das Zertifikat gar nicht geladen werden konnte. Entweder weil es fehlt oder der Pfad dahin unbekannt oder verboten ist.
Da ist natürlich klar das eine Verbindung sofort scheitert wenn es schon an solchen einfachen Basics hapert

Das Karres Tutorial beschreibt diese Schritte ja auch nochmals genau.

Die OVPN Konfig ist auf allen Plattformen immer gleich.

Richtig, das Prinzip ist gleich, nur ist bei den Pfaden nicht immer alles identisch. Hier bestehen Unterschiede, z.B. zwischen Linux und FreeBSD-Plattformen, wie beispielsweise zwischen einem DD-WRT Router und einer pfSense.
Bei der Übernahme einer Fremd-config ist also Vorsicht geboten. Also nicht vergessen die Pfade zu prüfen.
Hier einmal als Vergleich die Server.conf eines pfSense (FreeBSD) OpenVPN unter /var/etc/openvpn/server1

dev ovpns1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.219.2
tls-server
server 10.10.8.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server1
ifconfig 10.10.8.1 10.10.8.2
server1.conf: unmodified: line 1

Dabei verweist folgende Zeile auf ein File, welche Informationen für den Client übergibt.

client-config-dir /var/etc/openvpn-csc/server1

Hier die Config eines dazu gehörigen OpenVPN-Client, eines Linux-Routers auf OpenWRT-Basis, bei dem OpenVPN unter /etc/openvpn zu finden ist. Die Pfade bei einer DD-WRT sind dann z.B. unter /tmp/zu finden.

client
dev tun
proto udp
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
persist-tun
persist-key
tun-mtu 1342
# link-mtu 1430
cipher AES-256-CBC
auth SHA1
tls-client
tls-auth /etc/openvpn/ta.key 1
resolv-retry infinite
# remote 152.15.6.77 1194
remote müller.dd-dns.de 1194
verify-x509-name "dedalus" name  
ns-cert-type server
comp-lzo adaptive

Bei Dir scheint ein TLS-Fehler vorzuliegen, also poste noch einmal die aktuelle config. So bald Du den Tunnel zum laufen gebracht hast, wären auch die Routing-Protokolle interessant.
Gruss orcape

Was genau meinst du mit "Netzwerk ohne Server" ??? Ohne VPN Server ? Sowas gibts ja nicht ?

Mit Server meinte ich eher, ein Netzwerkdomäne, was bei mir ja nicht der Fall ist, auf der neuen Konfiguration.
Von da wo ich die Einstellungen übernommen habe war es eine Netzwerkdomäne.

Deinen Fehlermeldung sagt das das Zertifikat gar nicht geladen werden konnte. Entweder weil es fehlt oder der Pfad dahin unbekannt oder verboten ist.

Das interessante ist, dass mit der Version 2.4.4 die Verbindung zustande kommt mit den folgenden Fehlermeldungen:

Wed Mar 21 17:06:35 2018 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.

Wed Mar 21 16:54:03 2018 WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Wed Mar 21 16:54:03 2018 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication  
Wed Mar 21 16:54:03 2018 Incoming Data Channel: Cipher 'BF-CBC' initialized with 128 bit key  
Wed Mar 21 16:54:03 2018 WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Wed Mar 21 16:54:03 2018 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication  
Wed Mar 21 16:54:03 2018 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.

Nach dem update auf 2.4.5
dann die folgenden, wie oben gepostet und die Verbindung mit den selben Konfigs klappt nicht:

Wed Mar 21 17:08:16 2018 OpenVPN 2.4.5 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Mar  1 2018
Wed Mar 21 17:08:16 2018 Windows version 6.1 (Windows 7) 64bit
Wed Mar 21 17:08:16 2018 library versions: OpenSSL 1.1.0f  25 May 2017, LZO 2.10
Enter Management Password:
Wed Mar 21 17:08:16 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Mar 21 17:08:16 2018 Need hold release from management interface, waiting...
Wed Mar 21 17:08:17 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Mar 21 17:08:17 2018 MANAGEMENT: CMD 'state on'  
Wed Mar 21 17:08:17 2018 MANAGEMENT: CMD 'log all on'  
Wed Mar 21 17:08:17 2018 MANAGEMENT: CMD 'echo all on'  
Wed Mar 21 17:08:17 2018 MANAGEMENT: CMD 'bytecount 5'  
Wed Mar 21 17:08:17 2018 MANAGEMENT: CMD 'hold off'  
Wed Mar 21 17:08:17 2018 MANAGEMENT: CMD 'hold release'  
Wed Mar 21 17:08:17 2018 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Wed Mar 21 17:08:17 2018 OpenSSL: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
Wed Mar 21 17:08:17 2018 MANAGEMENT: Client disconnected
Wed Mar 21 17:08:17 2018 Cannot load certificate file C:\\Program Files\\OpenVPN\\config\\Client2.crt
Wed Mar 21 17:08:17 2018 Exiting due to fatal error

Da ist eine Änderung mit dem Update die, die Passwort Abfrage verhindert, bei unveränderten Konfigs.

Bei Dir scheint ein TLS-Fehler vorzuliegen, also poste noch einmal die aktuelle config. So bald Du den Tunnel zum laufen gebracht hast, wären auch die Routing-Protokolle interessant.

Ok, komischerweise, wie erwähnt erst ab der 2.4.5 Version

Die Konfigs sind gleich geblieben wie oben gepostet:

01.
client 
dev tap 
dev-node TAP 
proto udp4 
remote 35.14.21.23 1194 
resolv-retry infinite 
nobind 
persist-key 
persist-tun 
tls-client 
ca 'C:\\Program Files\\OpenVPN\\config\\ca.crt'   
cert 'C:\\Program Files\\OpenVPN\\config\\client2.crt'   
key 'C:\\Program Files\\OpenVPN\\config\\client2.key'   
ns-cert-type server 
comp-lzo 
verb 3 
script-security 2 
mute 50 
pull 
tun-mtu 1500 
tun-mtu-extra 32 
fragment 1472 
mssfix 
auth-nocache

Server

local 192.168.77.100

port 1194

proto udp
mode server
tls-server

dev tap
dev-node openvpn

ca c://programme//openvpn//keys//ca.crt
cert c://programme//openvpn//keys//server.crt
key c://programme//openvpn//keys//server.key

dh c://programme//openvpn//config//dh2048.pem

ifconfig 10.8.8.1 255.255.255.0
ifconfig-pool 10.8.8.2 10.8.8.250

ifconfig-pool-persist ipp.txt

push "route 192.168.77.0 255.255.255.0 10.8.8.1 1"  

push "dhcp-option DOMAIN random"  
push "dhcp-option DNS 10.8.8.1"  
push "dhcp-option DNS 192.168.77.100"  
push "dhcp-option DNS 192.168.77.101"  

client-to-client

keepalive 10 120

comp-lzo

max-clients 20

persist-key
persist-tun

status openvpn-status.log

log-append  openvpn.log

verb 4

tun-mtu 1500
tun-mtu-extra 32
fragment 1472
mssfix
crl-verify c://programme//openvpn//config//crl.pem
ip-win32 dynamic

Gruß
intane

Von da wo ich die Einstellungen übernommen habe war es eine Netzwerkdomäne.

Das ist für OpenVPN eh uninteressant, da es nichts von MS und "Domänen" kennt, diese also quasi ignoriert.

dass mit der Version 2.4.4 die Verbindung zustande kommt mit den folgenden Fehlermeldungen:

Das ist schon mal gut !

Nach dem update auf 2.4.5

OK, er meckert das 128Bit Schlüssel etwas schwach sind und empfiehlt dir hier 256 was ja heute Standard ist. Das ist aber nur ne Warnung.
Gravierender ist "Cannot load certificate file C:\\Program Files\\OpenVPN\\config\\Tzanoudakis.crt"
Denn das sagt ja ganz klar das er auf das Zertifikat NICHT zugreifen kann.
Entweder gibt es also

den Pfad dahin "C:\Program Files\OpenVPN\config\" gar nicht bzw. die Verzeichnisse existieren nicht
die Zugriffsrechte dahin fehlen
die Zert Datei Tzanoudakis.crt fehlt
oder die Leserecht darauf fehlen.

Da ist die Fehlermeldung eindeutig ! und DA solltest du auch ansetzen.
Und...
Lass doch mal den ganz überflüssigen Unsinn mit local, dev-node, ifconfig, ifconfig-pool-persist, push "dhcp-option, mssfix, crl-verify, ip-win32 usw. weg ! Das verschlimmbessert alles nur und OpenVPN hat dort sinnvolle Default Settings. Keep it simple and stupid...!
Außerdem arbeitest du hier ja schon wieder mit dem üblen tap Interfaces also Bridging

Du willst doch jetzt sinnvolles und empfohlenes Routing machen, oder ?
Da sind tun Kommandos wie tun-mtu dann so oder so Unsinn. 1500 Byte im Tunnel sowieso da es eh Dewfault ist und das Kommando entfallen kann. Abgesehen davon ist es auch falsch !!:
http://wohnzimmerhostblogger.de/archives/1563-OpenVPN-und-MTU-1500.html

Hi intane,
wie das Dir @aqui gerade so schön, wohl zum wiederholten mal erzählt hat, machst Du grundlegende Fehler.
Auf Tipps gehst Du überhaupt nicht ein und verwendest wohl immer noch die ursprüngliche .config.
Entscheide Dich für das tun-Device, lass unnötige Sachen, die nicht benötigt werden weg, so zum Beispiel auch das client-to-client. Das kreiert Dir nur einen Multiclienttunnel und bringt die nächsten Probleme mit sich.
Überprüfe die Pfade und checke Fehlermeldungen die in den logs auftauchen, dann sollte das auch klappen.
Gruss orcape

Huhu, sry wieder für die lange Abwesenheit.
Hab mich wieder an dem Thema rangesetzt und eure Lösungsvorschläge auf tun angeschaut und angewandt.

Leider bekomme ich eine Fehlermeldung, beim Versuch ins richtige Netz zu kommen.

Thu Apr 12 11:06:47 2018 WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'  
Thu Apr 12 11:06:47 2018 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1546', remote='link-mtu 1578'  
Thu Apr 12 11:06:47 2018 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'  
Thu Apr 12 11:06:47 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Apr 12 11:06:47 2018 [cteserver] Peer Connection Initiated with [AF_INET]84.135.54.70:1194
Thu Apr 12 11:06:48 2018 MANAGEMENT: >STATE:1523524008,GET_CONFIG,,,,,,
Thu Apr 12 11:06:48 2018 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)  
Thu Apr 12 11:06:48 2018 PUSH: Received control message: 'PUSH_REPLY,route 192.168.188.0 255.255.255.0 10.8.8.1 1,dhcp-option 10.8.8.1,dhcp-option 192.168.188.1,dhcp-option 192.168.188.105,ping 10,ping-restart 120,ifconfig 10.8.8.3 255.255.255.0,peer-id 0,cipher AES-256-GCM'  
Thu Apr 12 11:06:48 2018 Options error: --dhcp-option: unknown option type '10.8.8.1' or missing or unknown parameter  
Thu Apr 12 11:06:48 2018 Options error: --dhcp-option: unknown option type '192.168.188.1' or missing or unknown parameter  
Thu Apr 12 11:06:48 2018 Options error: --dhcp-option: unknown option type '192.168.188.105' or missing or unknown parameter  
Thu Apr 12 11:06:48 2018 OPTIONS IMPORT: timers and/or timeouts modified
Thu Apr 12 11:06:48 2018 OPTIONS IMPORT: --ifconfig/up options modified
Thu Apr 12 11:06:48 2018 OPTIONS IMPORT: route options modified
Thu Apr 12 11:06:48 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Apr 12 11:06:48 2018 OPTIONS IMPORT: peer-id set
Thu Apr 12 11:06:48 2018 OPTIONS IMPORT: adjusting link_mtu to 1629
Thu Apr 12 11:06:48 2018 OPTIONS IMPORT: data channel crypto options modified
Thu Apr 12 11:06:48 2018 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key  
Thu Apr 12 11:06:48 2018 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key  
Thu Apr 12 11:06:48 2018 WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address.  You are using something (255.255.255.0) that looks more like a netmask. (silence this warning with --ifconfig-nowarn)
Thu Apr 12 11:06:48 2018 MANAGEMENT: Client disconnected
Thu Apr 12 11:06:48 2018 There is a problem in your selection of --ifconfig endpoints [local=10.8.8.3, remote=255.255.255.0].  The local and remote VPN endpoints must exist within the same 255.255.255.252 subnet.  This is a limitation of --dev tun when used with the TAP-WIN32 driver.  Try 'openvpn --show-valid-subnets' option for more info.  
Thu Apr 12 11:06:48 2018 Exiting due to fatal error

Das interessante ist, dass ich ifconfig und dhcp option etc. alles rausgeschmissen habe, es scheint mir als ob er die Konfiguration, noch irgendwo außerhalb der server config gespeichert hat.

Anbei noch die neuen configs.

Server

proto udp

dev tun0

ca c://programme//openvpn//easy-rsa//keys//ca.crt
cert c://programme//openvpn//easy-rsa//keys//server.crt
key c://programme//openvpn//easy-rsa//keys//server.key 
dh c://programme//openvpn//config//dh2048.pem

server 10.8.8.0 255.255.255.0

keepalive 10 120

comp-lzo

persist-key
persist-tun


log-append  openvpn.log

verb 3

Client

client
dev tun
proto udp
remote 84.135.54.70 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca 'C:\\Program Files\\OpenVPN\\config\\ca.crt'  
cert 'C:\\Program Files\\OpenVPN\\config\\Client2.crt'  
key 'C:\\Program Files\\OpenVPN\\config\\Client2.key'  
fragment 1472
ns-cert-type server
comp-lzo
verb 3

Ich hab auch beim Server mit verschiedenen push Einstellungen getestet, wie im HOWTO oder in deiner Anleitung zu stehen sind, aber glaube der Fehler liegt, dass er nicht die richtige config öffnet beim Verbindungsaufbau.
Die Server config liegt unter C:\Program Files\OpenVPN\config und da liegt keine andere config, kann es sein, dass er noch die alte config von irgendwo lädt?
Also die Verbindung wird bis dahin aufgebaut.

Gruß
intane

Entscheide Dich für das tun-Device, lass unnötige Sachen, die nicht benötigt werden weg, so zum Beispiel auch das client-to-client. Das kreiert Dir nur einen Multiclienttunnel und bringt die nächsten Probleme mit sich.

Wurde weggelassen

leider klappt die Verbindung mit tun noch nicht.

Gruß
intane

Ja, das scheint zu stimmen. Die Server Konfig Datei die gestartet wird ist scheinbar NICHT die die du konfiguriert hast.
Das ist sicher, denn das zeigen die Parameter im Log die es in deiner Konfig Datei gar nicht mehr gibt !
Der holt die Konfig Datei irgendwo anderes her !!! Jedenfalls ist das nicht die von dir erstellte.

leider klappt die Verbindung mit tun noch nicht.

Das ist dann logisch wenn die Konfig Datei falsch ist !
fragment 1472 solltest du erstmal entfernen !

Normal liegt die Konfig Datei in /etc/openvpn. Wenn du sie woanders hast findet OpenVPN sie nicht.
Wo das Default Verzeichnis ist, ist in /etc/default/openvpn festgelegt also ggf. mal kontrollieren !
Du kannst aber OVPN auch mal manuell mit der dedizierten Angabe der Konfig Datei starten.

Dazu musst du den OVPN Prozess erst stoppen mit systemctl stop openvpn (bei systemd) oder mit /etc/init.d/openvpn stop oder auch service openvpn stop.
Danach kannst du mit openvpn /pfad/config.datei oder openvpn --config /pfad/config.datei händisch starten und das erzwingt dann das Laden deiner spezifischen Konfig Datei /pfad/config.datei mit dem kompletten Pfad dorthin.

Das ist dann logisch wenn die Konfig Datei falsch ist !
fragment 1472 solltest du erstmal entfernen !

ok hab ich, das war noch drin, weil das fürs bridging notwendig war, sonnst kam da ne Fehlermeldung mit:
Bad LZO decompression header byte
Aber wir bridgen ja nicht mehr ;)

Danach kannst du mit openvpn /pfad/config.datei oder openvpn --config /pfad/config.datei händisch starten und das erzwingt dann das Laden deiner spezifischen Konfig Datei /pfad/config.datei mit dem kompletten Pfad dorthin.

Das hat irgendwie über cmd nicht geklappt, die cmd spuckte raus, dass sie openvpn als Befehl bzw. --config nicht kennt, aber nicht allzu schlimm hab den Dienst über "Dienste" neugestartet" und es scheint, dass er die neue konfig übernommen hat.
Das icon wird grün, allerdings bin ich glaube nicht im Subnetz des Servers, kann den Server über RDP nicht erreichen, was über bridging ging.
Müsste ich da noch eine Route festlegen?

Thu Apr 12 13:19:19 2018 OpenVPN 2.4.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jan 31 2017
Thu Apr 12 13:19:19 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Thu Apr 12 13:19:19 2018 library versions: OpenSSL 1.0.2k  26 Jan 2017, LZO 2.09
Thu Apr 12 13:19:19 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Thu Apr 12 13:19:19 2018 Need hold release from management interface, waiting...
Thu Apr 12 13:19:19 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Thu Apr 12 13:19:19 2018 MANAGEMENT: CMD 'state on'  
Thu Apr 12 13:19:19 2018 MANAGEMENT: CMD 'log all on'  
Thu Apr 12 13:19:19 2018 MANAGEMENT: CMD 'hold off'  
Thu Apr 12 13:19:19 2018 MANAGEMENT: CMD 'hold release'  
Thu Apr 12 13:19:19 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]84.135.54.70:1194
Thu Apr 12 13:19:19 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Thu Apr 12 13:19:19 2018 UDP link local: (not bound)
Thu Apr 12 13:19:19 2018 UDP link remote: [AF_INET]84.135.54.70:1194
Thu Apr 12 13:19:19 2018 MANAGEMENT: >STATE:1523531959,WAIT,,,,,,
Thu Apr 12 13:19:20 2018 MANAGEMENT: >STATE:1523531960,AUTH,,,,,,
Thu Apr 12 13:19:20 2018 TLS: Initial packet from [AF_INET]84.135.54.70:1194, sid=3ced3774 709577cd
Thu Apr 12 13:19:20 2018 VERIFY OK: depth=1, C=DE, ST=NRW, L=Bochum, O=ct, OU=ct, CN=server, name=server, emailAddress=ct
Thu Apr 12 13:19:20 2018 VERIFY OK: nsCertType=SERVER
Thu Apr 12 13:19:20 2018 VERIFY OK: depth=0, C=DE, ST=NRW, L=Bochum, O=ct, OU=ct, CN=server, name=server, emailAddress=ct
Thu Apr 12 13:19:20 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Apr 12 13:19:20 2018 [server] Peer Connection Initiated with [AF_INET]84.135.54.70:1194
Thu Apr 12 13:19:21 2018 MANAGEMENT: >STATE:1523531961,GET_CONFIG,,,,,,
Thu Apr 12 13:19:21 2018 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)  
Thu Apr 12 13:19:21 2018 PUSH: Received control message: 'PUSH_REPLY,route 10.8.8.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.8.6 10.8.8.5,peer-id 0,cipher AES-256-GCM'  
Thu Apr 12 13:19:21 2018 OPTIONS IMPORT: timers and/or timeouts modified
Thu Apr 12 13:19:21 2018 OPTIONS IMPORT: --ifconfig/up options modified
Thu Apr 12 13:19:21 2018 OPTIONS IMPORT: route options modified
Thu Apr 12 13:19:21 2018 OPTIONS IMPORT: peer-id set
Thu Apr 12 13:19:21 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Thu Apr 12 13:19:21 2018 OPTIONS IMPORT: data channel crypto options modified
Thu Apr 12 13:19:21 2018 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key  
Thu Apr 12 13:19:21 2018 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key  
Thu Apr 12 13:19:21 2018 interactive service msg_channel=0
Thu Apr 12 13:19:21 2018 ROUTE_GATEWAY 192.168.33.254/255.255.255.0 I=7 HWADDR=3c:97:0e:cd:4c:ae
Thu Apr 12 13:19:21 2018 open_tun
Thu Apr 12 13:19:21 2018 TAP-WIN32 device [TAP] opened: \\.\Global\{F25781DE-AB88-4C05-9A3A-1C7B425DDA67}.tap
Thu Apr 12 13:19:21 2018 TAP-Windows Driver Version 9.21 
Thu Apr 12 13:19:21 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.8.6/255.255.255.252 on interface {F25781DE-AB88-4C05-9A3A-1C7B425DDA67} [DHCP-serv: 10.8.8.5, lease-time: 31536000]
Thu Apr 12 13:19:21 2018 Successful ARP Flush on interface [18] {F25781DE-AB88-4C05-9A3A-1C7B425DDA67}
Thu Apr 12 13:19:21 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Apr 12 13:19:21 2018 MANAGEMENT: >STATE:1523531961,ASSIGN_IP,,10.8.8.6,,,,
Thu Apr 12 13:19:26 2018 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Thu Apr 12 13:19:26 2018 MANAGEMENT: >STATE:1523531966,ADD_ROUTES,,,,,,
Thu Apr 12 13:19:26 2018 C:\WINDOWS\system32\route.exe ADD 10.8.8.1 MASK 255.255.255.255 10.8.8.5
Thu Apr 12 13:19:26 2018 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Thu Apr 12 13:19:26 2018 Route addition via IPAPI succeeded [adaptive]
Thu Apr 12 13:19:26 2018 Initialization Sequence Completed
Thu Apr 12 13:19:26 2018 MANAGEMENT: >STATE:1523531966,CONNECTED,SUCCESS,10.8.8.6,84.135.54.70, 1194,,

Außerdem benutzt er immer noch den TAP Adapter, oder ist normal auch bei tun, dass er über den Adapter die Verbindung aufbaut?

in der konfig die Zeile :
push "route 192.168.188.0 255.255.255.0"

aber klappt die Verbindung per RDP zum Server klappt noch nicht.

...
Thu Apr 12 14:02:20 2018 interactive service msg_channel=0
Thu Apr 12 14:02:20 2018 ROUTE_GATEWAY 192.168.33.254/255.255.255.0 I=7 HWADDR=3c:97:0e:cd:4c:ae
Thu Apr 12 14:02:20 2018 open_tun
Thu Apr 12 14:02:20 2018 TAP-WIN32 device [TAP] opened: \\.\Global\{F25781DE-AB88-4C05-9A3A-1C7B425DDA67}.tap
Thu Apr 12 14:02:20 2018 TAP-Windows Driver Version 9.21 
Thu Apr 12 14:02:20 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.8.6/255.255.255.252 on interface {F25781DE-AB88-4C05-9A3A-1C7B425DDA67} [DHCP-serv: 10.8.8.5, lease-time: 31536000]
Thu Apr 12 14:02:20 2018 Successful ARP Flush on interface [18] {F25781DE-AB88-4C05-9A3A-1C7B425DDA67}
Thu Apr 12 14:02:20 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Apr 12 14:02:20 2018 MANAGEMENT: >STATE:1523534540,ASSIGN_IP,,10.8.8.6,,,,
Thu Apr 12 14:02:25 2018 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Thu Apr 12 14:02:25 2018 MANAGEMENT: >STATE:1523534545,ADD_ROUTES,,,,,,
Thu Apr 12 14:02:25 2018 C:\WINDOWS\system32\route.exe ADD 192.168.188.0 MASK 255.255.255.0 10.8.8.5
Thu Apr 12 14:02:25 2018 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Thu Apr 12 14:02:25 2018 Route addition via IPAPI succeeded [adaptive]
Thu Apr 12 14:02:25 2018 C:\WINDOWS\system32\route.exe ADD 10.8.8.1 MASK 255.255.255.255 10.8.8.5
Thu Apr 12 14:02:25 2018 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Thu Apr 12 14:02:25 2018 Route addition via IPAPI succeeded [adaptive]
Thu Apr 12 14:02:25 2018 Initialization Sequence Completed
Thu Apr 12 14:02:25 2018 MANAGEMENT: >STATE:1523534545,CONNECTED,SUCCESS,10.8.8.6,93.226.128.143,1194,,

Gruß
intane

dass sie openvpn als Befehl bzw. --config nicht kennt,

Mit doppeltem Bindestrich - - ! Kannst es aber wie gesagt auch so machen das du nach dem openvpn Kommando den Pfad nur durch ein Blank (Leerschritt) separierst.

Server sieht aber jetzt mit "Initialization Sequence Completed " sehr gut aus !!

benutzt er immer noch den TAP Adapter,

Ist der Server nu gruselige Winblows Gurke ? Dann ist das normal.

CONNECTED,SUCCESS,10.8.8.6,93.226.128.143,1194,,

Der Client sieht auch sehr gut aus !! Mit Open VPN selber ist also alles bestens

aber klappt die Verbindung per RDP zum Server klappt noch nicht.

Wenn der Server und auch der Client Winblows ist hast du noch 2 Hürden zu nehmen !!
Wegen der auf dem virtuellen OVPN Adapter fehlschlagenden Netzwerk Erkennung dekalriert Windows den Adapter als öffentliches Interface in seiner lokalen Firewall. Damit sind dann alle Verbindungen von außen blockiert.
Hier bleibt also Ping, RDP usw. schon mal per se stecken.
Du musst also zwingend den Adapter im Firewall Setup in ein Privates Netzwerk Profil umkonfigurieren.
(Firewall mit erweiterten Eigenschaften im Suchfeld)
Das wäre der erste Schritt.
Für Ping (ICMP) musst du zusätzlich noch den Zugriff generell in der Firewall erlauben:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Auch der RDP Prozess blockiert den Zugriff von fremden Netzen in der Firewall !
Auch hier musst du zwingend das 10er VPN Netz (oder alle) zulassen.
Ohne das wird dir die Firewall alles blocken auf Server und Client Seite.
Das ist deine letzte Hürde zum Erfolg !

Das ist deine letzte Hürde zum Erfolg !

Das hört sich schon mal gut an

werde gleich versuchen die Einstellungen durchzuführen.

Gruß
intane

Konnte leider die letzten zwei Hürden noch nicht bezwingen.

Du musst also zwingend den Adapter im Firewall Setup in ein Privates Netzwerk Profil umkonfigurieren.

Somit erledigt.

Für Ping (ICMP) musst du zusätzlich noch den Zugriff generell in der Firewall erlauben

Ebenso
Der Ping klappt allerdings nur bis zum 10er Netz:

Das 192.168.188.0er findet er dagegen nicht.

Auch der RDP Prozess blockiert den Zugriff von fremden Netzen in der Firewall !

Sieht denke auch gut aus.

Auch hier musst du zwingend das 10er VPN Netz (oder alle) zulassen.

Neue Regel erstellt, wo das 10er Netz komplett frei ist.

Ohne das wird dir die Firewall alles blocken auf Server und Client Seite.

Auf dem Client hab ich jetzt bei meiner Firewall bei den ausgehenden Regeln nichts gravierendes dagegen gefunden.
Eventuell beim Client, doch was erlauben?
Beim Bridging war es bis jetzt nicht nötig, aber ist ja ein anderes Verfahren.

Was mir auffiel ist es auch, dass es kein Unterschied macht bei dem Verbindungsaufbau ob die Zeile bei der Server Konfig da ist oder nicht: push "route 192.168.188.0 255.255.255.0"

ob die Zeile bei der Server Konfig da ist oder nicht: push "route 192.168.188.0 255.255.255.0"

WIE hast du das getestet ??
Das kannst du nur sehen wenn du bei aktivem VPN Client dir mal die Routing Tabelle mit route print ansiehst !
Ohne das push route.. Kommando sollte das Netzwerk 192.168.188.0 /24 logischerweise fehlen in der Routing Tabelle. Pakete dahin gehen dann über die Default Route...und damit ins Nirwana.

"Nicht identifiziert" oben ist eher Öffentlich, was dann wieder Blocking heisst.
Bei den ICMP Regeln musst du aufpassen, oft sind die auf lokal gesetzt und sollten aber auf Beliebig stehen:

Deshalb solltest du auch oben in den Eigenschaften alles erstmal auf Beliebig einstellen um sicherzugehen das nicht gefiltert wird.
Dichtmachen kann man das später imme rnoch.
Es ist nur noch die Win Firewall !

Das kannst du nur sehen wenn du bei aktivem VPN Client dir mal die Routing Tabelle mit route print ansiehst !
Ohne das push route.. Kommando sollte das Netzwerk 192.168.188.0 /24 logischerweise fehlen in der Routing Tabelle. Pakete dahin gehen dann über die Default Route...und damit ins Nirwana.

ohne push Route:
Client

Server

Mit Push
Client

Server

"Nicht identifiziert" oben ist eher Öffentlich, was dann wieder Blocking heisst.

Erledigt

Bei den ICMP Regeln musst du aufpassen, oft sind die auf lokal gesetzt und sollten aber auf Beliebig stehen:

Unter den GPOs das öffnetliche zu privat deklariert

Leider komme ich immer noch nicht durch, damit ich pingen kann bzw. RDP benutzen kann.
Eventuell eine zusätzliche Route hinzufügen?

Gruß
intane

Wie erwartet. Die 192.168.188.0 wird sauber injiziert in die Routing Tabelle am Client auch via Adapter Nummer "35" was der virtuelle Tunnel Adapter ist. Siehst du ja auch selber.
Das ist also alles OK. Ein Traceroute (tracert) sollte also bei aktivem VPN immer den Weg via 10.8.8.0 dahin wählen.
Zeigt das das Routing korrekt funktioniert. Daran liegt es nicht.
Das die Route in der Routing Tabelle steht zeigt zudem das der Tunnel fehlerfrei aufgebaut wurde also auch das VPN an sich fehlerfrei funktioniert.

Eventuell eine zusätzliche Route hinzufügen?

Nein. Warum denn auch ? Das interne VPN Netz ist ja in der Tabelle und das remote lokale LAN werden auch sauber propagiert zum Client. Kannst du ja selber sehen in der Routing Tabelle ! Welche IP netze solltest du also noch routen wollen ? Gibt ja keine mehr wenn alle da sind !

Frage: Kannst du denn wenigstens das lokale LAN Interface 192.168.188.105 des Servers vom Client pingen ?
Ein Ping des direkten Server interfaces 10.8.8.5 klappt aber, oder ?

Das kann eigentlich nur noch an der lokalen Windows Firewall liegen !
Denk dran das du diese Firewall Einstellungen auf BEIDEN Seiten machen musst ! Also Server UND Client wenn beide Seiten Winblows sind.
Die Adapter Identifikation schlägt auf beiden Seiten fehl muss bei Winblows also beidseitig angepasst werden. Ebenso die Firewall Einstellungen und Profile.
Denk dran den IP Adressbereich bei ICMP lokale UND remote auf "Beliebig" zu stellen ! Das konnte man deinem "Erledigt" Screenshot nicht entnehmen. Wie bereits gesagt: Beide Seiten ! Server und Client.
Das gleiche gilt in der FW auch für den RDP Dienst !

Nun, ich weis ja nicht, ob das hier weiter hilft? Wenn nur ein Client pro Tunnel gewünscht wird, dann solltest Du einen Multiclienttunnel vermeiden.
Ich hatte auch schon diese "Multiclienttunnel" am laufen, zu erkennen an den virtuellen IP 's 10.8.8.1 - 10.8.8.6/7 und immer Probleme mit dem Routing auf die Netze dahinter.
Ich habe hier mehrere Tunnel am laufen, die über eine pfSense, den gegenseitigen Zugriff über die OpenVPN-Server gewähren. Die Clients laufen auf den unterschiedlichsten Plattformen und Verbindung besteht in die Serverseitigen Netze und auch in die remoten Clientnetze ohne Probleme.
Dabei haben die Server "immer" eine CCD mit Client-Spezifischen Anweisungen und KEINEN "client-to-client" Eintrag. Die Routen sind in den Servereinstellungen mit "route" bzw. "push route" definiert.
Die tun-IP im Server ist immer die xxx.xxx.xxx.1 und die des Clients immer die xxx.xxx.xxx.2 und nur diese virtuellen IP 's für das virtuelle TUN-Device.
Hier das IPv4-Routing Protokoll der pfSense, klar zu sehen die "ovpns X" IP 's des Servers xxx.xxx.xxx.1 und des Clients xxx.xxx.xxx.2.

IPv4 Routes
Destination	Gateway	Flags	Use	Mtu	Netif	Expire

default	192.168.219.1	UGS	414956	1500	igb0	
10.8.0/24	10.10.8.2	UGS	0	1342	ovpns1	
10.8.1	link#9	UHS	0	16384	lo0	
10.8.2	link#9	UH	0	1342	ovpns1	
12.7.0/24	10.12.7.2	UGS	0	1342	ovpns2	
12.7.1	link#10	UHS	0	16384	lo0	
12.7.2	link#10	UH	0	1342	ovpns2	
15.8.0/24	10.10.8.2	UGS	0	1342	ovpns1	
15.8.1	link#11	UHS	0	16384	lo0	
15.8.2	link#11	UH	28668	1308	ovpns3	
0.0.1	link#4	UH	468	16384	lo0	
16.7.0/24	link#3	U	26207	1492	igb2	
16.7.1	link#3	UHS	0	16384	lo0	
16.8.0/24	10.12.7.2	UGS	0	1342	ovpns2	
168.1.0/24	10.12.7.2	UGS	5	1342	ovpns2	
168.2.0/24	10.10.8.2	UGS	5	1342	ovpns1	
168.18.0/24	10.12.7.2	UGS	0	1342	ovpns2	
168.55.0/24	10.10.8.2	UGS	3	1342	ovpns1	
168.66.0/24	10.12.7.2	UGS	0	1342	ovpns2	
168.89.0/24	link#8	U	227802	1492	ath0_wlan0	
168.89.1	link#8	UHS	0	16384	lo0	
168.155.0/24	link#2	U	3643568	1492	igb1	
168.155.1	link#2	UHS	0	16384	lo0	
168.219.0/24	link#1	U	2656498	1500	igb0	
168.219.2	link#1	UHS	0	16384	lo0

Gruss orcape

Ich hatte auch schon diese "Multiclienttunnel" am laufen,

Du hast Recht !
Wurde dem TO oben auch schon mehrfach gesagt das er das NICHT machen soll.
Die Routing Table Screenshots mit den P2P "Leichen" zeigt aber klar das er das, wie du zu Recht bemerkst, leider nicht umgesetzt hat...
Da er aber (geraten) die OVPN Adresse des Servers pingen kann ist fraglich ob es das letztlich ist.
Hier wäre die Klärung der Frage ob er den LAN Adapter des Servers pingen kann sehr hilfreich. Aber die Antwort steht ja noch aus...?!

@aqui

Da er aber (geraten) die OVPN Adresse des Servers pingen kann ist fraglich ob es das letztlich ist.

Abgesehen von... (geraten). Wenn sich die Tunnel-IP 's pingen lassen, ist bei seiner config noch lange nicht gesagt, das es auch mit den lokalen oder remoten Netzen funktioniert.
Das hier noch mehrere Faktoren eine Rolle spielen, die dem TO als gute Ratschläge mit auf den Weg gegeben wurden, sollte klar sein. Ob dann ordentlich umgesetzt, ist dann ein anderer Fall.
Wenn er die ganze Lektüre, die Du ja zweifelsohne, ordentlich verlinkt hast, dann duchgearbeitet und verstanden hat, sollte es ja zu einem Ergebnis kommen.
Gruss orcape

Frage: Kannst du denn wenigstens das lokale LAN Interface 192.168.188.105 des Servers vom Client pingen ?
Ein Ping des direkten Server interfaces 10.8.8.5 klappt aber, oder ?

Leider beides nicht:
Nur der Ping auf den 10.8.8.1 wie unten zu sehen.
Auf 10.8.8.5 nicht.
Die Konfiguration ist jetzt mit der Push Route s.o. auch ohne den Multiclienttunnel

Client

Server

Das kann eigentlich nur noch an der lokalen Windows Firewall liegen !
Denk dran das du diese Firewall Einstellungen auf BEIDEN Seiten machen musst ! Also Server UND Client wenn beide Seiten Winblows sind.

Alles klar, muss dann eben noch schauen, dass ich beim Client auch die vornehme und nochmal probiere.

Die Adapter Identifikation schlägt auf beiden Seiten fehl muss bei Winblows also beidseitig angepasst werden. Ebenso die Firewall Einstellungen und Profile.
Denk dran den IP Adressbereich bei ICMP lokale UND remote auf "Beliebig" zu stellen ! Das konnte man deinem "Erledigt" Screenshot nicht entnehmen. Wie bereits gesagt: Beide Seiten ! Server und Client.

Aso ja, beim Server sind alle auf "beliebig", müssen wohl dann beim Client auch geschehen.

Nun, ich weis ja nicht, ob das hier weiter hilft? Wenn nur ein Client pro Tunnel gewünscht wird, dann solltest Du einen Multiclienttunnel vermeiden.

Multiclienttunnel müsste eigenlich deaktiviert sein.
Der Eintrag client-to-client ist auf der server Konfig entfernt worden.

Gruß
intane

Die Routing Table Screenshots mit den P2P "Leichen" zeigt aber klar das er das, wie du zu Recht bemerkst, leider nicht umgesetzt hat...

Komisch der Eintrag client-to-client ist eigentlich nicht mehr da.
Wie werden diese "Leichen" dann erzeugt.

Wenn er die ganze Lektüre, die Du ja zweifelsohne, ordentlich verlinkt hast, dann duchgearbeitet und verstanden hat, sollte es ja zu einem Ergebnis kommen.

Habe die Links größtenteils durchgeschaut, daraus die beiden Konfigs bzw. Einstellungen durchgeführt, es müssten eigentlich Kleinigkeiten sein, wieso die Verbindung nicht ganz klappt.
Da OVPN schon mal sich verbinden lässt.

Gruß
intane

Müsste, könnte, sollte. Bischen viel Konjunktiv....

Und 4 Einzelthreads im Minutenrythmus könnte man auch sinnvoll in einen zusammenfassen...nur mal so OT.

Wie werden diese "Leichen" dann erzeugt.

Wenn man KEIN Multiclient macht.
Sollte aber auch raus sein aus deinen Konfigs wenn die obigen noch stimmen. Das fragment, keepalive und persist-tun sollte noch raus so das wirklich nur das drin ist was man wirklich braucht.
Persist-tun bewirkt vermutlich das die Tunnel Netz nicht abgebaut werden und als Inaktiv in der Routing Tabelle verharren..
Die 10.8.8.1 sollte eigentlich gar nicht pingbar sein wenn der Server selber die .2 hat. Dann müsste die .2 vom Client pingbar sein.
Der Tunnel selber rennt also aber das das LAN Interface nicht pingbar ist zeigt klar das irgend etwas mit dem IPv4 Forwarding (Routing) am Server nicht klappt.
Hast du mal in der Registry überprüft ob das wirklich aktiv ist ??
Oder eben die lokale Firewall. Eins von beiden oder beides ist es....
Das ist die Pest mit Microsoft. Mit einem Linux würde das schon seit 3 Tagen laufen...

Das ist die Pest mit Microsoft.

Na ja, man kann es sich, man muss es sich ja nicht an tun.
Der Möglichkeiten und Alternativen gibt es da wohl mehrere.

Sollte aber auch raus sein aus deinen Konfigs wenn die obigen noch stimmen. Das fragment, keepalive und persist-tun sollte noch raus so das wirklich nur das drin ist was man wirklich braucht.
Persist-tun bewirkt vermutlich das die Tunnel Netz nicht abgebaut werden und als Inaktiv in der Routing Tabelle verharren..

Alles klar, anbei noch die überarbeitete server konfig.

port 1194

proto udp

dev tun0

ca c://programme//openvpn//easy-rsa//keys//ca.crt
cert c://programme//openvpn//easy-rsa//keys//server.crt
key c://programme//openvpn//easy-rsa//keys//server.key
dh c://programme//openvpn//config//dh2048.pem

server 10.8.8.0 255.255.255.0

push "route 192.168.188.0 255.255.255.0"  

comp-lzo

persist-key

log-append  openvpn.log

verb 3

client
dev tun
proto udp
remote 84.135.54.70 1194
resolv-retry infinite
nobind
persist-key

ca 'C:\\Program Files\\OpenVPN\\config\\ca.crt'  
cert 'C:\\Program Files\\OpenVPN\\config\\Client2.crt'  
key 'C:\\Program Files\\OpenVPN\\config\\Client2.key'  


ns-cert-type server
comp-lzo
verb 3

Die 10.8.8.1 sollte eigentlich gar nicht pingbar sein wenn der Server selber die .2 hat. Dann müsste die .2 vom Client pingbar sein.
Der Tunnel selber rennt also aber das das LAN Interface nicht pingbar ist zeigt klar das irgend etwas mit dem IPv4 Forwarding (Routing) am Server nicht klappt.

Ok, haben wir schon mal die Ursache.

Hast du mal in der Registry überprüft ob das wirklich aktiv ist ??

IPEnableRouter war inaktiv, da der Rechner kein Server BS hat, aktiviert, aber leider ohne Erfolg bis jetzt.

Oder eben die lokale Firewall. Eins von beiden oder beides ist es....
Das ist die Pest mit Microsoft. Mit einem Linux würde das schon seit 3 Tagen laufen...

Die Microsoft Pest ^^ ja auf dem Rechner muss eine Handwerkssoftware laufen und die ist für Windows erworben, daher...
Ja mittlerweile sind gefühlt alle Türen offen von der FW her bei Server und Client, aber leider hackt es noch hmm
Da Verbindung da ist, denke ich müsste auf der Fritzbox keine Route noch erstellt werden oder.

Was mir jetzt aufgefallen ist, dass die Verbindung alle zwei Minuten neustartet, bricht einfach plötzlich ab (timeout)

Client Log:

Wed Apr 18 13:58:58 2018 [server] Inactivity timeout (--ping-restart), restarting
Wed Apr 18 13:58:58 2018 C:\WINDOWS\system32\route.exe DELETE 192.168.188.0 MASK 255.255.255.0 10.8.8.5
Wed Apr 18 13:58:58 2018 Route deletion via IPAPI succeeded [adaptive]
Wed Apr 18 13:58:58 2018 C:\WINDOWS\system32\route.exe DELETE 10.8.8.1 MASK 255.255.255.255 10.8.8.5
Wed Apr 18 13:58:58 2018 Route deletion via IPAPI succeeded [adaptive]
Wed Apr 18 13:58:58 2018 Closing TUN/TAP interface
Wed Apr 18 13:58:58 2018 SIGUSR1[soft,ping-restart] received, process restarting
Wed Apr 18 13:58:58 2018 MANAGEMENT: >STATE:1524052738,RECONNECTING,ping-restart,,,,,
Wed Apr 18 13:58:58 2018 Restart pause, 5 second(s)
Wed Apr 18 13:59:03 2018 TCP/UDP: Preserving recently used remote address: [AF_INET] 84.135.54.70:1194
Wed Apr 18 13:59:03 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Apr 18 13:59:03 2018 UDP link local: (not bound)
Wed Apr 18 13:59:03 2018 UDP link remote: [AF_INET] 84.135.54.70:1194
Wed Apr 18 13:59:03 2018 MANAGEMENT: >STATE:1524052743,WAIT,,,,,,
Wed Apr 18 13:59:03 2018 MANAGEMENT: >STATE:1524052743,AUTH,,,,,,
Wed Apr 18 13:59:03 2018 TLS: Initial packet from [AF_INET] 84.135.54.70:1194, sid=43c34a7e ecab059f
Wed Apr 18 13:59:03 2018 VERIFY OK: depth=1, C=DE, ST=NRW, L=G, O=ct, OU=ct, CN=server, name=server, emailAddress=e
Wed Apr 18 13:59:03 2018 VERIFY OK: nsCertType=SERVER
Wed Apr 18 13:59:03 2018 VERIFY OK: depth=0, C=DE, ST=NRW, L=G, O=ct, OU=ct, CN=server, name=server, emailAddress=e
Wed Apr 18 13:59:03 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Wed Apr 18 13:59:03 2018 [cteserver] Peer Connection Initiated with [AF_INET] 84.135.54.70:1194
Wed Apr 18 13:59:04 2018 MANAGEMENT: >STATE:1524052744,GET_CONFIG,,,,,,
Wed Apr 18 13:59:04 2018 SENT CONTROL [cteserver]: 'PUSH_REQUEST' (status=1)  
Wed Apr 18 13:59:04 2018 PUSH: Received control message: 'PUSH_REPLY,route 192.168.188.0 255.255.255.0,route 10.8.8.1,topology net30,ifconfig 10.8.8.6 10.8.8.5,peer-id 0,cipher AES-256-GCM'  
Wed Apr 18 13:59:04 2018 OPTIONS IMPORT: --ifconfig/up options modified
Wed Apr 18 13:59:04 2018 OPTIONS IMPORT: route options modified
Wed Apr 18 13:59:04 2018 OPTIONS IMPORT: peer-id set
Wed Apr 18 13:59:04 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Wed Apr 18 13:59:04 2018 OPTIONS IMPORT: data channel crypto options modified
Wed Apr 18 13:59:04 2018 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key  
Wed Apr 18 13:59:04 2018 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key  
Wed Apr 18 13:59:04 2018 interactive service msg_channel=0
Wed Apr 18 13:59:04 2018 ROUTE_GATEWAY 192.168.33.254/255.255.255.0 I=7 HWADDR=3c:97:0e:cd:4c:ae
Wed Apr 18 13:59:04 2018 open_tun
Wed Apr 18 13:59:04 2018 TAP-WIN32 device [TAP] opened: \\.\Global\{F25781DE-AB88-4C05-9A3A-1C7B425DDA67}.tap
Wed Apr 18 13:59:04 2018 TAP-Windows Driver Version 9.21 
Wed Apr 18 13:59:04 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.8.6/255.255.255.252 on interface {F25781DE-AB88-4C05-9A3A-1C7B425DDA67} [DHCP-serv: 10.8.8.5, lease-time: 31536000]
Wed Apr 18 13:59:04 2018 Successful ARP Flush on interface [18] {F25781DE-AB88-4C05-9A3A-1C7B425DDA67}
Wed Apr 18 13:59:04 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Wed Apr 18 13:59:04 2018 MANAGEMENT: >STATE:1524052744,ASSIGN_IP,,10.8.8.6,,,,
Wed Apr 18 13:59:09 2018 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Wed Apr 18 13:59:09 2018 MANAGEMENT: >STATE:1524052749,ADD_ROUTES,,,,,,
Wed Apr 18 13:59:09 2018 C:\WINDOWS\system32\route.exe ADD 192.168.188.0 MASK 255.255.255.0 10.8.8.5
Wed Apr 18 13:59:09 2018 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Wed Apr 18 13:59:09 2018 Route addition via IPAPI succeeded [adaptive]
Wed Apr 18 13:59:09 2018 C:\WINDOWS\system32\route.exe ADD 10.8.8.1 MASK 255.255.255.255 10.8.8.5
Wed Apr 18 13:59:09 2018 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Wed Apr 18 13:59:09 2018 Route addition via IPAPI succeeded [adaptive]
Wed Apr 18 13:59:09 2018 Initialization Sequence Completed
Wed Apr 18 13:59:09 2018 MANAGEMENT: >STATE:1524052749,CONNECTED,SUCCESS,10.8.8.6,84.135.54.70,1194,,

Davor nicht wirklich drauf geachtet, das obere Log wiederholt sich alle zwei Minuten.