joseph22
Goto Top

OpenVPN nur Server-IP erreichbar, andere Netze nicht

Hallo zusammen,
ich habe auf einem Windows Server 2008R2 ein OpenVPN installiert und schaffe es nicht, andere Netze zu erreichen.

Der Server hat zwei Interfaces: Internet (192.168.178.10/24) und Intranet (192.168.0.200/24, der wird aber nicht mehr benutzt.).
Nun kam ja der TAP-Adapter von OpenVPN dazu und ich habe im Interface Internet die Freigabe auf diesen Adapter eingestellt.
Für OpenVPN Clients habe ich das Netz 10.2.5.0/24 vorgesehen und in meiner FritzBox (192.168.178.1/24 und Default Gateway im Netz) dafür auch eine statische Route erstellt, die auf 192.168.178.10/24 zeigt, also den Server, auf dem auch der OpenVPN Server läuft. Nun kann ich als verbundener Client leider nur den VPN-Server anpingen (dieser hat dann die IP 10.2.5.1), die 192.168.178.10 oder andere Hosts in meinem Netz kann ich leider nicht erreichen und ich weiß nicht, an was es liegen könnte. Daher habe ich hier mal die Serverkonfiguration sowie ipconfigs und Routen des Servers und des Clients sowie die OpenVPN Logs:

Serverkonfiguration:

local 192.168.178.10
port 1194
proto udp
dev tun

# ----------------------------------------------
# Zertifikate
# ----------------------------------------------

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

# ----------------------------------------------
# Server-Setup
# ----------------------------------------------

server 10.2.5.0 255.255.255.0
ifconfig-pool-persist "C:\\Programme\\OpenVPN\\ipp.txt"  
client-to-client

# ----------------------------------------------
# Client-Settings (inkl Special Dir)Files
# ----------------------------------------------

client-config-dir "C:\\Programme\\OpenVPN\\ccd"  
push "route 10.2.5.0 255.255.255.0"  
push "dhcp-option DNS 192.168.178.1"  

# ----------------------------------------------
# Defaults
# ----------------------------------------------

keepalive 10 120
persist-key
persist-tun

# ----------------------------------------------
# Logging
# ----------------------------------------------

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

ipconfig am Server, wenn OpenVPN nicht läuft:

Windows-IP-Konfiguration


Ethernet-Adapter tun:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Ethernet-Adapter Internet:

   Verbindungsspezifisches DNS-Suffix:
   IPv6-Adresse. . . . . . . . . . . : 2a02:8071:2ba3:1900:805d:c857:4900:efd4
   Verbindungslokale IPv6-Adresse  . : fe80::c0a8:b20a%14
   Verbindungslokale IPv6-Adresse  . : fe80::805d:c857:4900:efd4%14
   IPv4-Adresse  . . . . . . . . . . : 192.168.178.10
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : ::
                                       fe80::c225:6ff:fe1c:5067%14
                                       192.168.178.1

Ethernet-Adapter Intranet:

   Verbindungsspezifisches DNS-Suffix:
   IPv6-Adresse. . . . . . . . . . . : 2a02:8071:2ba3:1900:650b:7bb9:e257:1469
   Verbindungslokale IPv6-Adresse  . : fe80::650b:7bb9:e257:1469%13
   IPv4-Adresse  . . . . . . . . . . : 192.168.0.200
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : fe80::c225:6ff:fe1c:5067%13
                                       192.168.0.1

Ethernet-Adapter LAN-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Tunneladapter isatap.{F67071D9-53F9-4982-A218-5ECB257A599F}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Tunneladapter isatap.{D847383C-FC5F-4FBC-8C61-4617DA8E8929}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Tunneladapter LAN-Verbindung* 6:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Tunneladapter isatap.{28B94169-E00E-452C-9843-3DEF03E9C31B}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Tunneladapter isatap.{008CD343-2A65-4DE5-8748-10F1EDFBA75B}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

ipconfig am Server, wenn OpenVPN läuft:

Windows-IP-Konfiguration


Ethernet-Adapter tun:

   Verbindungsspezifisches DNS-Suffix:
   Verbindungslokale IPv6-Adresse  . : fe80::d4e4:8db9:6d4:4ca1%20
   IPv4-Adresse  . . . . . . . . . . : 10.2.5.1
   Subnetzmaske  . . . . . . . . . . : 255.255.255.252
   Standardgateway . . . . . . . . . :

Ethernet-Adapter Internet:

   Verbindungsspezifisches DNS-Suffix:
   IPv6-Adresse. . . . . . . . . . . : 2a02:8071:2ba3:1900:805d:c857:4900:efd4
   Verbindungslokale IPv6-Adresse  . : fe80::c0a8:b20a%14
   Verbindungslokale IPv6-Adresse  . : fe80::805d:c857:4900:efd4%14
   IPv4-Adresse  . . . . . . . . . . : 192.168.178.10
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : ::
                                       fe80::c225:6ff:fe1c:5067%14
                                       192.168.178.1

