istike2
Goto Top

OpenVPN-Problem DHCP geht, PING nicht

Hallo,

ich habe in einem LAN versuchsweise eine OPVPN-Verbindung zwischen einem Client und einem Server (SBS2003) aufgebaut. Die Verbindung steht scheinbar. Das Client bekommt die IP 192.168.10.6, DHCP geht also über das OVPN-Netz.

Meine Fragen:

1. was kann der Grund der folgenden Zeile sein?

"WARNING: No server certificate verification method has been enabled"

"Mon Feb 21 23:26:58 2011 ROUTE: route addition failed using CreateIpForwardEntry: Falscher Parameter. [status=87 if_index=65540]


2. wie kann ich erreichen, dass die Verbindung bei jedem Neustart automatisch aufgebaut wird?

3. Wie kann der User mit seinem lokalen NT-Login durch VPN angemeldet sein? (Ich möchte ja auf dem Server keine weitere User erstellen.)

4. warum können Server und Client einander nicht "anpingen"? Die Verbindung steht scheinbar.

5. wenn ich mir die Status-Info der TUN-Adapter in den Netzwereinstellungen des Server und des Clients anschaue ist Subnetz-Mask überall 255.255.255.252 obwohl ich 255.255.255.0 festgelegt habe (es ist möglicherweise i. O. so).

6. In denselben Status-Info gibt es kein Standard-Gateway, was in meinem Fall 192.168.10.1 sein sollte.

7. Ich habe gedacht, dass DHCP-Server identisch wäre mit dem Server. Es hat aber in meinem Fall die IP-Adresse 192.168.10.5. Ist es normal?


Danke für die Hilfe.


Gr. I.


hier ist die Config-Datei des Servers:

script-security 2
port 1194
proto udp
dev tun
tun-mtu 1500
fragment 1300
mssfix
tls-server
auth SHA1
pkcs12 C:\\Programme\\OpenVPN\\easy-rsa\\keys\\xxxx_Server.p12
dh C:\\Programme\\OpenVPN\\easy-rsa\\keys\\dh1024.pem
mode server
server 192.168.10.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.0.0.250 255.255.255.0"
client-to-client
keepalive 10 120
cipher AES-256-CBC
comp-lzo
user OpenVPN
status C:\\Programme\\OpenVPN\\config\\openvpn-status.log
verb 3


hier ist noch die Config-Datei des Clients:


client
dev tun
remote xxxxxxxxxxxxxxxxxx
port 1194
proto udp
tun-mtu 1500
fragment 1300
mssfix
pull
tls-client
auth SHA1
resolv-retry infinite
nobind
persist-key
persist-tun
pkcs12 C:\\Programme\\OpenVPN\\easy-rsa\\Keys\\xxxxxxxxxxxx.crt
cipher AES-256-CBC
comp-lzo
verb 3

hier ist das Log des Clients:

