OpenVpn - Dienst schlatet sich aus

[stoner123]

Hallo!

Hab versucht mir ein VPN einzurichten... Leider funkt es nicht ganz so, wie ich es mir gedacht hab...

Config der Box siehe Anhang..


Der Client hat folgene CONFIG:

client
dev tap
#udp/tcp je nachdem, was ausgewählt wurde
proto udp
#Port entsprechend der Konfiguration
remote xx.xx.xx.xx 1194
nobind
persist-key
persist-tun
#hier die Zertifikate/Schlüssel, wie beim Erstellen benannt
ca "C:\\Program Files (x86)\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files (x86)\\OpenVPN\\config\\client01.crt"
key "C:\\Program Files (x86)\\OpenVPN\\config\\client01.key"
# für TLS-Remote "ServerBox1" wie beim Erstellen benannt
tls-remote fritzbox
tls-auth "C:\\Program Files (x86)\\OpenVPN\\config\\static.key" 1
auth SHA1
cipher AES-256-CBC
comp-lzo
verb 3

Port wurde ebenfalls weitergeleitet.

OpenVpn sagt:

Wed Nov 04 21:10:36 2009 Control Channel Authentication: using 'C:\Program Files
 (x86)\OpenVPN\config\static.key' as a OpenVPN static key file
Wed Nov 04 21:10:36 2009 Outgoing Control Channel Authentication: Using 160 bit
message hash 'SHA1' for HMAC authentication
Wed Nov 04 21:10:36 2009 Incoming Control Channel Authentication: Using 160 bit
message hash 'SHA1' for HMAC authentication
Wed Nov 04 21:10:36 2009 LZO compression initialized
Wed Nov 04 21:10:36 2009 Control Channel MTU parms [ L:1590 D:166 EF:66 EB:0 ET:
0 EL:0 ]
Wed Nov 04 21:10:36 2009 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:
32 EL:0 AF:3/1 ]
Wed Nov 04 21:10:36 2009 Local Options hash (VER=V4): '48527533'
Wed Nov 04 21:10:36 2009 Expected Remote Options hash (VER=V4): '44bd8b5e'
Wed Nov 04 21:10:36 2009 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Nov 04 21:10:36 2009 UDPv4 link local: [undef]
Wed Nov 04 21:10:36 2009 UDPv4 link remote: xx.xx.xx.xx:1194
Wed Nov 04 21:10:36 2009 TLS: Initial packet from xx.xx.xx.xx:1194, sid=04b80a8
1 e62caac6
Wed Nov 04 21:10:36 2009 VERIFY OK: depth=1, /C=AT/ST=Vienna/L=ViennaVI/O=home/C
N=ca/[email protected]
Wed Nov 04 21:10:36 2009 VERIFY X509NAME OK: /C=AT/ST=Vienna/O=home/CN=fritzbox/
[email protected]
Wed Nov 04 21:10:37 2009 VERIFY OK: depth=0, /C=AT/ST=Vienna/O=home/CN=fritzbox/
[email protected]

Und dann schau ich im freetz nach und sehe, dass der dienst (OpenVPN) beendet ist.

Hoffe ich hab alle Infos gebracht, die gebraucht werden?

Danke schon mal...

 

[colonia27]

Config der Box siehe Anhang..

ich sehe hier keinen Anhang.

Der Client hat folgene CONFIG:

client
dev tap
#udp/tcp je nachdem, was ausgewählt wurde
proto udp
#Port entsprechend der Konfiguration
remote xx.xx.xx.xx 1194
nobind
persist-key
persist-tun
#hier die Zertifikate/Schlüssel, wie beim Erstellen benannt
ca "C:\\Progra[COLOR=Red]m F[/COLOR]ile[COLOR=Red]s ([/COLOR]x86)\\OpenVPN\\config\\ca.crt"
cert "C:\\Progra[COLOR=Red]m F[/COLOR]ile[COLOR=Red]s ([/COLOR]x86)\\OpenVPN\\config\\client01.crt"
key "C:\\Progra[COLOR=Red]m F[/COLOR]ile[COLOR=Red]s ([/COLOR]x86)\\OpenVPN\\config\\client01.key"
# für TLS-Remote "ServerBox1" wie beim Erstellen benannt
tls-remote fritzbox
tls-auth "C:\\Progra[COLOR=Red]m F[/COLOR]ile[COLOR=Red]s ([/COLOR]x86)\\OpenVPN\\config\\static.key" 1
auth SHA1
cipher AES-256-CBC
comp-lzo
verb 3