Ethernet-Adapter Intranet:

   Verbindungsspezifisches DNS-Suffix:
   IPv6-Adresse. . . . . . . . . . . : 2a02:8071:2ba3:1900:650b:7bb9:e257:1469
   Verbindungslokale IPv6-Adresse  . : fe80::650b:7bb9:e257:1469%13
   IPv4-Adresse  . . . . . . . . . . : 192.168.0.200
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : fe80::c225:6ff:fe1c:5067%13
                                       192.168.0.1

Ethernet-Adapter LAN-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Tunneladapter isatap.{F67071D9-53F9-4982-A218-5ECB257A599F}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Tunneladapter isatap.{D847383C-FC5F-4FBC-8C61-4617DA8E8929}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Tunneladapter LAN-Verbindung* 6:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Tunneladapter isatap.{28B94169-E00E-452C-9843-3DEF03E9C31B}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Tunneladapter isatap.{008CD343-2A65-4DE5-8748-10F1EDFBA75B}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Das OpenVPN Log vom Server:

Wed May 20 17:17:45 2020 OpenVPN 2.3.18 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Sep 26 2017
Wed May 20 17:17:45 2020 Windows version 6.1 (Windows 7) 64bit
Wed May 20 17:17:45 2020 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Wed May 20 17:17:45 2020 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Wed May 20 17:17:46 2020 Diffie-Hellman initialized with 2048 bit key
Wed May 20 17:17:46 2020 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed May 20 17:17:46 2020 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 I=13 HWADDR=00:1b:78:36:cf:16
Wed May 20 17:17:46 2020 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed May 20 17:17:46 2020 open_tun, tt->ipv6=0
Wed May 20 17:17:46 2020 TAP-WIN32 device [tun] opened: \\.\Global\{28B94169-E00E-452C-9843-3DEF03E9C31B}.tap
Wed May 20 17:17:46 2020 TAP-Windows Driver Version 9.9 
Wed May 20 17:17:46 2020 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.2.5.1/255.255.255.252 on interface {28B94169-E00E-452C-9843-3DEF03E9C31B} [DHCP-serv: 10.2.5.2, lease-time: 31536000]
Wed May 20 17:17:46 2020 Sleeping for 10 seconds...
Wed May 20 17:17:56 2020 Successful ARP Flush on interface [20] {28B94169-E00E-452C-9843-3DEF03E9C31B}
Wed May 20 17:17:56 2020 C:\Windows\system32\route.exe ADD 10.2.5.0 MASK 255.255.255.0 10.2.5.2
Wed May 20 17:17:56 2020 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed May 20 17:17:56 2020 Route addition via IPAPI succeeded [adaptive]
Wed May 20 17:17:56 2020 UDPv4 link local (bound): [AF_INET]192.168.178.10:1194
Wed May 20 17:17:56 2020 UDPv4 link remote: [undef]
Wed May 20 17:17:56 2020 MULTI: multi_init called, r=256 v=256
Wed May 20 17:17:56 2020 IFCONFIG POOL: base=10.2.5.4 size=62, ipv6=0
Wed May 20 17:17:56 2020 ifconfig_pool_read(), in='MyTestClient,10.2.5.4', TODO: IPv6  
Wed May 20 17:17:56 2020 succeeded -> ifconfig_pool_set()
Wed May 20 17:17:56 2020 IFCONFIG POOL LIST
Wed May 20 17:17:56 2020 MyTestClient,10.2.5.4
Wed May 20 17:17:56 2020 Initialization Sequence Completed

Die Routen am Server, wenn OpenVPN läuft (IPv6 habe ich rausgenommen):

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\Administrator>route print
===========================================================================
Schnittstellenliste
 20...00 ff 28 b9 41 69 ......TAP-Windows Adapter V9
 14...00 1b 78 36 cf 14 ......HP NC373i Multifunction Gigabit Server Adapter #2
 13...00 1b 78 36 cf 16 ......HP NC373i Multifunction Gigabit Server Adapter
 11...00 1b 21 03 af 09 ......Intel(R) PRO/1000 PF Server Adapter
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter
 15...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #2
 16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 17...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #3
 18...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #4
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.200    276
          0.0.0.0          0.0.0.0    192.168.178.1   192.168.178.10    276
         10.2.5.0    255.255.255.0         10.2.5.2         10.2.5.1     30
         10.2.5.0  255.255.255.252   Auf Verbindung          10.2.5.1    286
         10.2.5.1  255.255.255.255   Auf Verbindung          10.2.5.1    286
         10.2.5.3  255.255.255.255   Auf Verbindung          10.2.5.1    286
        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.200    276
    192.168.0.200  255.255.255.255   Auf Verbindung     192.168.0.200    276
    192.168.0.255  255.255.255.255   Auf Verbindung     192.168.0.200    276
    192.168.178.0    255.255.255.0   Auf Verbindung    192.168.178.10    276
   192.168.178.10  255.255.255.255   Auf Verbindung    192.168.178.10    276
  192.168.178.255  255.255.255.255   Auf Verbindung    192.168.178.10    276
        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.200    276
        224.0.0.0        240.0.0.0   Auf Verbindung    192.168.178.10    276
        224.0.0.0        240.0.0.0   Auf Verbindung          10.2.5.1    286
  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.200    276
  255.255.255.255  255.255.255.255   Auf Verbindung    192.168.178.10    276
  255.255.255.255  255.255.255.255   Auf Verbindung          10.2.5.1    286