Mon Feb 21 23:26:43 2011 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 8 2010
Mon Feb 21 23:26:43 2011 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Mon Feb 21 23:26:43 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Feb 21 23:26:49 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Feb 21 23:26:49 2011 LZO compression initialized
Mon Feb 21 23:26:49 2011 Control Channel MTU parms [ L:1562 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Feb 21 23:26:49 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Feb 21 23:26:49 2011 Data Channel MTU parms [ L:1562 D:1300 EF:62 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Feb 21 23:26:49 2011 Fragmentation MTU parms [ L:1562 D:1300 EF:61 EB:135 ET:1 EL:0 AF:3/1 ]
Mon Feb 21 23:26:49 2011 Local Options hash (VER=V4): 'caff5189'
Mon Feb 21 23:26:49 2011 Expected Remote Options hash (VER=V4): '43a81564'
Mon Feb 21 23:26:49 2011 UDPv4 link local: [undef]
Mon Feb 21 23:26:49 2011 UDPv4 link remote: XXXXXXXXX
Mon Feb 21 23:26:49 2011 TLS: Initial packet from XXXXXXXXX:1194, sid=21658f71 e80530da
Mon Feb 21 23:26:50 2011 VERIFY OK: depth=1, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxxx/CN=Tank_CA/emailAddress=xxxxxxxxxxxxxxxxx
Mon Feb 21 23:26:50 2011 VERIFY OK: depth=0, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxxx/CN=Tank_Server/emailAddress=xxxxxxxxxxxxxxx
Mon Feb 21 23:26:50 2011 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon Feb 21 23:26:50 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Feb 21 23:26:50 2011 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon Feb 21 23:26:50 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Feb 21 23:26:50 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Feb 21 23:26:50 2011 [Tank_Server] Peer Connection Initiated with 46.5.199.53:1194
Mon Feb 21 23:26:52 2011 SENT CONTROL [Tank_Server]: 'PUSH_REQUEST' (status=1)
Mon Feb 21 23:26:52 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.0.0.250 255.255.255.0,route 192.168.10.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 192.168.10.6 192.168.10.5'
Mon Feb 21 23:26:52 2011 OPTIONS IMPORT: timers and/or timeouts modified
Mon Feb 21 23:26:52 2011 OPTIONS IMPORT: --ifconfig/up options modified
Mon Feb 21 23:26:52 2011 OPTIONS IMPORT: route options modified
Mon Feb 21 23:26:52 2011 ROUTE default_gateway=192.0.0.250
Mon Feb 21 23:26:52 2011 TAP-WIN32 device [LAN-Verbindung 4] opened: \\.\Global\{E4AFCF4C-2EDE-4996-9932-CC64AE8326B4}.tap
Mon Feb 21 23:26:52 2011 TAP-Win32 Driver Version 9.7
Mon Feb 21 23:26:52 2011 TAP-Win32 MTU=1500
Mon Feb 21 23:26:52 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.10.6/255.255.255.252 on interface {E4AFCF4C-2EDE-4996-9932-CC64AE8326B4} [DHCP-serv: 192.168.10.5, lease-time: 31536000]
Mon Feb 21 23:26:52 2011 Successful ARP Flush on interface [65540] {E4AFCF4C-2EDE-4996-9932-CC64AE8326B4}
Mon Feb 21 23:26:58 2011 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Mon Feb 21 23:26:58 2011 WARNING: potential route subnet conflict between local LAN [192.0.0.0/255.255.255.0] and remote VPN [192.0.0.0/255.255.255.0]
Mon Feb 21 23:26:58 2011 C:\WINDOWS\system32\route.exe ADD 192.0.0.250 MASK 255.255.255.0 192.168.10.5
Mon Feb 21 23:26:58 2011 Warning: address 192.0.0.250 is not a network address in relation to netmask 255.255.255.0
Mon Feb 21 23:26:58 2011 ROUTE: route addition failed using CreateIpForwardEntry: Falscher Parameter. [status=87 if_index=65540]
Mon Feb 21 23:26:58 2011 Route addition via IPAPI failed [adaptive]
Mon Feb 21 23:26:58 2011 Route addition fallback to route.exe
Hinzufgen der Route fehlgeschlagen: Der angegebene Maskenparameter ist ungltig. (Ziel & Maske) != Ziel.
Mon Feb 21 23:26:58 2011 C:\WINDOWS\system32\route.exe ADD 192.168.10.0 MASK 255.255.255.0 192.168.10.5
Mon Feb 21 23:26:58 2011 Route addition via IPAPI succeeded [adaptive]
Mon Feb 21 23:26:58 2011 Initialization Sequence Completed

Content-ID: 161295

Url: https://administrator.de/forum/openvpn-problem-dhcp-geht-ping-nicht-161295.html

Ausgedruckt am: 23.12.2024 um 03:12 Uhr

DonKamillo
DonKamillo 22.02.2011 um 11:54:14 Uhr
Goto Top
Hallöle,

ansich ist das LOG aussagekräftig genug.

Mon Feb 21 23:26:58 2011 Route addition fallback to route.exe
Hinzufgen der Route fehlgeschlagen: Der angegebene Maskenparameter ist ungltig. (Ziel & Maske) != Ziel.
Mon Feb 21 23:26:58 2011 C:\WINDOWS\system32\route.exe ADD 192.168.10.0 MASK 255.255.255.0 192.168.10.5

Welches Netz willst Du erreichen?? 192.0.0.x /24?? Dieser Bereich ist eigentlich reserviert...

Deine OVPN Clients stehen in einem virtuellen Netz (192.168.10.x , wobei der DHCP Server für dieses Netz die 192.168.10.5 ist (gleichzeitig das Standard GW fü die VPN Clients))
Du versuchst aber deinen Server im 192.168.0.x /24 Netz zu erreichen. Die Route kann jedoch am Client nicht hinzugefügt werden (Fehler im Log), da die Syntax nicht stimmt (192.0.0.250 ist keine Netzadresse sondern wahrscheinlich der Server den du erreichen möchtest.) Die Route sollte am Server so aussehen, wenn Du das gesamte Netz erreichen möchtest : push "route 192.0.0.250 255.255.255.0"

Gruß
istike2
istike2 22.02.2011 um 12:07:10 Uhr
Goto Top
Hallo,

die Situation sieht so aus:

wir haben hier ein kleines Netz mit einigen Clients. Sie haben den Server mit der IP-Adresse 192.0.0.250 (255.255.255.0) (DHCP 192.0.0.50 -192.0.0.199)

Dieser Server und damit auch das LAN dahinter sollte für die Kollegen (mit Notebooks) unterwegs via VPN erreichbar sein. Für diesen Zweck wollte ich die VPN mit der IP-Segment 192.168.10.0 (255.255.255.0) einrichten. (Hauptsache, sie sind unterschiedlich)

So weit ich weiß, spielt das Subnetz hier keine Rolle, es legt ja nur die Größe des Netzwerkes fest, oder?

Um sicher zu gehen, kann ich ein völlig anderes Segment wie 172.16.x.x.

Damit wäre es dann OK, oder?

am Server so aussehen, wenn Du das gesamte Netz erreichen möchtest : push "route 192.0.0.250 255.255.255.0"

Ja, ich wollte es genau so machen. Ich habe dann etwas falsch geschrieben:

Mon Feb 21 23:26:58 2011 Warning: address 192.0.0.250 is not a network address in relation to netmask 255.255.255.0

Was sollte dann das Subnetz für diese Adresse sein? Eventuell "255.255.0.0"?

Gr. I.
DonKamillo
DonKamillo 22.02.2011 um 13:19:33 Uhr
Goto Top
Es ist soweit alles OK, das VPN Netz kann so bleibe wie es ist.

Habe einen Fehler in dem Push-Route Befehl eingebaut. So muss es aussehen:
push "route 192.0.0.0 255.255.255.0"

192.0.0.250 ist ja dein Server und nicht das Netz!

Du kannst es auch am Client testen (bei bestehender VPN Verbindung) indem Du die Route manuell setzt.

route add 192.0.0.0 MASK 255.255.255.0 192.168.10.5

Möglicherweise eine Rückroute am Server setzen.

Gruß
istike2
istike2 22.02.2011 um 21:49:15 Uhr
Goto Top
Hallo,

Danke!

Ich habe sicherheitshalber sofort mit einem anderen IP-Segment (172.16...) probiert bzw. die Verbindung von einem Client ausser des LANs aufgebaut.

hier ist das LOG:

Tue Feb 22 21:39:54 2011 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 8 2010
Tue Feb 22 21:39:54 2011 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Tue Feb 22 21:39:54 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Feb 22 21:40:02 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue Feb 22 21:40:03 2011 LZO compression initialized
Tue Feb 22 21:40:03 2011 Control Channel MTU parms [ L:1562 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Feb 22 21:40:03 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue Feb 22 21:40:03 2011 Data Channel MTU parms [ L:1562 D:1300 EF:62 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Feb 22 21:40:03 2011 Fragmentation MTU parms [ L:1562 D:1300 EF:61 EB:135 ET:1 EL:0 AF:3/1 ]
Tue Feb 22 21:40:03 2011 Local Options hash (VER=V4): 'caff5189'
Tue Feb 22 21:40:03 2011 Expected Remote Options hash (VER=V4): '43a81564'
Tue Feb 22 21:40:03 2011 UDPv4 link local: [undef]
Tue Feb 22 21:40:03 2011 UDPv4 link remote: xxxxxxxxxxxxxxxxxxxx:1194
Tue Feb 22 21:40:03 2011 TLS: Initial packet from xxxxxxxxxxxxxxxxxxxxxxx:1194, sid=e76c9675 512c3711
Tue Feb 22 21:40:03 2011 VERIFY OK: depth=1, /C=DE/ST=BW/L=Karlsruhe/O=/CN=Tank_CA/emailAddress=xxxxxxxxxxxxxxxxxxxxxxxxxxx
Tue Feb 22 21:40:03 2011 VERIFY OK: depth=0, /C=DE/ST=BW/L=Karlsruhe/O=/CN=Tank_Server/emailAddress=xxxxxxxxxxxxxxxxxxxxxxxxxx
Tue Feb 22 21:40:03 2011 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Feb 22 21:40:03 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Feb 22 21:40:03 2011 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Feb 22 21:40:03 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Feb 22 21:40:03 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Feb 22 21:40:03 2011 [Tank_Server] Peer Connection Initiated with 46.5.199.53:1194
Tue Feb 22 21:40:06 2011 SENT CONTROL [Tank_Server]: 'PUSH_REQUEST' (status=1)
Tue Feb 22 21:40:06 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.0.0.0 255.255.255.0,route 172.16.1.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 172.16.1.6 172.16.1.5'
Tue Feb 22 21:40:06 2011 OPTIONS IMPORT: timers and/or timeouts modified
Tue Feb 22 21:40:06 2011 OPTIONS IMPORT: --ifconfig/up options modified
Tue Feb 22 21:40:06 2011 OPTIONS IMPORT: route options modified
Tue Feb 22 21:40:06 2011 ROUTE default_gateway=xxxxxxxxxxxxxxxx
Tue Feb 22 21:40:06 2011 TAP-WIN32 device [LAN-Verbindung 9] opened: \.Global{A0F71C88-793A-4C4E-A907-DACCCD9CF89B}.tap
Tue Feb 22 21:40:06 2011 TAP-Win32 Driver Version 9.7
Tue Feb 22 21:40:06 2011 TAP-Win32 MTU=1500
Tue Feb 22 21:40:06 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 172.16.1.6/255.255.255.252 on interface {A0F71C88-793A-4C4E-A907-DACCCD9CF89B} [DHCP-serv: 172.16.1.5, lease-time: 31536000]
Tue Feb 22 21:40:06 2011 NOTE: FlushIpNetTable failed on interface [120] {A0F71C88-793A-4C4E-A907-DACCCD9CF89B} (status=5) : Zugriff verweigert
Tue Feb 22 21:40:11 2011 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Tue Feb 22 21:40:11 2011 C:WINDOWSsystem32
oute.exe ADD 192.0.0.0 MASK 255.255.255.0 172.16.1.5
Tue Feb 22 21:40:11 2011 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=120]
Tue Feb 22 21:40:11 2011 Route addition via IPAPI failed [adaptive]
Tue Feb 22 21:40:11 2011 Route addition fallback to route.exe
Der angeforderte Vorgang erfordert erh”hte Rechte.
Tue Feb 22 21:40:13 2011 ERROR: Windows route add command failed [adaptive]: returned error code 1
Tue Feb 22 21:40:13 2011 C:WINDOWSsystem32
oute.exe ADD 172.16.1.0 MASK 255.255.255.0 172.16.1.5
Tue Feb 22 21:40:13 2011 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=120]
Tue Feb 22 21:40:13 2011 Route addition via IPAPI failed [adaptive]
Tue Feb 22 21:40:13 2011 Route addition fallback to route.exe
Der angeforderte Vorgang erfordert erh”hte Rechte.
Tue Feb 22 21:40:16 2011 ERROR: Windows route add command failed [adaptive]: returned error code 1
Tue Feb 22 21:40:16 2011 Initialization Sequence Completed

Wenn ich richtig verstehe sind bestimmte Rechte nicht vorhanden was nicht wirklich verständlich ist, da ich als Admin angemeldet bin.

Hat jemand eine Idee, was los ist?

Danke.

Gr. I.
aqui
aqui 23.02.2011, aktualisiert am 18.10.2012 um 18:45:56 Uhr
Goto Top
Halt dich einfach ans OpenVPN Tutorial:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Da hast du eine laufende und funktionierende Konfig die auch noch Plattform unabhängig ist. Dann hast du auch solche Routing Probleme nicht.
istike2
istike2 24.02.2011 um 21:38:20 Uhr
Goto Top
Hallo Aqui,

ich habe deine Config-Vorschläge 1:1 übernommen (habe nur die Netz-Infos bzw. Pfaden geändert)

Ich habe nach wie vor dasselbe Problem:

Sowohl Server wie auch Clients werden als Verbunden angezeigt, DHCP funktioniert. Client bekommt die IP 172.16.2.6

Ports TCP und UDP sind im Router auf den Server 192.0.0.200 umgeleitei

Pingen ist nicht möglich. Es wird Zeitüberschreitung gemeldet:

Hier ist das Log des Clients:

Thu Feb 24 21:30:24 2011 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 8 2010
Thu Feb 24 21:30:24 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Feb 24 21:30:32 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Feb 24 21:30:32 2011 LZO compression initialized
Thu Feb 24 21:30:32 2011 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Feb 24 21:30:32 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Feb 24 21:30:32 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Feb 24 21:30:32 2011 Local Options hash (VER=V4): '41690919'
Thu Feb 24 21:30:32 2011 Expected Remote Options hash (VER=V4): '530fdded'
Thu Feb 24 21:30:32 2011 UDPv4 link local: [undef]
Thu Feb 24 21:30:32 2011 UDPv4 link remote:xxxxxxxxxxxxxxxx:1194
Thu Feb 24 21:30:32 2011 TLS: Initial packet from xxxxxxxxxxxxxxxxx:1194, sid=0f11d55a 2737bd4a
Thu Feb 24 21:30:32 2011 VERIFY OK: depth=1, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxxxxxxxxxx/CN=Tank_CA/emailAddress=xxxxxxxxxxxxxxxxxxxxx
Thu Feb 24 21:30:32 2011 VERIFY OK: nsCertType=SERVER
Thu Feb 24 21:30:32 2011 VERIFY OK: depth=0, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxxxxxxxxxx/CN=Tank_Server/emailAddress=xxxxxxxxxxxxxxxxxxxxxx
Thu Feb 24 21:30:33 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Feb 24 21:30:33 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Feb 24 21:30:33 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Feb 24 21:30:33 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Feb 24 21:30:33 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Feb 24 21:30:33 2011 [Tank_Server] Peer Connection Initiated with 46.5.199.53:1194
Thu Feb 24 21:30:35 2011 SENT CONTROL [Tank_Server]: 'PUSH_REQUEST' (status=1)
Thu Feb 24 21:30:35 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.0.0.0 255.255.255.0,route 172.16.2.1,topology net30,ping 10,ping-restart 120,ifconfig 172.16.2.6 172.16.2.5'
Thu Feb 24 21:30:35 2011 OPTIONS IMPORT: timers and/or timeouts modified
Thu Feb 24 21:30:35 2011 OPTIONS IMPORT: --ifconfig/up options modified
Thu Feb 24 21:30:35 2011 OPTIONS IMPORT: route options modified
Thu Feb 24 21:30:35 2011 ROUTE default_gateway=xxxxxxxxxxxxxxxxx
Thu Feb 24 21:30:35 2011 TAP-WIN32 device [LAN-Verbindung 9] opened: \\.\Global\{A0F71C88-793A-4C4E-A907-DACCCD9CF89B}.tap
Thu Feb 24 21:30:35 2011 TAP-Win32 Driver Version 9.7
Thu Feb 24 21:30:35 2011 TAP-Win32 MTU=1500
Thu Feb 24 21:30:35 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 172.16.2.6/255.255.255.252 on interface {A0F71C88-793A-4C4E-A907-DACCCD9CF89B} [DHCP-serv: 172.16.2.5, lease-time: 31536000]
Thu Feb 24 21:30:35 2011 NOTE: FlushIpNetTable failed on interface [119] {A0F71C88-793A-4C4E-A907-DACCCD9CF89B} (status=5) : Zugriff verweigert
Thu Feb 24 21:30:41 2011 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Thu Feb 24 21:30:43 2011 C:\WINDOWS\system32\route.exe ADD 192.0.0.0 MASK 255.255.255.0 172.16.2.5
Thu Feb 24 21:30:43 2011 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=119]
Thu Feb 24 21:30:43 2011 Route addition via IPAPI failed [adaptive]
Thu Feb 24 21:30:43 2011 Route addition fallback to route.exe
Der angeforderte Vorgang erfordert erh”hte Rechte.
Thu Feb 24 21:30:45 2011 ERROR: Windows route add command failed [adaptive]: returned error code 1
Thu Feb 24 21:30:45 2011 C:\WINDOWS\system32\route.exe ADD 172.16.2.1 MASK 255.255.255.255 172.16.2.5
Thu Feb 24 21:30:45 2011 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=119]
Thu Feb 24 21:30:45 2011 Route addition via IPAPI failed [adaptive]
Thu Feb 24 21:30:45 2011 Route addition fallback to route.exe
Der angeforderte Vorgang erfordert erh”hte Rechte.
Thu Feb 24 21:30:47 2011 ERROR: Windows route add command failed [adaptive]: returned error code 1
Thu Feb 24 21:30:47 2011 Initialization Sequence Completed

