brauche Hilfe bei OpenVPN mit DHCP-Konfig beim Bridging

[blacksun]

Hallo,

also ich bin so langsam am verzweifeln mit der OpenVPN-Konfig unter Freetz.

Konfiguriert habe ich das ganze wie hier beschrieben:
http://wiki.ip-phone-forum.de/softwa...ete:eek:penvpn
Ab dem Abschnitt Routing vs. Bridging.

Ich habe zwei verschiedene Server-Konfigs gestartet. Eine unter TCP und eine mit UDP auf verschiedenen Ports. Mit TCP funktioniert alles, mit UDP nicht.

FritzBox 1:
192.168.3.101
Diese Box übernimmt ist das Gateway ins internet
Diese Box hat die Std-AVM-Firmware.
Diese Box soll der DHCP für's gesamte LAN sein.
Die beiden Ports für OpenVPN werden geforwared (sowohl tcp als auch udp) auf die ip der Box2

FritzBox 2:
läuft als ip-Client im privaten LAN
192.168.3.102
Auf dieser läuft (wiegesagt zwei mal) der OpenVPN Server.

Meine Server-Konfig für TCP:

#  OpenVPN 2.1 Config, Sat Mar 21 15:53:51 CET 2009
proto tcp-server
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
tls-auth /tmp/flash/static.key 0
port 443
push "redirect-gateway"
ifconfig 192.168.200.98 255.255.255.0
push "route-gateway 192.168.200.98"
push "route 192.168.3.0 255.255.255.0"
max-clients 5
tun-mtu 1500
mssfix
verb 3
daemon
cipher BF-CBC
comp-lzo
float
keepalive 10 120

Meine Client-Konfig für TCP

client
dev tap
proto tcp
remote blacksun.dyndns.org 443
nobind
persist-key
persist-tun
ca "ca.crt"
cert "client1.crt"
key "client1.key"
tls-remote Eumex
tls-auth "OpenVPN_static_key.key" 1
auth SHA1
cipher BF-CBC
comp-lzo
verb 3

Meien Server-Konfig für UDP

#  OpenVPN 2.1 Config, Sat Mar 21 15:53:56 CET 2009
proto udp
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
tls-auth /tmp/flash/static.key 0
port 1194
push "redirect-gateway"
ifconfig 192.168.201.97 255.255.255.0
push "route-gateway 192.168.201.97"
push "route 192.168.3.0 255.255.255.0"
max-clients 4
tun-mtu 1500
mssfix
verb 3
daemon
cipher BF-CBC
comp-lzo
float
keepalive 10 120

Meine client-Konfig für udp:

client
dev tap
proto udp
remote blacksun.dyndns.org 1194
nobind
persist-key
persist-tun
ca "ca.crt"
cert "client1.crt"
key "client1.key"
tls-remote Eumex
tls-auth "OpenVPN_static_key.key" 1
auth SHA1
cipher BF-CBC
comp-lzo
verb 3

Grundsätzlich eine Verbindung kommt meistens schon zustande.
Allerdings erhalte ich bei TCP eine ip-Adresse von Box1 per DHCP, während bei UDP keine kommt.

Was mache ich falsch?
Was muss ich anders einstellen?

[MaxMuster]

- Mach mal nach der zweiten Server-Config noch den code-Block zu [/code]
- Die UDP-Config so kann nicht gehen, da sie nicht auf den Server-Port 1194 sondern den "TCP-Port" 443 geht.
- Welchen DHCP willst du denn nutzen? Im OpenVPN ist da nichts eingetragen...
- Wenn das im Zusammenhang mit deiner Frage zur ar7.cfg steht: Wenn du mehr als ein OpenVPN mit tap nutzt, musst du z.B. bei zwei Prozessen auch auch "tap1" usw. zur Brücke mit hinzufügen.

Jörg

[blacksun]

Hallo Jörg,

ich habe gehofft, dass Du antwortest, Du bist ja der Spezialist, was OpenVPN angeht.

- Die UDP-Config so kann nicht gehen, da sie nicht auf den Server-Port 1194 sondern den "TCP-Port" 443 geht.

Sorry, war ein Copy und Paste Fehler. Die Ports vom Client passen natürlich zu den Ports vom Server.

- Welchen DHCP willst du denn nutzen? Im OpenVPN ist da nichts eingetragen...

Nun wenn möglich den der box1

- Wenn das im Zusammenhang mit deiner Frage zur ar7.cfg steht: Wenn du mehr als ein OpenVPN mit tap nutzt, musst du z.B. bei zwei Prozessen auch auch "tap1" usw. zur Brücke mit hinzufügen.

ja, das tut sie.

Ist mir noch gar nicht aufgefallen, dass da zwei "taps" erzeugt werden. Hätt ich auch drauf kommen können.
Ich bastel heute schon zig Stunden an der Sache rum. Manchmal ist es doch besser, auch mal eine Pause zu machen. Aber der Ehrgeiz...


Die erste Box macht für das ganze LAN DHCP (einfach weil diese Box zuerst da war und DHCP schon immer macht). Erst später kam dann eine zweite Box zu probieren dazu, auf der ich dann mittels Freetz OpenVPN draufgepackt habe.
Da man (wie man es gelernt hat) Produktivsystem und Testsystem immer auseinander halten soll und es aber dennoch nur einen DHCP geben darf, dachte ich, die Box1 darf auch für's VPN DHCP machen.