===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik
          0.0.0.0          0.0.0.0      192.168.0.1  Standard
          0.0.0.0          0.0.0.0    192.168.178.1  Standard
===========================================================================

===========================================================================
Ständige Routen:
 If Metrik Netzwerkziel             Gateway
  0 4294967295 ::/0                     fe80::c0a8:b20a
===========================================================================

Nun der Client:

ipconfig, wenn VPN verbunden:

Windows-IP-Konfiguration


Ethernet-Adapter Ethernet 2:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Ethernet-Adapter Ethernet:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Ethernet-Adapter Ethernet 3:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Ethernet-Adapter VirtualBox Host-Only Network:

   Verbindungsspezifisches DNS-Suffix:
   Verbindungslokale IPv6-Adresse  . : fe80::3c21:9c7a:d050:2d31%6
   IPv4-Adresse  . . . . . . . . . . : 192.168.56.1
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . :

Unbekannter Adapter LAN-Verbindung 2:

   Verbindungsspezifisches DNS-Suffix:
   Verbindungslokale IPv6-Adresse  . : fe80::7c7b:849c:fbab:8db1%29
   IPv4-Adresse  . . . . . . . . . . : 10.2.5.6
   Subnetzmaske  . . . . . . . . . . : 255.255.255.252
   Standardgateway . . . . . . . . . : 192.168.178.1

Drahtlos-LAN-Adapter LAN-Verbindung* 1:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Drahtlos-LAN-Adapter LAN-Verbindung* 2:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Drahtlos-LAN-Adapter WLAN:

   Verbindungsspezifisches DNS-Suffix:
   IPv6-Adresse. . . . . . . . . . . : 2a00:20:9028:4553:b9d7:dbe0:d9ef:3f60
   Temporäre IPv6-Adresse. . . . . . : 2a00:20:9028:4553:28c9:633b:a075:6a26
   Verbindungslokale IPv6-Adresse  . : fe80::b9d7:dbe0:d9ef:3f60%10
   IPv4-Adresse  . . . . . . . . . . : 172.20.10.4
   Subnetzmaske  . . . . . . . . . . : 255.255.255.240
   Standardgateway . . . . . . . . . : fe80::cde:623:db0b:440d%10
                                       172.20.10.1

Ethernet-Adapter Bluetooth-Netzwerkverbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Ethernet-Adapter vEthernet (Default Switch):

   Verbindungsspezifisches DNS-Suffix:
   Verbindungslokale IPv6-Adresse  . : fe80::9c11:9b7c:8e92:9285%65
   IPv4-Adresse  . . . . . . . . . . : 192.168.54.145
   Subnetzmaske  . . . . . . . . . . : 255.255.255.240
   Standardgateway . . . . . . . . . :

Die Routen, wenn OpenVPN läuft, auch ohne IPv6:

Microsoft Windows [Version 10.0.17763.1217]
(c) 2018 Microsoft Corporation. Alle Rechte vorbehalten.


===========================================================================
Schnittstellenliste
 46...00 09 0f fe 00 01 ......Fortinet Virtual Ethernet Adapter (NDIS 6.30)
 47...3c 97 0e 19 14 e8 ......Intel(R) 82579LM Gigabit Network Connection
 35...00 09 0f aa 00 01 ......Fortinet SSL VPN Virtual Ethernet Adapter
  6...0a 00 27 00 00 06 ......VirtualBox Host-Only Ethernet Adapter
 29...00 ff af b6 28 3f ......TAP-Windows Adapter V9
  2...60 67 20 24 95 d9 ......Microsoft Wi-Fi Direct Virtual Adapter
 16...62 67 20 24 95 d8 ......Microsoft Wi-Fi Direct Virtual Adapter #2
 10...60 67 20 24 95 d8 ......Intel(R) Centrino(R) Advanced-N 6205
 17...e0 06 e6 b8 7f 37 ......Bluetooth Device (Personal Area Network)
  1...........................Software Loopback Interface 1
 65...70 15 34 a7 c2 55 ......Hyper-V Virtual Ethernet Adapter
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0    192.168.178.1         10.2.5.6    281
          0.0.0.0          0.0.0.0      172.20.10.1      172.20.10.4     55
         10.2.5.0    255.255.255.0         10.2.5.5         10.2.5.6     25
         10.2.5.4  255.255.255.252   Auf Verbindung          10.2.5.6    281
         10.2.5.6  255.255.255.255   Auf Verbindung          10.2.5.6    281
         10.2.5.7  255.255.255.255   Auf Verbindung          10.2.5.6    281
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
      172.20.10.0  255.255.255.240   Auf Verbindung       172.20.10.4    311
      172.20.10.4  255.255.255.255   Auf Verbindung       172.20.10.4    311
     172.20.10.15  255.255.255.255   Auf Verbindung       172.20.10.4    311
   192.168.54.144  255.255.255.240   Auf Verbindung    192.168.54.145   5256
   192.168.54.145  255.255.255.255   Auf Verbindung    192.168.54.145   5256
   192.168.54.159  255.255.255.255   Auf Verbindung    192.168.54.145   5256
     192.168.56.0    255.255.255.0   Auf Verbindung      192.168.56.1    281
     192.168.56.1  255.255.255.255   Auf Verbindung      192.168.56.1    281
   192.168.56.255  255.255.255.255   Auf Verbindung      192.168.56.1    281
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    331
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.56.1    281
        224.0.0.0        240.0.0.0   Auf Verbindung          10.2.5.6    281
        224.0.0.0        240.0.0.0   Auf Verbindung       172.20.10.4    311
        224.0.0.0        240.0.0.0   Auf Verbindung    192.168.54.145   5256
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.56.1    281
  255.255.255.255  255.255.255.255   Auf Verbindung          10.2.5.6    281
  255.255.255.255  255.255.255.255   Auf Verbindung       172.20.10.4    311
  255.255.255.255  255.255.255.255   Auf Verbindung    192.168.54.145   5256