Das Problem liegt also eindeutig an irgendwelchen Rechten...

Hast du eventuell eine Idee, was ich noch kontrollieren könnte?

Danke für die Hilfe.

Gr. I.

EDIT:

Es ist interessant, dass die erstellen TAP-Netzwerkkarte total falsche Einstellungen hat:

Physikalische Adresse: 00-FF-8E-25-94-14
IP-Adresse: 192.168.10.1
Subnetzmaske: 255.255.255.252
Standardgateway:
DHCP-Server: 192.168.10.2
Lease erhalten: 21.02.2011 23:03:05
Lease läuft ab: 21.02.2012 23:03:05
DNS-Server:
WINS-Server:

Per DHCP wird dem Client das richtige IP-Segment vermittelt, für sich selbst hat der Server ein völlig falsche IP-Adresse vergeben.

Hier ist die Config-Datei des Servers:

port 1194
proto udp
dev tun0
pkcs12 C:\\Programme\\OpenVPN\\easy-rsa\\keys\\Tank_Server.p12
dh C:\\Programme\\OpenVPN\\easy-rsa\\keys\\dh1024.pem
mode server
server 172.16.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.0.0.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3

Wenn ich allerdings die Maus über dem OVPN-GUI halte, kommt die Meldung, dass "Assigned-IP: "172.16.2.1"