ob das mit den Leerzeichen in den Pfaden so richtig ist ?!?

OpenVpn sagt:

Wed Nov 04 21:10:36 2009 Control Channel Authentication: using 'C:\Program Files
 (x86)\OpenVPN\config\static.key' as a OpenVPN static key file
Wed Nov 04 21:10:36 2009 Outgoing Control Channel Authentication: Using 160 bit
message hash 'SHA1' for HMAC authentication
Wed Nov 04 21:10:36 2009 Incoming Control Channel Authentication: Using 160 bit
message hash 'SHA1' for HMAC authentication
Wed Nov 04 21:10:36 2009 LZO compression initialized
Wed Nov 04 21:10:36 2009 Control Channel MTU parms [ L:1590 D:166 EF:66 EB:0 ET:
0 EL:0 ]
Wed Nov 04 21:10:36 2009 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:
32 EL:0 AF:3/1 ]
Wed Nov 04 21:10:36 2009 Local Options hash (VER=V4): '48527533'
Wed Nov 04 21:10:36 2009 Expected Remote Options hash (VER=V4): '44bd8b5e'
Wed Nov 04 21:10:36 2009 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Nov 04 21:10:36 2009 UDPv4 link local: [undef]
Wed Nov 04 21:10:36 2009 UDPv4 link remote: xx.xx.xx.xx:1194
Wed Nov 04 21:10:36 2009 TLS: Initial packet from xx.xx.xx.xx:1194, sid=04b80a8
1 e62caac6
Wed Nov 04 21:10:36 2009 VERIFY OK: depth=1, /C=AT/ST=Vienna/L=ViennaVI/O=home/C
N=ca/[email protected]
Wed Nov 04 21:10:36 2009 VERIFY X509NAME OK: /C=AT/ST=Vienna/O=home/CN=fritzbox/
[email protected]
Wed Nov 04 21:10:37 2009 VERIFY OK: depth=0, /C=AT/ST=Vienna/O=home/CN=fritzbox/
[email protected]

ist das alles was er beim Starten ausspuckt?
Wenn er vernünftig startet sollte am Ende etwas wie "Initialization sequence completed" oder so ähnlich stehen

 

[stoner123]

ja das ist alles was der vpn client ausspuckt... und wenn das dann ebne so da steht und ich schau nach ob der VPN Dienst noch läuft un der Box, muss ich festellen, dass der dienst abgestürzt ist, zumind. läuft er nicht mehr...

ja das mit den leerzeichen sollte funken, da ich es schon geschafft habe per static key und TUN zu verbinden (Key-Angabe ebenfalls mit Leerzeichen - AJA: ist ein Win System). Jedoch war ich da nur im LAN. Wollte aber den kompletten Traffik drüber haben...

Ps.: Hab den Anhang im ersten Post hinzugefügt...

 

[waldoo]

versuche es doch mal mit "tls-client" statt "tls-remote fritzbox"

stell den verbose mal bitte höher und schau dann ob du mehr output bekommst.

 

[MaxMuster]

Noch einige Bemerkungen dazu:
- Wenn du als Brückennetz 192.168.178.0/24 nimmst (siehe lokale IP) dann ist eine Route dahin überflüssig.
- Eigentlich fehlen einige Einstellungen beim Client (aber ich glaube "pull" macht der manchmal automatisch?)
- Sollt der Client nicht auch eine IP bekommen ;-) ?!?
Dein OpenVPN tut das nicht und hier (mit TAP) würde das nur gehen, wenn du dein TAP mit den LAN brückst, dann würde der DHCP der Box die Vergabe machen, wenn der Client einen Request schickt (z.B. Stamdard bei Windows)...
Bei identischen IPs (in LAN und VPN) ist das sogar zwingend, die beiden zu brücken, sonst zerscheißt du dir das Routing für das Netz

- Und zum Schluss: Wenn du im LAN testest, ist das keine gute Idee mit der Client-Konfig, sofern 192.168.178. dein Netz ist, weil dann (wie oben) LAN und VPN um die IPs "konkurieren" und zudem noch dein VPN versuchen könnte, die Gegenstelle, di ja im gleichen Netz ist, durch das VPN zu erreichen.

Jörg