===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik
          0.0.0.0          0.0.0.0    192.168.178.1  Standard
===========================================================================

===========================================================================
Ständige Routen:
  Keine

Und das OpenVPN Log des Clients:

Wed May 20 17:28:22 2020 OpenVPN 2.4.9 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 16 2020
Wed May 20 17:28:22 2020 Windows version 6.2 (Windows 8 or greater) 64bit
Wed May 20 17:28:22 2020 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Wed May 20 17:28:23 2020 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed May 20 17:28:23 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]78.43.229.51:1194
Wed May 20 17:28:23 2020 UDP link local: (not bound)
Wed May 20 17:28:23 2020 UDP link remote: [AF_INET]78.43.229.51:1194
Wed May 20 17:28:23 2020 [openvpnserver] Peer Connection Initiated with [AF_INET]78.43.229.51:1194
Wed May 20 17:28:25 2020 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 May 20 17:28:25 2020 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 May 20 17:28:25 2020 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Wed May 20 17:28:25 2020 open_tun
Wed May 20 17:28:25 2020 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{AFB6283F-A22F-43CB-B23B-9A9CBFAE35DD}.tap
Wed May 20 17:28:25 2020 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.2.5.6/255.255.255.252 on interface {AFB6283F-A22F-43CB-B23B-9A9CBFAE35DD} [DHCP-serv: 10.2.5.5, lease-time: 31536000]
Wed May 20 17:28:25 2020 Successful ARP Flush on interface [29] {AFB6283F-A22F-43CB-B23B-9A9CBFAE35DD}
Wed May 20 17:28:30 2020 ROUTE: route addition failed using CreateIpForwardEntry: Das Objekt ist bereits vorhanden.   [status=5010 if_index=29]
Wed May 20 17:28:30 2020 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem
Wed May 20 17:28:30 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed May 20 17:28:30 2020 Initialization Sequence Completed

Sieht irgendjemand, was ich hier falsch mache?

Content-ID: 573208

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

Ausgedruckt am: 26.11.2024 um 16:11 Uhr

Spirit-of-Eli
Spirit-of-Eli 20.05.2020 um 18:15:52 Uhr
Goto Top
Moin,

kennt das Gateway der Clients die Route in das OpenVPN Netz über den Server 2008?

Gruß
Spirit
ChriBo
ChriBo 20.05.2020 um 18:19:27 Uhr
Goto Top
Hi,
Sieht irgendjemand, was ich hier falsch mache?
Ja
1. Auf dem Server: Entferne das Gateway auf dem Intranet Interface (Hat aber nichts mit deinem VPN Fehler zu tun)
2. Woher soll der Client PC wissen, daß er 192.168.178.10/24 über 10.2.5.5 erreichen soll ?
3. Warum < push "route 10.2.5.0 255.255.255.0"> in der Config ?
CH
Joseph22
Joseph22 20.05.2020 um 18:29:24 Uhr
Goto Top
Ich gehe mal davon aus, dass 3. mit 2. zusammenhängt?ich möchte bezwecken, dass der Client das 10.2.5.0 Netz kennt und die entsprechende Route setzt. Soll ich das 192.168.178.0 auch dem Client bekannt machen?
Joseph22
Joseph22 20.05.2020 um 18:29:59 Uhr
Goto Top
Nachdem ich die 10.2.5.1 anpingen kann, denke ich ja.
ChriBo
ChriBo 20.05.2020 um 18:36:20 Uhr
Goto Top
Hi,
Ich hatte gehoft das du die Lösung selber findest.
Er kennt das 10.2.5.0 Netz, ohne extra Routeneintrag, da er ja eine 10.2.5.0/24 er Adresse erhält; das Netz auf dem Adapter selber muß nie durch einen Routeneintrag bekannt gegeben werden.
Du sollst nicht, sondern du mußt 192.168.178.0/24 dem Client per push route bekannt geben.