Ich verstehe nur "Bahnhof"
aqui
aqui 25.02.2011, aktualisiert am 18.10.2012 um 18:45:58 Uhr
Goto Top
Relevant ist was am tun interface steht. Also wenn der Tunnel steht, dann solltest du einmal ein ipconfig eingeben und sehen was am tun/tap device steht ! Dort muss ein Interface mit diesem Namen zu sehen sein !!
Weiterhin relevant ist wie die Routing Tabelle bei aktivem Tunnel Link aussieht !!?
Ein route print zeigt dir das an !
Hier kannst du dann sehen ob die remoten Netze mit "push route x.y.z..." richtig propagiert sind.
Zwei Dinge sind sehr auffällig bei dir in der ansonsten korrekten Konfig:
  • Die Fehlermeldung "...ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=119] " zeigt das du unter dem User mit dem OpenVPN rennt vermutlich keine ausreichenden Rechte hast um das tun/tap Interface zu aktivieren. Die "Zugriff verweigert" Message dadrüber erhärtet diese Vermutung ?!
Ggf. solltest du einmal statt des tun Devices ein tap Device nehmen oder deine Rechte überprüfen. Das ist in jedem Falle ein ernster Fehler den du fixen musst !
  • push "route 192.0.0.0 255.255.255.0" ist natürlich schon ein mehr als grenzwertiger Befehl in der Beziehung das 192.0.0.0 kein privates_RFC_1918_IP_Netzwerk ist, also kein privates Netzwerk !!
Dieses Netzwerk ist von der IANA reserviert. Du solltest hier also dich besser an den RFC 1918 Standard halten und private IP Netze für lokale Netze benutzen !

Folgende weitere Dinge solltest du unbedingt prüfen wenn du remote Endgeräte pingst:
  • Das du die #comment-toc6 VPN_Adress_Design_Regeln eingehalten ?
  • Hast du bedacht das das Routing für die remoten Netze auf den OpenVPN Router zeigen muss. Wichtig wenn du DSL Router und OpenVPN Server getrennt hast. Siehe #comment-toc8 hier ! Dann geht das NICHT ohne statische Routen !
  • Ganz wichtig: die lokale Firewall dieser Engeräte muss angepasst werden in den erweiterten Einstellungen, das sie Pakete aus diesen remoten Netzen erlaubt ! Sonst blockt sie alles was NICHT lokal ist ! Passe das also an und achte zudem darauf das ICMP Ping dort erlaubt ist unter dem Button "ICMP" (Ping) muss der Haken bei "Auf eingehende Echos antworten" aktiviert sein !
Als Empfehlung solltest du auch erstmal beim Test besser das Kommando ifconfig-pool-persist ipp.txt weglassen zum Cachen der Leases, denn vielen Forenbeiträge sagen das dies bei Windows in Verbindung mit tun Interfaces nicht funktioniert und zu weiteren Problemen führt.
Benötigen tut man dieses Kommando so oder so nicht !

Wenn du das alles beachtest sollte das im Handumdrehen laufen ! Das ist eine simple Standardkonfig die millionenfach so im aktiven Einsatz ist !
istike2
istike2 27.02.2011 um 19:15:11 Uhr
Goto Top
Hallo Aqui,

danke. Hier sind die ersten Ergebnisse:

1. Ich habe das IP-Segment des Firmennetzes auf 192.168.1.x geändert.
2. Ich habe sowohl den VPN-Server wie auch den Client - aus ihrem Kontextmenü als Admin gestartet.

3. hier ist das Log des Clients:

Sun Feb 27 19:33:32 2011 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 8 2010
Sun Feb 27 19:33:32 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun Feb 27 19:33:39 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Feb 27 19:33:39 2011 LZO compression initialized
Sun Feb 27 19:33:39 2011 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Feb 27 19:33:39 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun Feb 27 19:33:39 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sun Feb 27 19:33:39 2011 Local Options hash (VER=V4): '41690919'
Sun Feb 27 19:33:39 2011 Expected Remote Options hash (VER=V4): '530fdded'
Sun Feb 27 19:33:39 2011 UDPv4 link local: [undef]
Sun Feb 27 19:33:39 2011 UDPv4 link remote: xxxxxxxxxxxxxxxxxxxxxx:1194
Sun Feb 27 19:33:39 2011 TLS: Initial packet from xxxxxxxxxxxxxxxxxxxxxxx:1194, sid=a15c3860 9e10e8f8
Sun Feb 27 19:33:40 2011 VERIFY OK: depth=1, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxxxxxxx/CN=Tank_CA/emailAddressxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Sun Feb 27 19:33:40 2011 VERIFY OK: nsCertType=SERVER
Sun Feb 27 19:33:40 2011 VERIFY OK: depth=0, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxxxxxxxx/CN=xxxxxxxxxxxxxxx/emailAddress=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Sun Feb 27 19:33:41 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Feb 27 19:33:41 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 27 19:33:41 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Feb 27 19:33:41 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 27 19:33:41 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sun Feb 27 19:33:41 2011 [Tank_Server] Peer Connection Initiated with xxxxxxxxxxxxxxxxxxx:1194
Sun Feb 27 19:33:43 2011 SENT CONTROL [Tank_Server]: 'PUSH_REQUEST' (status=1)
Sun Feb 27 19:33:43 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 172.16.2.1,topology net30,ping 10,ping-restart 120,ifconfig 172.16.2.6 172.16.2.5'
Sun Feb 27 19:33:43 2011 OPTIONS IMPORT: timers and/or timeouts modified
Sun Feb 27 19:33:43 2011 OPTIONS IMPORT: --ifconfig/up options modified
Sun Feb 27 19:33:43 2011 OPTIONS IMPORT: route options modified
Sun Feb 27 19:33:43 2011 ROUTE default_gateway=192.168.0.1
Sun Feb 27 19:33:44 2011 TAP-WIN32 device [LAN-Verbindung 9] opened: \\.\Global\{A0F71C88-793A-4C4E-A907-DACCCD9CF89B}.tap
Sun Feb 27 19:33:44 2011 TAP-Win32 Driver Version 9.7
Sun Feb 27 19:33:44 2011 TAP-Win32 MTU=1500
Sun Feb 27 19:33:44 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 172.16.2.6/255.255.255.252 on interface {A0F71C88-793A-4C4E-A907-DACCCD9CF89B} [DHCP-serv: 172.16.2.5, lease-time: 31536000]
Sun Feb 27 19:33:44 2011 Successful ARP Flush on interface [119] {A0F71C88-793A-4C4E-A907-DACCCD9CF89B}
Sun Feb 27 19:33:49 2011 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Sun Feb 27 19:33:50 2011 C:\WINDOWS\system32\route.exe ADD 192.168.1.0 MASK 255.255.255.0 172.16.2.5
Sun Feb 27 19:33:50 2011 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Sun Feb 27 19:33:50 2011 Route addition via IPAPI succeeded [adaptive]
Sun Feb 27 19:33:50 2011 C:\WINDOWS\system32\route.exe ADD 172.16.2.1 MASK 255.255.255.255 172.16.2.5
Sun Feb 27 19:33:51 2011 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Sun Feb 27 19:33:51 2011 Route addition via IPAPI succeeded [adaptive]
Sun Feb 27 19:33:51 2011 Initialization Sequence Completed

4. hier ist das Ergebnis des "Route Print" auf dem Server:

IPv4-Routentabelle
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 ff 8e 25 94 14 ...... TAP-Win32 Adapter V9
0x3 ...00 23 c3 f5 ac 61 ...... Hamachi Network Interface
0x10005 ...00 04 23 b7 e8 aa ...... Intel(R) PRO/1000 CT Network Connection
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.1.250 192.168.1.200 1
5.0.0.0 255.0.0.0 5.245.172.97 5.245.172.97 20
5.245.172.97 255.255.255.255 127.0.0.1 127.0.0.1 20
5.255.255.255 255.255.255.255 5.245.172.97 5.245.172.97 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
172.16.2.0 255.255.255.252 172.16.2.1 172.16.2.1 30
172.16.2.1 255.255.255.255 127.0.0.1 127.0.0.1 30
172.16.255.255 255.255.255.255 172.16.2.1 172.16.2.1 30
192.168.1.0 255.255.255.0 192.168.1.200 192.168.1.200 20
192.168.1.200 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.1.255 255.255.255.255 192.168.1.200 192.168.1.200 20
224.0.0.0 240.0.0.0 5.245.172.97 5.245.172.97 20
224.0.0.0 240.0.0.0 172.16.2.1 172.16.2.1 30
224.0.0.0 240.0.0.0 192.168.1.200 192.168.1.200 20
255.255.255.255 255.255.255.255 5.245.172.97 5.245.172.97 1
255.255.255.255 255.255.255.255 172.16.2.1 172.16.2.1 1
255.255.255.255 255.255.255.255 192.168.1.200 192.168.1.200 1
Standardgateway: 192.168.1.250
St„ndige Routen:
Keine

5. hier ist das "Route Print" des Clients:

Schnittstellenliste
119...00 ff a0 f7 1c 88 ......TAP-Win32 Adapter V9
14...00 21 86 4c 8c 04 ......Bluetooth-Ger„t (PAN)
12...00 21 5c 4c bb d3 ......Intel(R) Wireless WiFi Link 4965AGN
11...00 21 70 9a f1 a0 ......Broadcom NetXtreme 57xx-Gigabit-Controller
1...........................Software Loopback Interface 1
15...00 00 00 00 00 00 00 e0 Microsoft-6zu4-Adapter
17...00 00 00 00 00 00 00 e0 Microsoft-6zu4-Adapter #2
22...00 00 00 00 00 00 00 e0 Microsoft-6zu4-Adapter #5

IPv4-Routentabelle
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.12 25
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
172.16.2.1 255.255.255.255 172.16.2.5 172.16.2.6 30
172.16.2.4 255.255.255.252 Auf Verbindung 172.16.2.6 286
172.16.2.6 255.255.255.255 Auf Verbindung 172.16.2.6 286
172.16.2.7 255.255.255.255 Auf Verbindung 172.16.2.6 286
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.12 281
192.168.0.12 255.255.255.255 Auf Verbindung 192.168.0.12 281
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.12 281
192.168.1.0 255.255.255.0 172.16.2.5 172.16.2.6 30
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 172.16.2.6 286
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.12 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
255.255.255.255 255.255.255.255 Auf Verbindung 172.16.2.6 286
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.12 281
St„ndige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Metrik
0.0.0.0 0.0.0.0 5.0.0.1 Standard
0.0.0.0 0.0.0.0 192.168.1.250 Standard

IPv6-Routentabelle
Aktive Routen:
If Metrik Netzwerkziel Gateway
135 58 ::/0 Auf Verbindung
1 306 ::1/128 Auf Verbindung
135 58 2001::/32 Auf Verbindung
135 306 2001:0:4137:9e76:14e0:3ee8:3f57:fff3/128
Auf Verbindung
119 286 fe80::/64 Auf Verbindung
12 281 fe80::/64 Auf Verbindung
135 306 fe80::/64 Auf Verbindung
135 306 fe80::14e0:3ee8:3f57:fff3/128
Auf Verbindung
12 281 fe80::3906:b828:623b:57a4/128
Auf Verbindung
119 286 fe80::b481:8417:f57b:4e73/128
Auf Verbindung
1 306 ff00::/8 Auf Verbindung
135 306 ff00::/8 Auf Verbindung
119 286 ff00::/8 Auf Verbindung
12 281 ff00::/8 Auf Verbindung
St„ndige Routen:
Keine