Das funktioniert soweit auch schon eine Ewigkeit ganz gut. Allerdings hatte ich bisher immer einen WinXP-Laptop und als Internetanbindung für den Laptop (also den VPN-Client) eine Breitbandverbindung.

Da mich das Thema mobiles Internet und WindowsMobile sehr gereizt hat, hab ich mir nun bei ebay einen HTC Hermes ersteigert und mir ein simyo-Kärtchen zugelegt, einfach weil ich das auch mal probieren wollte.
Ich hab mir bewusst ein WindowsMobile-Gerät geholt, weil es dafür einen OpenVPN-Client gibt (http://ovpnppc.ziggurat29.com/ovpnppc-files.htm), für Symbian hingegen leider nicht.

Nun, ich dachte man installiert sich den Client (der übrigens genauso aussieht und bedient wird wie bei WinXP auch) und nimmt einfach 1-zu-1 die config vom Laptop, die da immer problemlos funktioniert hat.
Doch nichts war's. Über TCP bekomm ich keine Verbindung über GPRS/UMTS hin, weder wenn ich den Client auf dem PDA benutze noch wenn ich den PDA lediglich als Modem für den XP-Laptop nehme und dort den OpenVPN-Client nutze.

Da bin ich noch ziemlich ratlos, warum TCP-Verbindungen über das Handy-Netz immer so abbrechen:

TLS Error: client->client or server->server connection attempted from 78.42.159.42:443
Sat Mar 21 10:27:25 2009 Fatal TLS error (check_tls_errors_co), restarting
Sat Mar 21 10:27:25 2009 TCP/UDP: Closing socket

Bis zur Überprüfung von TLS-Remote kommt er immer, aber dann bricht das ganze immer ab. Der gleiche Laptop mit dem gleichen VPN-Client nur über DSL funktioniert hingegen ohne Probleme.

Nun ja, das ist auch der Grund, warum ich nun zusätzlich den OpenVPN auf einem UDP-Port lauschen lasse. Da kommt eine Verbindung zustande, und mit dem Laptop mit VPN-Client funktioniert die Verbindung auch.

Aber mit dem VPN-Client auf dem WindowsMobile-PDA, da kommt zwar auch eine Verbindung zustande, jedoch erhält das tap-Device auf dem PDA keine ip per DHCP zugeordnet, und ich bin nun am probieren, woran das wieder liegt.

Daher auch die Frage nach der ar7.cfg. Es könnte ja sein, dass ich dort was falsch konfiguriert habe und WinXP den Fehler ausgleich, Windows Mobile hingegen nicht.

[MaxMuster]

Wenn du keine IP bekommst, kann das auch am TAP-Treiber liegen. Probier mal für da tap-Interface
erstmal ipconfig /release und dann ipconfig /renew . Geht es denn, wenn du eine feste IP aus dem Netz direkt einträgst?

Jörg

[blacksun]

Wenn du keine IP bekommst, kann das auch am TAP-Treiber liegen. Probier mal für da tap-Interface
erstmal ipconfig /release und dann ipconfig /renew . Geht es denn, wenn du eine feste IP aus dem Netz direkt einträgst?

Hallo Jörg,

also das mit den Befehlen ist bei WindowsMobile gar nicht so einfach, da es keine Kommandozeile gibt. Aber ich hab da ein Tool, mit dem man das machen kann (vxUtil von http://www.cam.com/vxutil_pers.html).

Und Du wirst es nicht glauben, aber Dein Tip mit dem "es gibt für jede OpenVPN-Instanz ein neues tap-Device, das man bridgen muss" war Gold richtig. Ich habe jetzt das tap1 auch in die Bridge-Liste mit reingepackt und schon bekommt das tap-Device auf dem WM-Gerät auch eine ip aus meinem privaten lan.

Allerdings hab ich mich schon zu früh gefreut, ich komm leider immer noch nicht vom WM-Gerät runter. Ich kann zwar 127.0.0.1 und auch die 192.168.3.45, die das tap-Device auf dem Gerät nun bekommen hat, anpingen, aber ein Ping zur Box1 oder Box2 geht leider nicht.

Kann es sein, dass das was mit dem Routing nicht stimmt?

Hier das Log

Sat Mar 21 22:16:18 2009 OpenVPN 2.1_rc15e Win32-MSVC++ [SSL] [LZO2] built on Mar 15 2009
Sat Mar 21 22:16:18 2009 MANAGEMENT: TCP Socket listening on 127.0.0.1:10000
Sat Mar 21 22:16:18 2009 Need hold release from management interface, waiting...
Sat Mar 21 22:16:19 2009 MANAGEMENT: Client connected from 127.0.0.1:10000
Sat Mar 21 22:16:19 2009 Using Windows Connection Manager with destination '{097AFAB2-B067-4BB1-90CA-BCA9C553EECF}' resolving to provider guid {097AFAB2-B067-4BB1-90CA-BCA9C553EECF} (exclusive)
Sat Mar 21 22:16:26 2009 Acquisition of Windows Connection Manager provider succeeded...
Sat Mar 21 22:16:26 2009 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Sat Mar 21 22:16:26 2009 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sat Mar 21 22:16:26 2009 Control Channel Authentication: using '\Programme\OpenVPN\config\ovpnstatic.key' as a OpenVPN static key file
Sat Mar 21 22:16:26 2009 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Mar 21 22:16:26 2009 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Mar 21 22:16:26 2009 LZO compression initialized
Sat Mar 21 22:16:26 2009 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sat Mar 21 22:16:26 2009 MANAGEMENT: >STATE:1237670186,RESOLVE,,,
Sat Mar 21 22:16:26 2009 RESOLVE: Cannot resolve host address: tauscher.dyndns.org: [HOST_NOT_FOUND] The specified host is unknown.
Sat Mar 21 22:16:26 2009 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Sat Mar 21 22:16:26 2009 Local Options hash (VER=V4): '13a273ba'
Sat Mar 21 22:16:26 2009 Expected Remote Options hash (VER=V4): '360696c5'
Sat Mar 21 22:16:26 2009 MANAGEMENT: >STATE:1237670186,RESOLVE,,,
Sat Mar 21 22:16:26 2009 RESOLVE: Cannot resolve host address: tauscher.dyndns.org: [HOST_NOT_FOUND] The specified host is unknown.
Sat Mar 21 22:16:31 2009 RESOLVE: Cannot resolve host address: tauscher.dyndns.org: [HOST_NOT_FOUND] The specified host is unknown.
Sat Mar 21 22:16:36 2009 RESOLVE: Cannot resolve host address: tauscher.dyndns.org: [HOST_NOT_FOUND] The specified host is unknown.
Sat Mar 21 22:16:41 2009 RESOLVE: Cannot resolve host address: tauscher.dyndns.org: [HOST_NOT_FOUND] The specified host is unknown.
Sat Mar 21 22:16:47 2009 Socket Buffers: R=[32768->32768] S=[16384->16384]
Sat Mar 21 22:16:47 2009 UDPv4 link local (bound): [undef]
Sat Mar 21 22:16:47 2009 UDPv4 link remote: 78.42.159.42:1194
Sat Mar 21 22:16:47 2009 MANAGEMENT: >STATE:1237670207,WAIT,,,
Sat Mar 21 22:16:47 2009 MANAGEMENT: >STATE:1237670207,AUTH,,,
Sat Mar 21 22:16:47 2009 TLS: Initial packet from 78.42.159.42:1194, sid=796ec02f 262435d1
Sat Mar 21 22:16:52 2009 VERIFY OK: depth=1, /C=DE/ST=BW/L=Buehlertann/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=BlackSunSoftwareGmbH-CA/emailAddress=blacksun@directbox.com
Sat Mar 21 22:16:52 2009 VERIFY X509NAME OK: /C=DE/ST=BW/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=Eumex/emailAddress=blacksun@directbox.com
Sat Mar 21 22:16:52 2009 VERIFY OK: depth=0, /C=DE/ST=BW/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=Eumex/emailAddress=blacksun@directbox.com
Sat Mar 21 22:16:59 2009 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Mar 21 22:16:59 2009 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Mar 21 22:16:59 2009 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Mar 21 22:16:59 2009 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Mar 21 22:16:59 2009 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Mar 21 22:16:59 2009 [Eumex] Peer Connection Initiated with 78.42.159.42:1194
Sat Mar 21 22:17:01 2009 MANAGEMENT: >STATE:1237670221,GET_CONFIG,,,
Sat Mar 21 22:17:01 2009 SENT CONTROL [Eumex]: 'PUSH_REQUEST' (status=1)
Sat Mar 21 22:17:01 2009 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway,route-gateway 192.168.3.97,route 192.168.3.0 255.255.255.0'
Sat Mar 21 22:17:01 2009 OPTIONS IMPORT: route options modified
Sat Mar 21 22:17:01 2009 OPTIONS IMPORT: route-related options modified
Sat Mar 21 22:17:01 2009 ROUTE default_gateway=10.129.175.233
Sat Mar 21 22:17:01 2009 TAP-WIN32 device [TAP1:] opened: TAP1:
Sat Mar 21 22:17:01 2009 TAP-Win32 Driver Version 9.4 
Sat Mar 21 22:17:01 2009 TAP-Win32 MTU=1500
Sat Mar 21 22:17:01 2009 Successful ARP Flush on interface [3] TAP DEVICE 1
Sat Mar 21 22:17:06 2009 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Sat Mar 21 22:17:06 2009 Route: Waiting for TUN/TAP interface to come up...
Sat Mar 21 22:17:11 2009 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Sat Mar 21 22:17:11 2009 Route: Waiting for TUN/TAP interface to come up...
Sat Mar 21 22:17:12 2009 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Sat Mar 21 22:17:12 2009 Route: Waiting for TUN/TAP interface to come up...
Sat Mar 21 22:17:13 2009 TEST ROUTES: 2/2 succeeded len=1 ret=1 a=0 u/d=up
Sat Mar 21 22:17:13 2009 C:\WINDOWS\system32\route.exe ADD 78.42.159.42 MASK 255.255.255.255 10.129.175.233
Sat Mar 21 22:17:13 2009 ROUTE: route addition failed using CreateIpForwardEntry: Der Parameter ist ungültig.   [status=87 if_index=196612]
Sat Mar 21 22:17:13 2009 Route addition via IPAPI failed [adaptive]
Sat Mar 21 22:17:13 2009 Route addition fallback to route.exe
Sat Mar 21 22:17:13 2009 ERROR: Windows route add command failed [adaptive]: external program did not execute -- returned error code -1
Sat Mar 21 22:17:13 2009 C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 10.129.175.233
Sat Mar 21 22:17:13 2009 Route deletion via IPAPI succeeded [adaptive]
Sat Mar 21 22:17:13 2009 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 192.168.3.97
Sat Mar 21 22:17:13 2009 Route addition via IPAPI succeeded [adaptive]
Sat Mar 21 22:17:13 2009 MANAGEMENT: >STATE:1237670233,ADD_ROUTES,,,
Sat Mar 21 22:17:13 2009 RESOLVE: Cannot parse IP address: 
Sat Mar 21 22:17:13 2009 WARNING: potential route subnet conflict between local LAN [192.168.3.0/255.255.255.0] and remote VPN [192.168.3.0/255.255.255.0]
Sat Mar 21 22:17:13 2009 C:\WINDOWS\system32\route.exe ADD 192.168.3.0 MASK 255.255.255.0 192.168.3.97
Sat Mar 21 22:17:13 2009 Route addition via IPAPI succeeded [adaptive]
Sat Mar 21 22:17:13 2009 Initialization Sequence Completed
Sat Mar 21 22:17:13 2009 MANAGEMENT: >STATE:1237670233,CONNECTED,SUCCESS,,78.42.159.42
Sat Mar 21 22:17:13 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:13 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:13 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:14 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:18 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:18 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:18 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:19 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:20 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:21 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:22 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:24 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:28 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:30 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:36 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:42 2009 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
Sat Mar 21 22:17:46 2009 TCP/UDP: Closing socket
Sat Mar 21 22:17:46 2009 C:\WINDOWS\system32\route.exe DELETE 192.168.3.0 MASK 255.255.255.0 192.168.3.97
Sat Mar 21 22:17:46 2009 Route deletion via IPAPI succeeded [adaptive]
Sat Mar 21 22:17:46 2009 C:\WINDOWS\system32\route.exe DELETE 78.42.159.42 MASK 255.255.255.255 10.129.175.233
Sat Mar 21 22:17:46 2009 ROUTE: route deletion failed using DeleteIpForwardEntry: Der Parameter ist ungültig.  
Sat Mar 21 22:17:46 2009 Route deletion via IPAPI failed [adaptive]
Sat Mar 21 22:17:46 2009 Route deletion fallback to route.exe
Sat Mar 21 22:17:46 2009 ERROR: Windows route delete command failed [adaptive]: external program did not execute -- returned error code -1
Sat Mar 21 22:17:46 2009 C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 192.168.3.97
Sat Mar 21 22:17:46 2009 Route deletion via IPAPI succeeded [adaptive]
Sat Mar 21 22:17:46 2009 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 10.129.175.233
Sat Mar 21 22:17:46 2009 ROUTE: route addition failed using CreateIpForwardEntry: Der Parameter ist ungültig.   [status=87 if_index=196612]
Sat Mar 21 22:17:46 2009 Route addition via IPAPI failed [adaptive]
Sat Mar 21 22:17:46 2009 Route addition fallback to route.exe
Sat Mar 21 22:17:46 2009 ERROR: Windows route add command failed [adaptive]: external program did not execute -- returned error code -1
Sat Mar 21 22:17:46 2009 Closing TUN/TAP interface
Sat Mar 21 22:17:46 2009 SIGTERM[hard,] received, process exiting
Sat Mar 21 22:17:46 2009 MANAGEMENT: >STATE:1237670266,EXITING,SIGTERM,,
Sat Mar 21 22:17:46 2009 Releasing Windows Connection Manager provider

ach ja, und so sieht das ganze mit TCP auf Port 443 aus, wo nicht mal eine Verbindung zustande kommt:

Sat Mar 21 22:18:24 2009 OpenVPN 2.1_rc15e Win32-MSVC++ [SSL] [LZO2] built on Mar 15 2009
Sat Mar 21 22:18:24 2009 MANAGEMENT: TCP Socket listening on 127.0.0.1:10000
Sat Mar 21 22:18:24 2009 Need hold release from management interface, waiting...
Sat Mar 21 22:18:24 2009 MANAGEMENT: Client connected from 127.0.0.1:10000
Sat Mar 21 22:18:25 2009 Using Windows Connection Manager with destination '{097AFAB2-B067-4BB1-90CA-BCA9C553EECF}' resolving to provider guid {097AFAB2-B067-4BB1-90CA-BCA9C553EECF} (exclusive)
Sat Mar 21 22:18:30 2009 Acquisition of Windows Connection Manager provider succeeded...
Sat Mar 21 22:18:30 2009 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Sat Mar 21 22:18:30 2009 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sat Mar 21 22:18:31 2009 Control Channel Authentication: using '\Programme\OpenVPN\config\ovpnstatic.key' as a OpenVPN static key file
Sat Mar 21 22:18:31 2009 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Mar 21 22:18:31 2009 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Mar 21 22:18:31 2009 LZO compression initialized
Sat Mar 21 22:18:31 2009 Control Channel MTU parms [ L:1576 D:168 EF:68 EB:0 ET:0 EL:0 ]
Sat Mar 21 22:18:31 2009 MANAGEMENT: >STATE:1237670311,RESOLVE,,,
Sat Mar 21 22:18:31 2009 RESOLVE: Cannot resolve host address: tauscher.dyndns.org: [HOST_NOT_FOUND] The specified host is unknown.
Sat Mar 21 22:18:31 2009 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Sat Mar 21 22:18:31 2009 Local Options hash (VER=V4): 'e39a3273'
Sat Mar 21 22:18:31 2009 Expected Remote Options hash (VER=V4): '3c14feac'
Sat Mar 21 22:18:31 2009 MANAGEMENT: >STATE:1237670311,RESOLVE,,,
Sat Mar 21 22:18:31 2009 RESOLVE: Cannot resolve host address: tauscher.dyndns.org: [HOST_NOT_FOUND] The specified host is unknown.
Sat Mar 21 22:18:36 2009 RESOLVE: Cannot resolve host address: tauscher.dyndns.org: [HOST_NOT_FOUND] The specified host is unknown.
Sat Mar 21 22:18:41 2009 RESOLVE: Cannot resolve host address: tauscher.dyndns.org: [HOST_NOT_FOUND] The specified host is unknown.
Sat Mar 21 22:18:46 2009 RESOLVE: Cannot resolve host address: tauscher.dyndns.org: [HOST_NOT_FOUND] The specified host is unknown.
Sat Mar 21 22:18:52 2009 Attempting to establish TCP connection with 78.42.159.42:443
Sat Mar 21 22:18:52 2009 MANAGEMENT: >STATE:1237670332,TCP_CONNECT,,,
Sat Mar 21 22:18:53 2009 TCP connection established with 78.42.159.42:443
Sat Mar 21 22:18:53 2009 Socket Buffers: R=[32768->32768] S=[16384->16384]
Sat Mar 21 22:18:53 2009 TCPv4_CLIENT link local (bound): [undef]
Sat Mar 21 22:18:53 2009 TCPv4_CLIENT link remote: 78.42.159.42:443
Sat Mar 21 22:18:53 2009 MANAGEMENT: >STATE:1237670333,WAIT,,,
Sat Mar 21 22:18:54 2009 MANAGEMENT: >STATE:1237670334,AUTH,,,
Sat Mar 21 22:18:54 2009 TLS: Initial packet from 78.42.159.42:443, sid=adf86229 0da5e408
Sat Mar 21 22:19:05 2009 VERIFY OK: depth=1, /C=DE/ST=BW/L=Buehlertann/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=BlackSunSoftwareGmbH-CA/emailAddress=blacksun@directbox.com
Sat Mar 21 22:19:05 2009 VERIFY X509NAME OK: /C=DE/ST=BW/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=Eumex/emailAddress=blacksun@directbox.com
Sat Mar 21 22:19:05 2009 VERIFY OK: depth=0, /C=DE/ST=BW/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=Eumex/emailAddress=blacksun@directbox.com
Sat Mar 21 22:19:12 2009 TLS Error: unknown opcode received from 78.42.159.42:443 op=25
Sat Mar 21 22:19:12 2009 Fatal TLS error (check_tls_errors_co), restarting
Sat Mar 21 22:19:12 2009 TCP/UDP: Closing socket
Sat Mar 21 22:19:12 2009 SIGUSR1[soft,tls-error] received, process restarting
Sat Mar 21 22:19:12 2009 MANAGEMENT: >STATE:1237670352,RECONNECTING,tls-error,,
Sat Mar 21 22:19:12 2009 Restart pause, 5 second(s)
Sat Mar 21 22:19:17 2009 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Sat Mar 21 22:19:17 2009 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sat Mar 21 22:19:17 2009 Re-using SSL/TLS context
Sat Mar 21 22:19:17 2009 LZO compression initialized
Sat Mar 21 22:19:17 2009 Control Channel MTU parms [ L:1576 D:168 EF:68 EB:0 ET:0 EL:0 ]
Sat Mar 21 22:19:17 2009 MANAGEMENT: >STATE:1237670357,RESOLVE,,,
Sat Mar 21 22:19:17 2009 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Sat Mar 21 22:19:17 2009 Local Options hash (VER=V4): 'e39a3273'
Sat Mar 21 22:19:17 2009 Expected Remote Options hash (VER=V4): '3c14feac'
Sat Mar 21 22:19:17 2009 Attempting to establish TCP connection with 78.42.159.42:443
Sat Mar 21 22:19:17 2009 MANAGEMENT: >STATE:1237670357,TCP_CONNECT,,,
Sat Mar 21 22:19:18 2009 TCP connection established with 78.42.159.42:443
Sat Mar 21 22:19:18 2009 Socket Buffers: R=[32768->32768] S=[16384->16384]
Sat Mar 21 22:19:18 2009 TCPv4_CLIENT link local (bound): [undef]
Sat Mar 21 22:19:18 2009 TCPv4_CLIENT link remote: 78.42.159.42:443
Sat Mar 21 22:19:18 2009 MANAGEMENT: >STATE:1237670358,WAIT,,,
Sat Mar 21 22:19:19 2009 MANAGEMENT: >STATE:1237670359,AUTH,,,
Sat Mar 21 22:19:19 2009 TLS: Initial packet from 78.42.159.42:443, sid=b6c16ddc d0e46bef
Sat Mar 21 22:19:30 2009 VERIFY OK: depth=1, /C=DE/ST=BW/L=Buehlertann/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=BlackSunSoftwareGmbH-CA/emailAddress=blacksun@directbox.com
Sat Mar 21 22:19:30 2009 VERIFY X509NAME OK: /C=DE/ST=BW/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=Eumex/emailAddress=blacksun@directbox.com
Sat Mar 21 22:19:30 2009 VERIFY OK: depth=0, /C=DE/ST=BW/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=Eumex/emailAddress=blacksun@directbox.com
Sat Mar 21 22:19:38 2009 TLS Error: Unroutable control packet received from 78.42.159.42:443 (si=3 op=P_ACK_V1)
Sat Mar 21 22:19:38 2009 Fatal TLS error (check_tls_errors_co), restarting
Sat Mar 21 22:19:38 2009 TCP/UDP: Closing socket
Sat Mar 21 22:19:38 2009 SIGUSR1[soft,tls-error] received, process restarting
Sat Mar 21 22:19:38 2009 MANAGEMENT: >STATE:1237670378,RECONNECTING,tls-error,,
Sat Mar 21 22:19:38 2009 Restart pause, 5 second(s)
Sat Mar 21 22:19:43 2009 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Sat Mar 21 22:19:43 2009 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sat Mar 21 22:19:43 2009 Re-using SSL/TLS context
Sat Mar 21 22:19:43 2009 LZO compression initialized
Sat Mar 21 22:19:43 2009 Control Channel MTU parms [ L:1576 D:168 EF:68 EB:0 ET:0 EL:0 ]
Sat Mar 21 22:19:43 2009 MANAGEMENT: >STATE:1237670383,RESOLVE,,,
Sat Mar 21 22:19:43 2009 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Sat Mar 21 22:19:43 2009 Local Options hash (VER=V4): 'e39a3273'
Sat Mar 21 22:19:43 2009 Expected Remote Options hash (VER=V4): '3c14feac'
Sat Mar 21 22:19:43 2009 Attempting to establish TCP connection with 78.42.159.42:443
Sat Mar 21 22:19:43 2009 MANAGEMENT: >STATE:1237670383,TCP_CONNECT,,,
Sat Mar 21 22:19:44 2009 TCP connection established with 78.42.159.42:443
Sat Mar 21 22:19:44 2009 Socket Buffers: R=[32768->32768] S=[16384->16384]
Sat Mar 21 22:19:44 2009 TCPv4_CLIENT link local (bound): [undef]
Sat Mar 21 22:19:44 2009 TCPv4_CLIENT link remote: 78.42.159.42:443
Sat Mar 21 22:19:44 2009 MANAGEMENT: >STATE:1237670384,WAIT,,,
Sat Mar 21 22:19:44 2009 MANAGEMENT: >STATE:1237670384,AUTH,,,
Sat Mar 21 22:19:44 2009 TLS: Initial packet from 78.42.159.42:443, sid=4cb84c12 9a2fc84d
Sat Mar 21 22:19:56 2009 VERIFY OK: depth=1, /C=DE/ST=BW/L=Buehlertann/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=BlackSunSoftwareGmbH-CA/emailAddress=blacksun@directbox.com
Sat Mar 21 22:19:56 2009 VERIFY X509NAME OK: /C=DE/ST=BW/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=Eumex/emailAddress=blacksun@directbox.com
Sat Mar 21 22:19:56 2009 VERIFY OK: depth=0, /C=DE/ST=BW/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=Eumex/emailAddress=blacksun@directbox.com
Sat Mar 21 22:20:04 2009 TLS Error: unknown opcode received from 78.42.159.42:443 op=20
Sat Mar 21 22:20:04 2009 Fatal TLS error (check_tls_errors_co), restarting
Sat Mar 21 22:20:04 2009 TCP/UDP: Closing socket
Sat Mar 21 22:20:04 2009 SIGUSR1[soft,tls-error] received, process restarting
Sat Mar 21 22:20:04 2009 MANAGEMENT: >STATE:1237670404,RECONNECTING,tls-error,,
Sat Mar 21 22:20:04 2009 Restart pause, 5 second(s)
Sat Mar 21 22:20:06 2009 SIGTERM[hard,init_instance] received, process exiting
Sat Mar 21 22:20:06 2009 MANAGEMENT: >STATE:1237670406,EXITING,init_instance,,
Sat Mar 21 22:20:06 2009 Releasing Windows Connection Manager provider

[MaxMuster]

Weche IP hat denn die Box im ifconfig des OpnVPN? die 192.168.3.97, denn die IP taucht als Gateway auf??
Kannst du die Box anpingen? Oder ein "arp -a" bekommen, nach dem Ping?
Da du eine IP aus dem 192.168.3.0-er Netz hast, brauchst du keine Route dafür pushen...

Jörg

[blacksun]

Weche IP hat denn die Box im ifconfig des OpnVPN? die 192.168.3.97, denn die IP taucht als Gateway auf??
Kannst du die Box anpingen? Oder ein "arp -a" bekommen, nach dem Ping?
Da du eine IP aus dem 192.168.3.0-er Netz hast, brauchst du keine Route dafür pushen...

Also,

die Box2 mit dem OpenVPN-Server darauf hat im ganz normalen LAN die 192.168.3.102.
siehe hier:
[Edit frank_m24: Bild vom externen Hoster in Link umgewandelt. Bitte benutzt den forumeigenen Dateimanager, um Bilder hochzuladen (Beitrag "Ändern" -> "Erweitert" -> "Anhänge verwalten").]
http://i42.*********com/ixgu4y.jpg




im Freetz-Menü sieht's so aus

http://i39.*********com/algths.jpg

http://i40.*********com/5dm63s.jpg

http://i44.*********com/w9uotl.jpg

Das mit der push "route 192.168.3.0 255.255.255.0" taucht nun auch nicht mehr auf.

Wie schon gesagt, ich kann weder 192.168.3.102 noch sonstwas im LAN, etwas die Box1 (192.168.3.101, die ja dhcp, gatewas in's Inet, DNS ist) anpingen.

Ich hab auch gleich probiert im Freetz (dort wo oben im Screenshot noch die .97 steht) auch die .102 zu setzen. Gleiches Ergebnis.

[MaxMuster]

Nimm noch den Haken bei "Clientverkehr umleiten" weg und versuche bitte, die Box über die .97 zu pingen.
Geht das mit "arp -a"?

Jörg

[blacksun]

Nimm noch den Haken bei "Clientverkehr umleiten" weg und versuche bitte, die Box über die .97 zu pingen.

Hallo Jörg,

das mit dem Clientverkehr umleiten scheint's gewesen zu sein.
Jetzt funktioniert der Ping in's LAN, sowohl auf .102 als auch das inet gateway .101.
Auch in's Internet komm ich jetzt über's VPN.

Kann ich nun dennoch sicher sein, dass jede Anwendung auf dem PDA jetzt ihren Weg durch das VPN nimmt und nicht doch den direkten Weg nimmt?
Ich hab hauptsächlich deshalb ein VPN, damit ich von unterwegs meinen traffic absichern kann, indem ich ihn über das heimische vpn leite.
bei der handy-datenverbindung geht es mir im vgl. zu öffentlichen hotspots weniger darum, dass da jemand mitlauscht, sondern dass da bestimmte dienste gesperrt werden (stichwort portsperre / -priorisierung)

Geht das mit "arp -a"?

Da gibt's ein Problem, unter WindowsMobile gibt es keine Kommandozeile, an der man das eingeben könnte.


Jetzt probier ich dasselbe mal OpenVPN-Instanz für TCP. Das gerade war ja alles UDP.
Oder meinst Du, dass das an was anderem liegt? Bei TCP kommt ja gar nicht erst eine Verbindung zustande.

[MaxMuster]

Kann ich nun dennoch sicher sein, dass jede Anwendung auf dem PDA jetzt ihren Weg durch das VPN nimmt und nicht doch den direkten Weg nimmt?

Das hängt von den Routen ab. Man sah nur im Log, dass es mit dem Löschen und Anlegen von Routen ein Problem gab. scheinbar auch mit dem "redirect-gateway" was ja genau das tut. Da musst du wohl noch etwas dran arbeiten, denn ohne den Befehl wird vermutlich beides möglich sein:
Du hast das default-Gateway vom Provider und dann noch eines, was die Fritzbox im DHCP geschickt hat... Ohne eine Konsole und die üblichen Windows-Befehle wird es schwer sein, das zu "debuggen".

Zu deinem TCP-Problem würde ich prüfen: nutzt vielleicht noch was anderes Port 443? Oder der Provider greift da "optimierend" ein, weil er https vermutet?

Jörg

[blacksun]

Das hängt von den Routen ab. Man sah nur im Log, dass es mit dem Löschen und Anlegen von Routen ein Problem gab. scheinbar auch mit dem "redirect-gateway" was ja genau das tut. Da musst du wohl noch etwas dran arbeiten, denn ohne den Befehl wird vermutlich beides möglich sein

Mist, genau das will ich ja eigentlich mit einem vpn erreichen, dass ich mir bei den applikationen keinen kopf mehr um verschlüsselung machen muss, weil alles den weg durch's vpn nimmt.

macht es eigentlich einen unterschied, ob ich das "redirect-gateway" per push vom server auf den client bringe oder ob ich es gleich direkt in das config-file vom client schreibe?

Zu deinem TCP-Problem würde ich prüfen: nutzt vielleicht noch was anderes Port 443? Oder der Provider greift da "optimierend" ein, weil er https vermutet?

hhmm, zumindest wüsste ich noch nichts davon.
prinzipiell schließe ich es mal aus, weil bis vom meinem wm-gerät lief nur eine instanz von ovpn, und zwar tcp und auf port 1194. so bin ich auch zu meinem ersten versuch mit dem ovpn auf wm gestartet.

edit:
hab's gerade nochmal probiert, indem ich die konfig auf dem server und vom client von udp auf tcp umgestellt habe. sprich nun tcp-1194. genau dasselbe spiel.

[MaxMuster]

Wo das redirect steht ist egal. Zur Erläuterung: redirect-gateway geht in die Routingtabelle, holt sich das Default-GW und setzt eine Host-Route zum VPN-Server über das D-GW, danach wird die Default-Route gelöscht und eine über das VPN eingetragen.
Im Log sieht man, dass das Eintragen der Host-Route nicht geklappt hat (dafür aber das Löschen der Default-Route mit dem Effekt, dass die Gegenseite nicht mehr gefunden wurde....)
Solange das Anlegen dieser Route nicht funktioniert, geht redirect-gateway nicht. Da müsstest du vielleicht mal bei irgendwelchen "Mobile-Foren" versuchen was drüber rauszubekommen...

Ich mach jetzt Schluss für heute (oder für gestern )

Jörg

[blacksun]

Wo das redirect steht ist egal. Zur Erläuterung: redirect-gateway geht in die Routingtabelle, holt sich das Default-GW und setzt eine Host-Route zum VPN-Server über das D-GW, danach wird die Default-Route gelöscht und eine über das VPN eingetragen.
Im Log sieht man, dass das Eintragen der Host-Route nicht geklappt hat (dafür aber das Löschen der Default-Route mit dem Effekt, dass die Gegenseite nicht mehr gefunden wurde....)

und

Das hängt von den Routen ab. Man sah nur im Log, dass es mit dem Löschen und Anlegen von Routen ein Problem gab. scheinbar auch mit dem "redirect-gateway" was ja genau das tut. Da musst du wohl noch etwas dran arbeiten, denn ohne den Befehl wird vermutlich beides möglich sein:
Du hast das default-Gateway vom Provider und dann noch eines, was die Fritzbox im DHCP geschickt hat... Ohne eine Konsole und die üblichen Windows-Befehle wird es schwer sein, das zu "debuggen".

Hallo Jörg,

ich hab mich mal wieder mit dem Thema VPN über mein WindowsMobile-Smartphone beschäftigt. Inzwischen habe ich auch eine Kommandozeile auf dem Gerät, die zumindest die Befehle route, ping und ipconfig kennt.

Ich hab hier einmal die Routen mit und dann auch ohne einem "redirect-gateway" im Konfig-file:

Mit Redirect:

=============================================================================
 Interface List 
 2 	  0 9 2d ce 51 92	 TIACXWLN1
 3 	  0 ff dd 6f 40 eb	 TAP Device 1
 196612 	  0 0 0 0 0 0	 
=============================================================================

=============================================================================
 Active Routes 
  
 The no. of entries is ::: 13
      Destination       Netmask       GatewayAddress     Interface    Metric  
 ----------------------------------------------------------------------------
          0.0.0.0          0.0.0.0    192.168.3.101     192.168.3.44      30
         10.0.0.0        255.0.0.0    10.43.184.150    10.43.184.150      50
    10.43.184.150  255.255.255.255        127.0.0.1        127.0.0.1      50
   10.255.255.255  255.255.255.255    10.43.184.150    10.43.184.150      50
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1
      192.168.3.0    255.255.255.0     192.168.3.44     192.168.3.44      30
     192.168.3.44  255.255.255.255        127.0.0.1        127.0.0.1      30
    192.168.3.255  255.255.255.255     192.168.3.44     192.168.3.44      30
        224.0.0.0        240.0.0.0     192.168.3.44     192.168.3.44      30
        224.0.0.0        240.0.0.0    10.43.184.150    10.43.184.150      50
  255.255.255.255  255.255.255.255    10.43.184.150          0.0.0.0       1
  255.255.255.255  255.255.255.255     192.168.3.44     192.168.3.44       1
  255.255.255.255  255.255.255.255    10.43.184.150    10.43.184.150       1
=============================================================================

ohne:

=============================================================================
 Interface List 
 2 	  0 9 2d ce 51 92	 TIACXWLN1
 3 	  0 ff 31 59 2b 10	 TAP Device 1
 4 	  0 0 0 0 0 0	 
=============================================================================

=============================================================================
 Active Routes 
  
 The no. of entries is ::: 14
      Destination       Netmask       GatewayAddress     Interface    Metric  
 ----------------------------------------------------------------------------
          0.0.0.0          0.0.0.0    192.168.3.101     192.168.3.45      30
          0.0.0.0          0.0.0.0    10.73.189.185    10.73.189.185      50
         10.0.0.0        255.0.0.0    10.73.189.185    10.73.189.185      50
    10.73.189.185  255.255.255.255        127.0.0.1        127.0.0.1      50
   10.255.255.255  255.255.255.255    10.73.189.185    10.73.189.185      50
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1
      192.168.3.0    255.255.255.0     192.168.3.45     192.168.3.45      30
     192.168.3.45  255.255.255.255        127.0.0.1        127.0.0.1      30
    192.168.3.255  255.255.255.255     192.168.3.45     192.168.3.45      30
        224.0.0.0        240.0.0.0     192.168.3.45     192.168.3.45      30
        224.0.0.0        240.0.0.0    10.73.189.185    10.73.189.185      50
  255.255.255.255  255.255.255.255     192.168.3.45          0.0.0.0       1
  255.255.255.255  255.255.255.255     192.168.3.45     192.168.3.45       1
  255.255.255.255  255.255.255.255    10.73.189.185    10.73.189.185       1
=============================================================================

Mit "redirect" komm ich zu keiner ip bei mir im LAN und damit auch nicht weiter in's Inet.
Eigentlich sieht alles so aus, wie es sein müsste.

Wenn ich bei redirect mit ipconfig schaue, dann hat die Provider-Verbindung kein Gateway mehr.

Kannst Du aus den Routing-Tabellen was rauslesen, wo der Fehler liegt?
Wie könnte ich das "redirect" manuell bauen. Das heißt ich baue eine funktionierende Verbindung ohne redirect auf und setze z.B. die Routen dann manuell.

Den Befehl arp kann die Konsole leider nicht.

[MaxMuster]

.. Zumindest sieht man, was fehlt: Eine Route zur IP deines "VPN-Servers".

Du könntest das mal versuchen nachzustellen:
- Per ping auf den dyndns-Namen die IP deiner Box herausfinden nehmen wir mal an "1.2.3.4"
- Die Routingtabelle oder ipconfig für das "Defaultgateway" auslesen, z.B. "10.73.189.185"
- Eine Hostroute für die VPN-ServerBox anlegen: route add 1.2.3.4 10.73.189.185
- Wenn das fehlschlägt, "rumprobieren" bis diese Route eingetragen ist. Im "route print" müsste dann z.B. stehen:

 0.0.0.0          0.0.0.0            10.73.189.185    10.73.189.185      50
[...]
 1.2.3.4          255.255.255.255    10.73.189.185    10.73.189.185      50

danach nochmal "mit redirect" starten solte dann gehen.

Jörg