CH
Joseph22
Joseph22 20.05.2020 aktualisiert um 18:56:05 Uhr
Goto Top
Ich habe die push Zeile nun durch die 192.168.178.0 ersetzt, aber ich kann vom Client aus immer noch nicht die 192.168.178.10 oder .1 erreichen.

OpenVPN setzt auf dem Client folgende Route:

192.168.178.0    255.255.255.0         10.2.5.5         10.2.5.6    281

Allerdings ist das Gateway für mich nicht nachvollziehbar, der TAP-Adapter hat die .1, die .5 ist gar nicht vergeben. Mein Client hat die .6?

Wenn ich
route change 192.168.178.0 mask 255.255.255.0 10.2.5.1
durchführe, erhalte ich ebenfalls ein Timeout.
Spirit-of-Eli
Spirit-of-Eli 20.05.2020 um 18:56:28 Uhr
Goto Top
Ich gehe davon aus, das du eine Fritzbox einsetzt. Auf dieser muss eine Route für das VPN Netz auf den Windows Server zeigen.
Joseph22
Joseph22 20.05.2020 aktualisiert um 19:06:08 Uhr
Goto Top
Genau, da habe ich eine statische Route: 10.2.5.0/24 zeigt auf 192.168.178.10 (die IP meines Windows Servers):


Aktiv Netzwerk Subnetzmaske Gateway
x 10.2.5.0 255.255.255.0 192.168.178.10
HuckFin
HuckFin 20.05.2020 um 19:39:12 Uhr
Goto Top
Sind die Netzwerkkarten (vpn + lan) gebrückt ?
Joseph22
Joseph22 20.05.2020 aktualisiert um 19:50:39 Uhr
Goto Top
Ja, der VPN Adapter darf denInternet-Adapter nutzen und steuern. IPEnableRouter steht auf 1
HuckFin
HuckFin 20.05.2020 aktualisiert um 20:33:19 Uhr
Goto Top
Ich kenne das jetzt nur von Linux aus als OpenVPN Server.
Da benutze ich dev tap, proto udp.
Als Client dann Win 10.
Da klappt es immer mit dem anpingen aller PCs im Ziel-Lan.
BZW kann ich alle Geräte dort erreichen.

float
dev tap
proto udp
port 5000
mode server
ifconfig 10.0.1.20 255.255.255.0
ifconfig-pool 10.0.1.1 10.0.1.9
tls-server
client-to-client
cipher AES-256-CBC
ab hier verschlüsselung...

Ich pinge dort dann z.b. in dass 192.168.x.y Netz


und mit brücken meine ich, dass du VPN Adapter + lan-adapter anklickst (mit strg) und dann rechte maustaste und "überbrücken" anklickst
Joseph22
Joseph22 20.05.2020 um 20:44:16 Uhr
Goto Top
Ein gebridgtes Netz wollte ich eigentlich nicht, ich werde aber beides morgen mal probieren.
HuckFin
HuckFin 20.05.2020 um 20:53:10 Uhr
Goto Top
Ich vermute, ohne Brücke kommst du nur bis zum VPN Adapter (Server)
Erst die Brücke zeigt dir die PCs im Lan
aqui
Lösung aqui 20.05.2020 aktualisiert um 23:53:20 Uhr
Goto Top
und schaffe es nicht, andere Netze zu erreichen.
Erstmal lesen und verstehen:
Merkzettel: VPN Installation mit OpenVPN
und
OpenVPN - Erreiche Netzwerk hinter Client nicht

Deine Kardinalsfehler:
  • Server: Es ist Blödsinn mit push "route..." Das interne OVPN IP Netz an die Clients zu pushen. Blödsinn deshalb weil sie beim Tunnelaufbau dieses Netz automatisch bekommen. Mit push "route..." werden immer nur die lokalen IP Netze auf der Serverseite den Clients bekannt gemacht ! Fazit: Statt des falschen push "route 10.2.5.0 255.255.255.0" muss dort ein push "route 192.168.178.0 255.255.255.0" und push "route 192.168.200.0 255.255.255.0" hin ! Deine beiden lokalen LANs am Server ! Im Client kannst du das dann checken ob das in der Routing Tabelle ist mit route print (Windows) oder netstat -r -n bzw. ip route show (Linux)
  • Willst du auch noch das gesamte Client Netz routen muss zusätzlich noch ein route 192.168.56.0 255.255.255.0 und ein iroute 192.168.56.0 255.255.255.0 noch dazu !!

2 statische Routen auf der FritzBox natürlich noch !
Zielnetz: 10.2.5.0, Maske: 255.255.255.0, Gateway: 192.168.178.10 (IP Adresse OVPN Server)
Zielnetz: 192.168.56.0, Maske: 255.255.255.0, Gateway: 192.168.178.10
Lies die obigen Tutorials dazu und setze um was da steht !!