6. "Ganz wichtig: die lokale Firewall dieser Engeräte muss angepasst werden in den erweiterten Einstellungen, das sie Pakete aus diesen remoten Netzen erlaubt ! Sonst blockt sie alles was NICHT lokal ist ! Passe das also an und achte zudem darauf das ICMP Ping dort erlaubt ist unter dem Button "ICMP" (Ping) muss der Haken bei "Auf eingehende Echos antworten" aktiviert sein !"

Auf diesem SBS 2003 wird das Firewall durch RAS (o. ä) geregelt. Soll ich dort einen bestimmten Port öffnen?

7. Das Port UDP 1194 wurde natürlich auf den SBS 2002 Server umgeleitet. In diesem Fall also auf 192.168.1.200

Ich denke also dass beim Punkt 6 die Wurzel des Problems liegen kann.

Gr. I.
aqui
aqui 28.02.2011, aktualisiert am 18.10.2012 um 18:46:00 Uhr
Goto Top
Ja sicher ! Das ist die wichtigste Einstellung mit !
Und.... dein Punkt 1 ist die denkbar dümmste Idee gewesen in verbindung mit VPNs.
Besser du liest das hier bevor du solche contraproduktiven Einstellungen machst:
VPNs einrichten mit PPTP
istike2
istike2 28.02.2011 um 22:04:33 Uhr
Goto Top
Ok. Danke, dann ändere ich es weiter auf was "Exotisches"... Gr. I.
istike2
istike2 01.03.2011 um 20:16:39 Uhr
Goto Top
Hallo Aqui,

http://www.filefactory.com/file/cac036c/n/portfreigabe_SBS_2003.JPG

Ich habe versucht in dem Tool RAS and Routing das Port 1194 zu öffnen. Ist es richtig so?

Ich habe unter den Eigenschafter des VPN-Netzwerkadapters noch die folgenden Einstellungen vorgenommen:

1. NAT / Basisfirewall der OVPN-Netzwerkverbindung:

"An das Internet angeschloßene öffentlichen Schnittestelle"

2. Adresspool:

172.16.2.1. - 172.16.2.255 (Maske 255.255.255.0)

3. Dienste und Ports:

Ich habe den Dienst "OpenVPN" hinzugefügt

"Auf dieser Schnittstelle"
Eingehender UDP-Port 1194
Private Adresse: 172.16.2.1
Ausgehender Port: 1194

4. ICMP

Ich habe alle Optionen aktiviert.

Ausserdem habe ich das statische Route

Ziel: 192.168.1.0
Mask: 255.255.255.0
Gateway: 172.16.2.1
Metrik: 1

hinzugefügt.

Ping geht aktuell zwischen 172.16.2.1 und 172.16.2.6 (Also zwischen dem OVPN Server und Client) wieder nicht.

!!!! was mir auffällt: Laut der Config-Datei des OVPN-Servers sollte das Subnetz 255.255.255.0 sein. Wenn ich mir aber die "Details anschaue steht dort 255.255.255.252.

Auch dieses Zitat aus dem Log (Siehe unten) kann auf dieses Problem hinweisen.
Tue Mar 01 20:51:18 2011 NOTE: FlushIpNetTable failed on interface [131074] {8E259414-9074-4AF0-9A00-E477AFCFF9EB} (status=259) : Es sind keine Daten mehr verfügbar.
Tue Mar 01 20:51:18 2011 C:\WINDOWS\system32\route.exe ADD 172.16.2.0 MASK 255.255.255.0 172.16.2.2
Tue Mar 01 20:51:18 2011 Warning: route gateway is not reachable on any active network adapters: 172.16.2.2
Tue Mar 01 20:51:18 2011 Route addition via IPAPI failed [adaptive]
Tue Mar 01 20:51:18 2011 Route addition fallback to route.exe
Hinzufgen der Route fehlgeschlagen: Entweder ist der Schnittstellenindex ungltig oder das Gateway befindet sich nicht im gleichen Netzwerk wie die Schnittstelle. šberprfen Sie die IP-Adresstabelle fr diesen Rechner.


Kann es der Grund des Problems sein?

Nachdem ich diese Einstellungen vorgennommen habe, habe ich die Verbindung sowohl Cliensseitig wie auch Serverseitig abgebrochen und neugestartet. Den SBS-Server habe ich also nicht neugestartet.

Hier ist das Log des Servers:

Tue Mar 01 20:51:08 2011 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 8 2010
Tue Mar 01 20:51:08 2011 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.
Tue Mar 01 20:51:08 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 01 20:51:08 2011 Diffie-Hellman initialized with 1024 bit key
Tue Mar 01 20:51:08 2011 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 01 20:51:08 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue Mar 01 20:51:08 2011 ROUTE default_gateway=192.168.1.250
Tue Mar 01 20:51:08 2011 TAP-WIN32 device [LAN-Verbindung 3] opened: \\.\Global\{8E259414-9074-4AF0-9A00-E477AFCFF9EB}.tap
Tue Mar 01 20:51:08 2011 TAP-Win32 Driver Version 9.7
Tue Mar 01 20:51:08 2011 TAP-Win32 MTU=1500
Tue Mar 01 20:51:08 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 172.16.2.1/255.255.255.252 on interface {8E259414-9074-4AF0-9A00-E477AFCFF9EB} [DHCP-serv: 172.16.2.2, lease-time: 31536000]
Tue Mar 01 20:51:08 2011 Sleeping for 10 seconds...
Tue Mar 01 20:51:18 2011 NOTE: FlushIpNetTable failed on interface [131074] {8E259414-9074-4AF0-9A00-E477AFCFF9EB} (status=259) : Es sind keine Daten mehr verfügbar.
Tue Mar 01 20:51:18 2011 C:\WINDOWS\system32\route.exe ADD 172.16.2.0 MASK 255.255.255.0 172.16.2.2
Tue Mar 01 20:51:18 2011 Warning: route gateway is not reachable on any active network adapters: 172.16.2.2
Tue Mar 01 20:51:18 2011 Route addition via IPAPI failed [adaptive]
Tue Mar 01 20:51:18 2011 Route addition fallback to route.exe
Hinzufgen der Route fehlgeschlagen: Entweder ist der Schnittstellenindex ungltig oder das Gateway befindet sich nicht im gleichen Netzwerk wie die Schnittstelle. šberprfen Sie die IP-Adresstabelle fr diesen Rechner.
Tue Mar 01 20:51:18 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 01 20:51:18 2011 UDPv4 link local (bound): [undef]:1194
Tue Mar 01 20:51:18 2011 UDPv4 link remote: [undef]
Tue Mar 01 20:51:18 2011 MULTI: multi_init called, r=256 v=256
Tue Mar 01 20:51:18 2011 IFCONFIG POOL: base=172.16.2.4 size=62
Tue Mar 01 20:51:18 2011 Initialization Sequence Completed
Tue Mar 01 20:51:51 2011 MULTI: multi_create_instance called
Tue Mar 01 20:51:51 2011 xxxxxxxxxxxxxxxxx:64535 Re-using SSL/TLS context
Tue Mar 01 20:51:51 2011 xxxxxxxxxxxxxxxxx:64535 LZO compression initialized
Tue Mar 01 20:51:51 2011 xxxxxxxxxxxxxxxxx:64535 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 01 20:51:51 2011 xxxxxxxxxxxxxxxxx:64535 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 01 20:51:51 2011 xxxxxxxxxxxxxxxxx:64535 Local Options hash (VER=V4): '530fdded'
Tue Mar 01 20:51:51 2011 xxxxxxxxxxxxxxxxx:64535 Expected Remote Options hash (VER=V4): '41690919'
Tue Mar 01 20:51:51 2011 xxxxxxxxxxxxxxxxx:64535 TLS: Initial packet from 85.216.120.63:64535, sid=a90eac17 b8de4fc1
Tue Mar 01 20:51:51 2011 xxxxxxxxxxxxxxxxx:64535 VERIFY OK: depth=1, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxx_Tank/CN=Tank_CA/emailAddress=xxxxxxxxxxxxxxxxxxxxxxxxx
Tue Mar 01 20:51:51 2011 85.216.120.63:64535 VERIFY OK: depth=0, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxxx_Tank/CN=Tank_Client1/emailAddress=xxxxxxxxxxxxxxxxxxxxxxxxx
Tue Mar 01 20:51:52 2011 xxxxxxxxxxxxxxxxx:64535 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 01 20:51:52 2011 xxxxxxxxxxxxxxxxx:64535 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 01 20:51:52 2011 xxxxxxxxxxxxxxxxx:64535 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 01 20:51:52 2011 xxxxxxxxxxxxxxxxx:64535 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 01 20:51:52 2011 xxxxxxxxxxxxxxxxx:64535 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Mar 01 20:51:52 2011 xxxxxxxxxxxxxxxxx:64535 [Tank_Client1] Peer Connection Initiated with xxxxxxxxxxxxxxxxx:64535
Tue Mar 01 20:51:52 2011 Tank_Client1/xxxxxxxxxxxxxxxxx:64535 MULTI: Learn: 172.16.2.6 -> Tank_Client1/xxxxxxxxxxxxxxxxx:64535
Tue Mar 01 20:51:52 2011 Tank_Client1/xxxxxxxxxxxxxxxxx:64535 MULTI: primary virtual IP for Tank_Client1/xxxxxxxxxxxxxxxxx:64535: 172.16.2.6
Tue Mar 01 20:51:54 2011 Tank_Client1/xxxxxxxxxxxxxxxxx:64535 PUSH: Received control message: 'PUSH_REQUEST'
Tue Mar 01 20:51:54 2011 Tank_Client1/xxxxxxxxxxxxxxxxx:64535 SENT CONTROL [Tank_Client1]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 172.16.2.1,topology net30,ping 10,ping-restart 120,ifconfig 172.16.2.6 172.16.2.5' (status=1)


Gr. I.
aqui
aqui 04.03.2011, aktualisiert am 18.10.2012 um 18:46:03 Uhr
Goto Top
Achte daruf das der Winblows Server kein NAT/ICS macht, denn das ist ebenso eine Stolperstelle:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Transparentes Routing ist für dich Pflicht !
istike2
istike2 04.03.2011 um 19:19:51 Uhr
Goto Top
Danke für den Link:

was ich bisher gemacht habe:

Hier ist die Config-Datei des VPN-Servers, der selbst auf dem SBS 2003 Server eingerichtet worden ist. Mit dieser Confid hat DHCP funktioniert bzw. habe unter 172.16.2.1 den OVPN-Server und unter 192.168.1.200 den SBS Server erreicht. Die Clients hinter dem SBS Server sind allerdings dadurch nicht "sichtbar" geworden. DNS habe ich nocht eingerichtet, weil ich es nicht brauche. (Die Zeile mit der DNS habe ich testweise in dem Config gelassen.) Mir reicht es also völlig, wenn ich mittels IP-Adresse Netzwerklaufwerke oder Netzwerkdrucker einrichten kann, bzw. auf den FTP-Server zugreifen kann.

Bei diesem Test war RAS völlig deaktiviert anhand deiner Tut habe ich jetzt RAS mit der Option LAN-Routing aktiviert. (Das "blöde" 192.168-IP-Segment werde ich ändern. In diesem Testzeitraum lasse ich es kurzfristig noch so.)

port 1194
proto udp
dev tun
tun-mtu 1500
fragment 1300
mssfix
pkcs12 C:\\Programme\\OpenVPN\\easy-rsa\\keys\\Tank_Server.p12
dh C:\\Programme\\OpenVPN\\easy-rsa\\keys\\dh1024.pem
mode server
server 172.16.2.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DOMAIN xxxxxxxxxx.local"
push "dhcp-option DNS 192.168.1.200"
push "dhcp-option WINS 192.168.1.200"
tls-server
ifconfig-pool-persist ipp.txt
auth SHA1
cipher AES-256-CBC
keepalive 10 120
comp-lzo
verb 3

Die Sache ist durch die Änderungen nicht besser geworden. Die Änderungen die das Registry betreffen habe ich nicht durchgeführt, weil ich nicht verstehe, ob ich sie wirklich brauche.

Ich denke, dass die Schwierigkeiten damit zusammenhängen, dass die Gateways nicht (richtig) gesetzt werden. Die virtuellen Netzwerkkarten der VPN-Verbindung bekommen automatisch die Daten. Die Felder sind also leer.

Ich kann mir vorstellen, dass ich
1.entweder den Server-Config so schreiben müsste, dass das entsprechende Gateway eingerichtet wird
2. order trage ich die IP manuell in die Einstellungen der Karten.

Hier stell sich die was mein Gateway ist: es sollte ins SBS-Netz der SBS-Router sein. In meinem Fall 192.168.1.200

Sollte ich also die Zeile push "route 192.168.1.0 255.255.255.0" so ändern: push "route 192.168.1.0 255.255.255.0 192.168.1.200"

Eine andere Möglichkeit wäre wohl die zwei Netzerkkarten zu "bridgen". Ich habe hier in der SBS 2003-GUI leider keine Möglichkeit gefunden. (Unter W7 geht es aus dem Kontextmenü ganz einfach).

Falls du eine Idee hats, in welche Richtung es sich lohnt so gehen, danke dir!