Auf gar keinen Fall solltest du Bridging über den VPN Tunnel machen. Das ist immer kontraproduktiv, denn du belastest dann mit dem gesamten Broad- und Multicast Traffic den VPN Tunnel und reisst die Performance in den Orkus. Zudem kannst du dann nicht mehr routen.
OpenVPN selber rät dringenst vom Bridging ab deshalb. Es gilt immer die goldene Netzwerker Admin Regel: "Route wherever you can, bridge where you must !"
Vergiss also diesen Unsinn mit dem netztechnisch falschen Bridging und fixe deine vollkommen falsche Server Konfig !
Dann kommt das auch alles sofort zum Fliegen.
Tutorials lesen und verstehen hilft wirklich ! face-wink
Joseph22
Joseph22 21.05.2020 um 07:16:43 Uhr
Goto Top
Hi, danke für die Links, probiere ich gleich mal aus. Bin da aber wenig optimistisch, selbst wenn ich das eigene LAN pushe, geht es nicht (wie oben beschrieben). Für was die statische Route auf das 192.168.56.0-Netz?
Joseph22
Joseph22 21.05.2020 aktualisiert um 10:58:27 Uhr
Goto Top
Vielen Dank, jetzt geht es. Anscheinend hat ihm der VPN-Adressbereich nicht gepasst.
Eine Frage noch: Auf 192.168.178.10 läuft RDP, der geht per Portfreigabe ins Internet (das ist der Grund, warum OpenVPN kommt ;) ). Nun erreiche ich den RDP aus dem Internet nur vom Mobilfunk, mit WLAN geht es nicht. Dort wird auch das 192.168.178.0 Netz verwendet. Im Mobilfunk habe ich die 10.irgendwas und da geht das RDP. Gibt es da Konflikte, auch wenn der VPN-Server NICHT läuft?
aqui
aqui 21.05.2020 aktualisiert um 14:52:08 Uhr
Goto Top
Für was die statische Route auf das 192.168.56.0-Netz?
Sofern du auf der Clientseite statt rein nur des Clients dort auch das gesamte lokale LAN per VPN verbinden willst !
Vielen Dank, jetzt geht es. Anscheinend hat ihm der VPN-Adressbereich nicht gepasst.
Kein Wunder wenn man so gruselige Anfängerfehler mit dem Routing gemacht hat wie du oben !
Gut das es nun rennt wie es soll... ! Obwohl das immer so ist wenn man es richtig macht und richtig einrichtet... face-wink
mit WLAN geht es nicht.
Das ist einzig ein Winblows Rechte Problem ! Ggf. der RDP Client App. oder der Windows Firewall auf dem Adapter.
Mit dem VPN selber hat es nichts mehr zu tun. Kannst du ja auch ganz einfach testen:
Wenn du via WLAN Interface bei aktivem VPN Client das interne VPN Interface (10.2.5.1) und die beiden LAN Interfaces des OVPN Servers anpingen kannst ist das VPN als Problem raus !
Möglich auch das du ggf. WLAN und LAN Interface zusammen aktiv hast. Dann gilt als Gateway immer rein nur das LAN Interface (Windows Adapter Bindungsreihenfolge bzw. Adapter Prioritäts Metrik).
Ist das der Fall deaktiviere mal den LAN Port dann so das nur WLAN aktiv ist, dann sollte es immer klappen.
Joseph22
Joseph22 21.05.2020 um 15:10:35 Uhr
Goto Top
Vielen Dank! Dann hab ich das Netz verwechselst :D
Das mit dem Adapter schaue ich mal, auf meinem Macbook habe ich nämlich das gleiche Verhalten.
Ping auf beide Interfaces geht. Ich werde mal bei mir das Netz auf 192.168.150.0 oder ein 10er Netz umstellen und berichte dann mal.
aqui
aqui 21.05.2020 aktualisiert um 15:50:01 Uhr
Goto Top
Die Routing Tabelle im Client ist dann immer dein bester Freund bei aktiver VPN Verbindung. face-wink
netstat -r -n -f inet auf dem Mac im Terminal bzw. route print (Winblows)
Joseph22
Joseph22 21.05.2020 um 15:55:14 Uhr
Goto Top
Ja mit Unix/Mac bin ich fit, nur Windows lässt bei mir zu wünschen übrig. Es geht auch darum dass ich den RDP nicht erreiche, wenn ich nicht im VPN bin und in meinem eigenen Heimnetz und mit mobilem Hotspot geht es dann.

Also: Mac/Windows -> IP meiner FritzBox -> IP entfernte FritzBox -> 192.168.178.10 (RDP Rechner)

Ich berichte dann mal face-smile
aqui
aqui 21.05.2020 aktualisiert um 16:01:05 Uhr
Goto Top
nur Windows lässt bei mir zu wünschen übrig.
Was ja eher positiv ist, denn Microsoft Knechte gibts ja schon genug ! face-big-smile
Es geht auch darum dass ich den RDP nicht erreiche, wenn ich nicht im VPN bin
Was ja auch logisch ist ! Ohne aktive VPN Verbindung kannst du ja die privaten RFC 1918 IP Netze gar nicht erreichen.
Es sei denn du arbeitest mit simplen Port Forwarding und gibst den RDP Port im NAT Router komplett frei für den ungeschützten RDP Zugriff. Dann ginge es auch ohne VPN.
So einen Sicherheits technischen Blödsinn macht aber heutzutage niemand mehr (hoffentlich ?!!). Ein aktives VPN ist in deinem Setup also immer ein Muss.
Dann gilt es natürlich aber auch eine intelligente IP Adressierung im VPN zu verwenden. Siehe dazu auch HIER.
Joseph22
Joseph22 21.05.2020 aktualisiert um 16:49:48 Uhr
Goto Top
Doch, aktuell Port forwarding von der FritzBox auf 192.168.178.10:3389. ist „historisch gewachsen“ Da mir das ein Dorn im Auge ist, muss das weg, daher kommt OpenVPN.
Für OpenVPN habe ich auch ein Port Forwarding auf 192.168.178.10:1194, nur wenn ich mich aus meinem WLAN zu Hause mit dem OpenVPN Server (über die öffentliche IP bzw. den DynDNS der FritzBox) oder RDP verbinden will, geht es nicht. Also muss irgendwo ein Konflikt mit den Netzen vorliegen. Mit meinen mobilen Hotspot geht aber beides. Und bevor ich jetzt ewig tracert mache und Routentabellen anschaue, einfach die Frage: darf das Remote LAN das gleiche Netz wie mein lokales LAN haben (in diesem Fall sind beide 192.168.178.0/24, Standard FritzBox halt). Und wenn jetzt gesagt wird das knallt, stelle ich gleich unsere Netze und Routen und statische IPS um face-smile
Spirit-of-Eli
Spirit-of-Eli 21.05.2020 um 17:02:58 Uhr
Goto Top
Das Portforwarding spielt da nicht rein.
Joseph22
Joseph22 21.05.2020 aktualisiert um 17:14:00 Uhr
Goto Top
Aber was dann? Sind es wirklich die beiden LANs auf beiden Seiten?
Und vor allem warum hat es vor OpenVPN funktioniert?
aqui
aqui 22.05.2020 aktualisiert um 14:58:57 Uhr
Goto Top
Und vor allem warum hat es vor OpenVPN funktioniert?
Weil du da immer über dummes Port Forwarding gegangen bist !

Doch, aktuell Port forwarding von der FritzBox auf 192.168.178.10:3389. ist „historisch gewachsen“ Da mir das ein Dorn im Auge ist, muss das weg
Zu Recht ! In einem Firmennetzwerk ist sowas ein absolutes NoGo und wäre ein Grund für eine Kündigung wenn man sowas realisiert.
Für OpenVPN habe ich auch ein Port Forwarding auf 192.168.178.10:1194
Welches Protokoll ??? Hoffentlich wohl UDP ?!
Ist auch nicht das Gelbe vom Ei, denn so musst du ungeschützten Internet Traffic in dein lokales LAN lassen. Keine besonders intelligente Idee und der Hauptgrund warum VPN Komponenten immer auf der Peripherie, sprich also VPN Router oder Firewall, angesiedelt sein sollten und niemals in einem lokalen Server im LAN. Aber OK, wenn du dir dessen bewusst bist und damit leben kannst ist das OK und ja auch nicht anders machbar wenn der Server intern ist.
aus meinem WLAN zu Hause mit dem OpenVPN Server (über die öffentliche IP bzw. den DynDNS der FritzBox) oder RDP verbinden will, geht es nicht.
Aber wenn du mit genau demselben Client nur im LAN (Kupfer) bist dann geht es ??
Hast du zuhause ggf. ein DS-Lite Anschluss mit CGN ??
darf das Remote LAN das gleiche Netz wie mein lokales LAN haben (in diesem Fall sind beide 192.168.178.0/24, Standard FritzBox halt).
Niemals dürfen sie das !
Das ist der Todesstoß für ein VPN. Allein schon die dümmliche FritzBox Allerwelts Adressierung so beizubehalten in einem VPN Umfeld zeugt schon von wenig Nachdenken. In jedem Netz was dann eine FritzBox hat als Router mit der AVM Default Adressierung wird dann dein VPN sofort immer scheitern.
Denk doch mal selber etwas nach. Die erste Klasse, Grundschule AP Adressregel die jeder lernt ist: "IP Netze müssen einzigartig sein !"
Gegen diese simple Grundregel hast du dann schon verstoßen. Ist auch klar, denn wie sollte so eine eindeutige und gesicherte Wegeführung der IP Pakete gemacht werden ?

Stell dir vor in D gäbe es 3 mal "München, Bahnhofstraße 3" und du sagst jemanden: "Fahr nach München in die Bahnhofstraße 3". Das kann nicht klappen wenn man es nicht wieder einzigartig mit der Postleitzahl machen würde.
Einfach nur mal logisch nachdenken und den gesunden Menschenverstand bemühen ! face-wink
In einem VPN Umfeld wie deinem wäre es sinnvoll und intelligent gewesen beide IP Netze auf eine andere IP Adresse umzustellen wie z.B. 172.17.177.0 /24 und 172.18.178.0 /24 oder sowas. Der Fundus der privaten RFC 1918 IP Adressen lässt dir ja eine mehr als reichhaltige Auswahl:
https://de.wikipedia.org/wiki/Private_IP-Adresse#Private_Adressbereiche
und die FritzBox ist inkl. DHCP ja mit 3 Mausklicks auf ein neues IP Netz umgestellt und löst so dein "Problem" im Handumdrehen. Kein Thema also