Gr. I.
aqui
aqui 05.03.2011 um 09:25:27 Uhr
Goto Top
Du benötigst das Routing wenn du zwischen beiden Segmenten im Server routen musst ! Ohne das sind alle Segmente isoliert.
Vom Bridging der Karten kann man dir nur dringend abraten. Aus Performancesicht ist das ein erheblicher Rückschritt da du alles mit Broad- und Multicasts flutest....
Irgendwas stimmt an deinem Setup noch nicht oder du hast ein Problem mit der Firewall.
Das ist ein simples Standard OpenVPN setup was eigentlich in 20 Minuten mit ein paar Mausklicks erledigt ist.
istike2
istike2 05.03.2011 um 10:36:43 Uhr
Goto Top
Ja klar, Routing mache ich aber mit der Zeile:

"route 192.168.1.0 255.255.255.0" so ändern: push "route 192.168.1.0 255.255.255.0"

Damit sollte es erledigt sein. Dessen Ergebnis war auf dem Client mit dem Befehlt "print route" auch zu sehen.

Was FW betrifft war bisher RAS völlig deaktiviert. Ich habe es jetzt anhand des verlinkten Tutorials nur mit der Option LAN-Routing aktiviert. Was könnte es noch sein?

Ich habe also aus dem SBS-Netzt nur den Server selbst erreicht.
aqui
aqui 05.03.2011, aktualisiert am 18.10.2012 um 18:46:04 Uhr
Goto Top
Nur nochmal zum Verständnis nachgefragt: Dein Design sieht so aus:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
D.h. dein OpenVPN Win Server hat 2 NICs von denen eine das lokale LAN mit den Clients bedient und eine das LAN zum DSL Router, richtig ?
Mit
push "route 192.168.1.0 255.255.255.0"
machst du dann in der Konfig dein lokales LAN am Server zum remoten VPN Client bekannt, auch richtig ?
Das dein Client nicht auch in einem 192.168.1.0er IP Netz betrieben wird (IP Konflikt !!) hast du gelesen und diese folgenden Design Regeln befolgt ??
VPNs einrichten mit PPTP
Das sind zwingende Voraussetzungen !!

Wenn du nun die Client Verbindung öffnest kannst du dann...:
a.) die interne OpenVPN Server IP 172.16.2.1 anpingen ?
b.) Kannst du das lokale LAN Interface des Servers 192.168.1.x anpingen ? Achtung FW Einstellungen hier am Server beachten !
c.) Oben sieht man das da noch ein Hamachi Interface aktiv ist. Sowas ist bei VPN Tests immer kontraproduktiv da es zu gegenseitigen Beeinflussungen kommen kann. Für OpenVPN Tests sowas immer deaktivieren.

Diese Minimaltests solltest du erstmal zum Fliegen bringen !
istike2
istike2 07.03.2011 um 14:18:25 Uhr
Goto Top
Hallo Aqui,

Das Netz sieht so aus:

ein SBS 2003-er Server (jetzt endlich in LAN mit 10.1.1.0 face-smile) mit vier Clients. Der Server /10.1.1.200/ fungiert als DNS bzw. DHCP-Server und verbindet die Clients zum Router /10.1.1.250/. DHCP ist im Router /nur als Gateway zum Internet/ ist deaktiviert.

Auf dem SBS Server läuft der OVPN-Server /172.16.2.1/ im 172.16.2.0 Netz. Es besteht die Verbindung zu meinem Notebook /172.16.2.6/ WENN ich RAS auf dem SBS Netz deaktiviere. In diesem Fall kann ich beide Server (10.1.1.200 und 172.16.2.1) von meinem Notebook anpingen.

Was nicht geht:

Ich kann mein Notebook vom Server per Ping nicht erreichen. bzw. ich kann auch keinen anderen Client oder den Router selbst im 10.1.1.0 Netz erreichen, die direkt vom Server (durch Remote Desktop) ohne weitere zu erreichen sind.

Hamachi brauche ich wegen RD weil sonst nicht testen kann. Ich hoffe, dass das Problem nicht daran liegt. Ich habe mein Notebook auch als Domain-PC erfasst. Ich versuche mal die OVPN-Verbindung auch aus diesem Account zu testen. Die bisherigen Test habe ich immer so durchgeführt, dass mein NB kein Domain-Mitglied war.

Gr. I.
aqui
aqui 07.03.2011 um 17:12:09 Uhr
Goto Top
Das ist auch alles klar warum das nicht geht ! Dein Szenario sieht vermutlich so aus, oder:

10f4d1763bf16081f498eea5d9f79152

Das du nicht pingen kannst hat 2 wichtige Ursachen:
Deine Firewall im Notebook erlaubt keine ICMPs und auch keinen Zugang von fremden IPs was die Firewall in der Regel ja blockt !
Gehe also in die erweiterten Einstellungen, dann ICMP (Ping) und setze hier den Haken Auf eingehende Eches antworten !
Für alle anderen Dienste musst du ggf. den Port Bereich der Firewall entsprechend auf dein VPN Netz anpassen sonst blockt die Firewall Zugriffe darauf !

Das du keine anderen Geräte im Netz anpingen kannst ist doch ganz logisch !
Vermutlich haben die alle als Default Gateway den Router mit der 10.1.1.250 eingetragen ! Wenn du nun ein Gerät via VPN anpingst hast du einen 172.16.2.0er IP Adresse als Absender...logisch ! Damit senden lokale Geräte im 10er Netz nun alle alle Antwortpakete statt in den VPN Tunnel via VPN Server direkt zum Router. Klar, müssen sie auch, denn sie merken ja das das Zielnetz 172.16.2.0 nicht ihr lokales netzwerk ist also ab damit zum Router....
Der aber wiederum routet das ins Internet weil ihm (vermutlich) die statische Route auf den OpenVPN Server fehlt. Dort werden diese Pakete dann in den Filterlisten des Providers gleich in den Müll gedrückt werden. (Private nicht geroutete RFC 1918 IP Netze !)

Fazit: Was dir fehlt ist eine statische Route auf deinem Router die sagt: "Alle 172.16.2.0er Pakete bitte NICHT ins Internet sondern an die 10.1.1.200 !!". Dann gehen diese damit auch sauber an den OpenVPN Server und der schickt sie dann via VPN Tunnel zum Notebook wie es sich gehört !
Gehe also ins Web Setup deines Routers unter statische Routen und trage dort ein:
Zielnetz: 172.16.2.0, Maske: 255.255.255.0, Gateway: 10.1.1.200 Fertig ist der Lack !
Damit kommt dieses OpenVPN Drama bei dir dann endlich zu einem erfolgreichen Abschluss !!
istike2
istike2 07.03.2011 um 21:10:01 Uhr
Goto Top
Hallo Aqui,

danke für die Antwort und wirklich für deine ganze "Hilfsserie".

Jetzt klappt´s face-smile

Ich habe schon (fast) aufgegeben.

Gr. I.