Bitte lies dazu auch unbedingt das hier:
VPNs einrichten mit PPTP
Und kauf dir mal ein gutes Buch zu TCP/IP Grundlagen. Lesen und verstehen nicht vergessen natürlich...
Joseph22
Joseph22 22.05.2020 aktualisiert um 18:06:07 Uhr
Goto Top
Zu Recht ! In einem Firmennetzwerk ist sowas ein absolutes NoGo und wäre ein Grund für eine Kündigung wenn man sowas realisiert.

Es ist ein Verein und keine Firma ;) Daher wurde das auch bis zu meiner Übernahme des Ganzen vor einer Woche als gut befunden :D

Welches Protokoll ??? Hoffentlich wohl UDP ?!
Ist auch nicht das Gelbe vom Ei, denn so musst du ungeschützten Internet Traffic in dein lokales LAN lassen. Keine besonders intelligente Idee und der Hauptgrund warum VPN Komponenten > immer auf der Peripherie, sprich also VPN Router oder Firewall, angesiedelt sein sollten und niemals in einem lokalen Server im LAN. Aber OK, wenn du dir dessen bewusst bist und damit leben kannst ist das OK und ja auch nicht anders machbar wenn der Server intern ist.

Klar UDP, steht ja so in der Server-Konfiguration.
Ich habe ein zweites Netz aufgebaut, in welchem sich alle Clients befinden. Traffic von außen geht jetzt auf den Server, der hat jetzt das lokale Netz 10.16.130.0/24, während alle Clients in 10.16.131.0/24 sind. Eine Route von 130 nach 131 gibt es natürlich nicht ;) Somit habe ich ein extra Netz für alle Dinge, die über das VPN erreichbar sein müssen. Falls die irgendwann mal von den lokalen Clients erreichbar sein müssen, kann man ja einfach eine Route hinzufügen. Dann brauche ich aber eine Firewall :D

Niemals dürfen sie das !
Das ist der Todesstoß für ein VPN. Allein schon die dümmliche FritzBox Allerwelts Adressierung so beizubehalten in einem VPN Umfeld zeugt schon von wenig Nachdenken. In jedem Netz was dann eine FritzBox hat als Router mit der AVM Default Adressierung wird dann dein VPN sofort immer scheitern.
Denk doch mal selber etwas nach. Die erste Klasse, Grundschule AP Adressregel die jeder lernt ist: "IP Netze müssen einzigartig sein !"
Gegen diese simple Grundregel hast du dann schon verstoßen. Ist auch klar, denn wie sollte so eine eindeutige und gesicherte Wegeführung der IP Pakete gemacht werden ?

Anscheinend liegt das aber daran, dass die FritzBox kein NAT auf lokalen Interfaces macht. Dann ist natürlich klar, warum es nicht geht :D

Vielen Dank für deine Tipps, OpenVPN ist für mich jetzt deutlich klarer! face-smile
aqui
aqui 22.05.2020 aktualisiert um 17:34:15 Uhr
Goto Top
Na ja...wenn die Mitglieder wüssten das ihre Daten offen über das Internet gehen würden sie es vermutlich nicht mehr "gut" finden....aber egal.
dass die FritzBox kein NAT auf lokalen Interfaces macht.
Nein, das kann die FritzBox nicht, nur auf dem WAN/Internet Interface wo es auch nicht abschaltbar ist. Die FritzBox ist ein billiger Consumer Router. Von dem darfst du nicht das Featureset eines Ciscos erwarten, da muss man auch mal fair bleiben !
Vielen Dank für deine Tipps,
Immer gerne !
Wenn du dann auch noch zum Zitieren mal richtigerweise ein ">" am Zeilenanfang mit einem Leerzeichen danach verwenden würdest statt sinnbefreit die Code Tags dafür zu missbrauchen wären wir alle auch zufrieden hier. face-wink
Joseph22
Joseph22 22.05.2020 um 18:01:01 Uhr
Goto Top
Ja klar, aber NAT auf allen Interfaces sollte imho jeder Router können face-smile

Ah, so geht das :D
aqui
aqui 22.05.2020 aktualisiert um 18:11:40 Uhr
Goto Top
Nein ! So gut wie alle billigen Consumer Router können das einzig nur auf dem WAN/Internet Port. Und das meistens auch nicht abschaltbar so das beidseitiges Routing unmöglich ist durch die NAT Firewall.
Nur bessere Router mit einem guten Featureset können das konfigurierbar auf allen Interfaces. Alternativ solche Router Modelle die sich alternativ mit freier Firmware wie DD-WRT oder OpenWRT bespielen lassen. Dort ist es auch möglich.
Hier irrst du also gewaltig mit der Annahme das es "jeder" kann.