[Erstmal gelöst]OpenVPN in der Box macht kummer....

Toggle sidebar Toggle sidebar
Upgrade 3CX to v18 and get it hosted free!
N

newland

Neuer User
Mitglied seit
13 Jan 2008
Beiträge
115
Punkte für Reaktionen
0
Punkte
0
So nun weis ich nicht ob ich ein neues Thema aufmachen soll oder… Dann denke ich mal schon.

Mit meine Box konnte ich Verbindung mit OpenVPN mit Static_Key auf aufbauen d.h. die Box als Client und als Server.

Nun Versuche ich es mal nach Anleitung hier und einer PDF-Doc. Früher habe ich mal eine OpenVPN Verbindung mit Zertifikaten (Verwaltung)aufgebaut auf ein Windows NT 4.0 Server aber das ist schon ein bissen her.
Jetzt habe ich hier diese Zenario.
Ich will eine Tun Verbindung zu meiner Fritzbox aufbauen per OpenVPN versteht sich, das mit fünf Clients die unterschiedlich auf die Box zugreifen können (sollen).
Dazu habe ich für jeden Client 5 passende Zertifikate und eins für die Box erstellt wo ja der Server OpenVPN läuft.
Zu denen habe ich dann die entsprechenden Clients Config erstellt.
Eine z.B. Sieht so aus.:
Code: 
port 1194 #PORT ANPASSEN
remote fritz.box #SERVER ANPASSEN (URL oder IP)
proto udp
dev tun
tls-client
ns-cert-type server
comp-lzo
ca C:\\Server\\OpenVPN\\keys\\ca.crt
cert C:\\Server\\OpenVPN\\keys\\winserver2003.crt
key C:\\Server\\OpenVPN\\keys\\winserver2003.key
tls-auth "C:\\Server\\OpenVPN\\keys\\static.key" 1
tun-mtu 1500
tun-mtu-extra 32
mssfix
nobind
pull #Client verliert ohne das Pull bei Inaktivität die Verbindung
verb 3
mute 50
persist-key
persist-tun

Auf der Box (Server) sieht das ganze so aus.

Code: 
 # OpenVPN 2.1 Config
proto udp
port 1194
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
mode server
tls-server
dh /tmp/flash/dh.pem
crl-verify /tmp/flash/crl.pem
tls-auth /tmp/flash/static.key 0
ifconfig-pool 192.168.200.100 192.168.200.150
ifconfig 192.168.200.1 192.168.200.2 
route 192.168.200.0 255.255.255.0
push "route 192.168.200.0 255.255.255.0"
push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 192.168.0.1"
push "redirect-gateway"
max-clients 5
tun-mtu 1500
mssfix

daemon
verb 3

cipher BF-CBC
comp-lzo
float
keepalive 10 120
status /var/log/openvpn.log

So nun wenn ich eine Verbindung aufbaue bricht die Verbindung ab besser gesagt OpenVPN auf meine Box Stopp den Dienst.
Wenn ich dann in Client-Logfile schaue sieht die Meldung so aus:
Code: 
Sat Jan 19 01:47:01 2008 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2006
Sat Jan 19 01:47:01 2008 Control Channel Authentication: using 'C:\Server\OpenVPN\keys\static.key' as a OpenVPN static key file
Sat Jan 19 01:47:01 2008 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 19 01:47:01 2008 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 19 01:47:01 2008 LZO compression initialized
Sat Jan 19 01:47:01 2008 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sat Jan 19 01:47:02 2008 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Sat Jan 19 01:47:02 2008 Local Options hash (VER=V4): 'ec497616'
Sat Jan 19 01:47:02 2008 Expected Remote Options hash (VER=V4): '7cd8ed90'
Sat Jan 19 01:47:02 2008 UDPv4 link local: [undef]
Sat Jan 19 01:47:02 2008 UDPv4 link remote: 192.168.0.1:1194
Sat Jan 19 01:47:02 2008 TLS: Initial packet from 192.168.0.1:1194, sid=63e3f9ea 4c764a5e
Sat Jan 19 01:47:02 2008 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1200703471) Sat Jan 19 01:44:31 2008 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat Jan 19 01:47:02 2008 TLS Error: incoming packet authentication failed from 192.168.0.1:1194
Sat Jan 19 01:47:04 2008 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2 / time = (1200703471) Sat Jan 19 01:44:31 2008 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat Jan 19 01:47:04 2008 TLS Error: incoming packet authentication failed from 192.168.0.1:1194
Sat Jan 19 01:47:04 2008 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #3 / time = (1200703471) Sat Jan 19 01:44:31 2008 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat Jan 19 01:47:04 2008 TLS Error: incoming packet authentication failed from 192.168.0.1:1194
Sat Jan 19 01:47:04 2008 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #4 / time = (1200703471) Sat Jan 19 01:44:31 2008 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat Jan 19 01:47:04 2008 TLS Error: incoming packet authentication failed from 192.168.0.1:1194
Sat Jan 19 01:47:04 2008 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #5 / time = (1200703471) Sat Jan 19 01:44:31 2008 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Die Log der Box sieht so aus:

Code: 
nel: mcfw_query_sent: cpmac:0,1,2,3:0.0.0.0 1000
Jan 19 01:39:52 fritz daemon.err openvpn[511]: 192.168.0.5:3317 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jan 19 01:39:52 fritz daemon.err openvpn[511]: 192.168.0.5:3317 TLS Error: TLS handshake failed
Jan 19 01:39:52 fritz daemon.notice openvpn[511]: 192.168.0.5:3317 SIGUSR1[soft,tls-error] received, client-instance restarting
Jan 19 01:39:54 fritz daemon.notice openvpn[511]: MULTI: multi_create_instance called
Jan 19 01:39:54 fritz daemon.notice openvpn[511]: 192.168.0.5:3350 Re-using SSL/TLS context
Jan 19 01:39:54 fritz daemon.notice openvpn[511]: 192.168.0.5:3350 LZO compression initialized
Jan 19 01:39:54 fritz daemon.notice openvpn[511]: 192.168.0.5:3350 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Jan 19 01:39:54 fritz daemon.notice openvpn[511]: 192.168.0.5:3350 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Jan 19 01:39:54 fritz daemon.notice openvpn[511]: 192.168.0.5:3350 TLS: Initial packet from 192.168.0.5:3350, sid=a996fa10 6084a021
Jan 19 01:40:54 fritz daemon.err openvpn[511]: 192.168.0.5:3350 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jan 19 01:40:54 fritz daemon.err openvpn[511]: 192.168.0.5:3350 TLS Error: TLS handshake failed
Jan 19 01:40:54 fritz daemon.notice openvpn[511]: 192.168.0.5:3350 SIGUSR1[soft,tls-error] received, client-instance restarting
Jan 19 01:40:56 fritz daemon.notice openvpn[511]: MULTI: multi_create_instance called
Jan 19 01:40:56 fritz daemon.notice openvpn[511]: 192.168.0.5:3378 Re-using SSL/TLS context
Jan 19 01:40:56 fritz daemon.notice openvpn[511]: 192.168.0.5:3378 LZO compression initialized
Jan 19 01:40:56 fritz daemon.notice openvpn[511]: 192.168.0.5:3378 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Jan 19 01:40:56 fritz daemon.notice openvpn[511]: 192.168.0.5:3378 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Jan 19 01:40:56 fritz daemon.notice openvpn[511]: 192.168.0.5:3378 TLS: Initial packet from 192.168.0.5:3378, sid=a0598e12 6db0cbd1
Jan 19 01:41:06 fritz daemon.err openvpn[511]: read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
…
….

Den Static-Key für die tls-auth habe ich vorher aus der Box entnommen und im Verzeichnis im Client gepackt.

Dann habe ich mal tls-auth abgestellt und im Client ein # gesetzt und das ganze noch mal versucht.

Dann kommt diese Meldung im Client-Logfile

Code: 
Sat Jan 19 02:20:57 2008 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2006
Sat Jan 19 02:20:57 2008 LZO compression initialized
Sat Jan 19 02:20:57 2008 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sat Jan 19 02:20:57 2008 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Sat Jan 19 02:20:57 2008 Local Options hash (VER=V4): 'd3a7571a'
Sat Jan 19 02:20:57 2008 Expected Remote Options hash (VER=V4): '5b1533a2'
Sat Jan 19 02:20:57 2008 UDPv4 link local: [undef]
Sat Jan 19 02:20:57 2008 UDPv4 link remote: 192.168.0.1:1194
Sat Jan 19 02:20:57 2008 TLS: Initial packet from 192.168.0.1:1194, sid=d2886e4f 174c21ba
Sat Jan 19 02:20:59 2008 VERIFY OK: depth=1, /C=DE/ST=CA/L=Home/O=RCB/OU=RCB/CN=fritzbox/[email protected]
Sat Jan 19 02:20:59 2008 VERIFY OK: nsCertType=SERVER
Sat Jan 19 02:20:59 2008 VERIFY OK: depth=0, /C=DE/ST=CA/O=RCB/OU=RCB/CN=fritzbox/[email protected]
Sat Jan 19 02:21:01 2008 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Sat Jan 19 02:21:01 2008 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)

Sat Jan 19 02:21:05 2008 TCP/UDP: Closing socket

Log der Box:

Code: 
Jan 19 02:17:45 fritz daemon.notice openvpn[1513]: OpenVPN 2.1_rc4 mipsel-linux [SSL] [LZO2] [EPOLL] built on Jan 14 2008
Jan 19 02:17:47 fritz daemon.notice openvpn[1513]: Diffie-Hellman initialized with 2048 bit key
Jan 19 02:17:47 fritz daemon.warn openvpn[1513]: WARNING: file '/tmp/flash/box.key' is group or others accessible
Jan 19 02:17:47 fritz daemon.notice openvpn[1513]: TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Jan 19 02:17:47 fritz daemon.notice openvpn[1513]: TUN/TAP device tun0 opened
Jan 19 02:17:47 fritz daemon.notice openvpn[1513]: TUN/TAP TX queue length set to 100
Jan 19 02:17:47 fritz daemon.notice openvpn[1513]: /sbin/ifconfig tun0 192.168.200.1 pointopoint 192.168.200.2 mtu 1500
Jan 19 02:17:47 fritz daemon.notice openvpn[1513]: /sbin/route add -net 192.168.200.0 netmask 255.255.255.0 gw 192.168.200.2
Jan 19 02:17:47 fritz daemon.notice openvpn[1513]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Jan 19 02:17:47 fritz daemon.notice openvpn[1520]: Socket Buffers: R=[109568->131072] S=[109568->131072]
Jan 19 02:17:47 fritz daemon.notice openvpn[1520]: UDPv4 link local (bound): [undef]:1194
Jan 19 02:17:47 fritz daemon.notice openvpn[1520]: UDPv4 link remote: [undef]
Jan 19 02:17:47 fritz daemon.notice openvpn[1520]: MULTI: multi_init called, r=256 v=256
Jan 19 02:17:47 fritz daemon.notice openvpn[1520]: IFCONFIG POOL: base=192.168.200.100 size=13
Jan 19 02:17:47 fritz daemon.notice openvpn[1520]: Initialization Sequence Completed
Jan 19 02:18:26 fritz daemon.notice openvpn[1520]: MULTI: multi_create_instance called
Jan 19 02:18:26 fritz daemon.notice openvpn[1520]: 192.168.0.5:3865 Re-using SSL/TLS context
Jan 19 02:18:26 fritz daemon.notice openvpn[1520]: 192.168.0.5:3865 LZO compression initialized
Jan 19 02:18:26 fritz daemon.notice openvpn[1520]: 192.168.0.5:3865 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Jan 19 02:18:26 fritz daemon.notice openvpn[1520]: 192.168.0.5:3865 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Jan 19 02:18:26 fritz daemon.notice openvpn[1520]: 192.168.0.5:3865 TLS: Initial packet from 192.168.0.5:3865, sid=3bdc7e8f e8a2bd95
Jan 19 02:18:29 fritz daemon.err openvpn[1520]: 192.168.0.5:3865 CRL: cannot read CRL from file /tmp/flash/crl.pem

So jetzt weis ich auch nicht mehr weiter. Firewall ist für den Port offen 1194 und am Client 1 ebenfalls offen (Portweiterleitung)
Was mich wunder das auch hier OpenVPN gestoppt wird von der Box?

Dann das mit
cannnot read file /tmp/flash/crl.pem
Zum Vergrößern anklicken....
wundert mich ob wohl da doch nichts drin stehen muss nur doch für zurück gezogene Zertifikate?

Darum benötige ich die Hilfe von Euch Profis die mit OpenVPN mehr sich auskennen.

PS: Ich hoffe der Text ist nicht zu lang geworden. ;)
 
Zuletzt bearbeitet:
Zunächst scheint dein "erstes" Probelm tatsächlich mit dem tls-auth (dem Key?) zusammen gehangen zu haben, denn ohne das geht es ja viel weiter.

Ich denke in der Tat ist die "canot read Zeile" dein Problem, denn die Box möchte sehen, ob das Client-Zertifikat zurückgezogen wurde und kann das nicht tun.

Eigentlich sollte der Eintrag mit "crl-verify /tmp/flash/crl.pem" nur drin sein, wenn die Datei angelegt wurde. Wenn du keine zurückgezogenen Zertifikate hast, lösche die Datei einfach und führe danach nochmal ein "modsave" aus.


Jörg
 
So nun habe ich konnte ich eine Verbindungaufbauen nach dem ich die /tmp/flash/crl.pem in tmp gelöscht habe und habe eine neue tls-auth-key erstellt.
Verbindung zur Box konnte aufgebaut werden. (Schon mal gut)
Aber wieso wenn ich im Log des Windows Client diese Meldung noch finde macht mich stutzig?

Code: 
----
----
Sat Jan 19 22:38:46 2008 TLS Error: incoming packet authentication failed from 192.168.0.1:1194
Sat Jan 19 22:38:46 2008 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #65 / time = (1200778570) Sat Jan 19 22:36:10 2008 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
----
----

Sat Jan 19 22:44:32 2008 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #37 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
----
----

Ich denke meine Netzconfig müsset ja in Ordnung sein?! Das tls-auth-key bezieht sich sicher auf die Verbindung?
 
Wenn es prinzipiell klappt und das nur ab und an mal kommt ist das bei UDP und/oder WLAN-Beteiligung schon o.k. (wenn also mal ein Paket verloren gehen oder wiederholt werden kann).

Jörg
 
ja klapp es bis jetzt schon nur ich habe die Verbindung per Lan eth0 aufgebaut. Wenn ich in der Client conf ein # setzte kommt die meldung mit :

Code: 
Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #37 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Ich hoffe ja jetzt nicht das ich die Hälfte alle Gesendeten/Empfangen Pakete verliere.

Ich muss noch mal schauen wie es von Ausserhalb läuft (Netzwerk/Route).
 
Zuletzt bearbeitet:
So nun kann ich auch von Aussen per openvpn auf ein meiner Boxen ;)

Da
Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #37 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Zum Vergrößern anklicken....
soweit auch nicht mehr vor und wenn ist es ja nicht so Gravierend.

Aber was ich der Logfile Client festelle es kommt immer wieder zu
Code: 
Sun Jan 20 07:27:01 2008 NOTE: FlushIpNetTable failed on interface [65540] {4A7192B9-720C-4A02-91D7-4BEEC67BE97E} (status=259) : Es sind keine Daten mehr verfügbar.  
Sun Jan 20 07:27:01 2008 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Jan 20 07:27:01 2008 Route: Waiting for TUN/TAP interface to come up...
Sun Jan 20 07:27:02 2008 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Wenn man eine Verbindung aufbaut.
1 zu
[FlushIpNetTable failed on interface [65540] {4A7192B9-720C-4A02-91D7-4BEEC67BE97E} (status=259) : Es sind keine Daten mehr verfügbar.
Zum Vergrößern anklicken....
Bekommt er keiner Daten mehr von Server darum der 'Test Routes'.

Was ca. 1- 2 min mit Test Routes durchzieht bis eine Verbind steht mit den Server. Habe ich in meine Conf zuviele gesetzt?


Dann noch eben kurz das
Route addition via IPAPI failed
Zum Vergrößern anklicken....

Habe ich da eine falsche Route definition gesetzt in mein Netzwerk?
Auf jeden fall vergibt der DCHP die erste IP ab 192.168.xx.106 statt wie es in der Server-Conf eingetragen ist beispiel 192.168xx.100. Aber kann sein das ich vorher schon Verbindung von anderen Clients aufgebaut hatte.

PS. Ich hoffe keine ist Böse mit meiner doppel Post (Sorry)

Udate 21.1.2008 Uhr 23:52

So jetzt habe ich mal in die Client-Opnevpn.Conf

Code: 
 ip-win32 netsh
aber leider bringt mir das nur eine Fehlermeldung :
Mon Jan 21 23:57:09 2008 NOTE: FlushIpNetTable failed on interface [65540] {4A7192B9-720C-4A02-91D7-4BEEC67BE97E} (status=259) : Es sind keine Daten mehr verfügbar.
Mon Jan 21 23:57:09 2008 NOTE: You have selected (explicitly or by default) '--ip-win32 ipapi', which has a better chance of working correctly if the TAP-Win32 TCP/IP proper
Zum Vergrößern anklicken....

Sollte ich eine route in meiner Clinet-openvpn.conf schreiben?

Ich dache so an
Code: 
 route 192.168.0.0 255.255.255.0 192.168.0.1
oder?
 
Zuletzt bearbeitet:
Moin,

das es etwas dauert, bis der Adapter "initialisiert ist", ist ganz normal ("TEST ROUTES ... Waiting for TUN/TAP..."), die "falsche IP" hast du ja schon selbst erklärt.

Wie sieht denn die Routingtabelle aus? Vorher/nachher (also mit und ohne VPN-Verbindung)? Die Route sollte eigentlich unnötig sein, da du die per "push/pull" von Server ziehst. Wenn, muss sie auf die "VPN-IP" des Servers zeigen, also die 192.168.200.1 (bzw die entsprechende IP auf der Server-Seite des TUNs).

Das ist jetzt eher "Fritzbox-unspezifisch", da müsstest du eventuell auch nochmal bei Google und Co anfragen, wenn du "tiefere" Erklärungen benötigst und wir hier eventuell nicht weiter kommen ;-)

Jörg
 
Zuletzt bearbeitet:
Hallo

ok dann Fasse ich kurz zusammen:
1
Code: 
 route 192.168.0.0 255.255.255.0 192.168.0.1
weglassen in der Clend-Conf da der Client sich die route duchr push/pull von Server sieht oder es müsste die IP des VPN- Server drinstehen.

2
Setzte bring so mit
Code: 
ip-win32 netsh oder mit ip-win32 ipapi

bring dann mit Route bzw. für eine schellere einbindung in Netz nicht's
Also sollte man nicht dann mit
Code: 
TEST ROUTES ... Waiting for TUN/TAP.
rechnenn.

Wenn ich mal ip-win32 ipapi setzt in der Cliend-Config bekomme ich in OpenVPN-GUI keine IP für den Client angezeigt. Wenn ich ip-win32 ipapi weglasse schon.
Aber die Roue Tabelle sieht dann anders aus : Siehe unten
Meine Route sieht in Client so aus:Ohne VPN

Code: 
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0      192.168.0.1     192.168.0.4       30
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.0.0    255.255.255.0      192.168.0.4     192.168.0.4       30
      192.168.0.4  255.255.255.255        127.0.0.1       127.0.0.1       30
    192.168.0.255  255.255.255.255      192.168.0.4     192.168.0.4       30
        224.0.0.0        240.0.0.0      192.168.0.4     192.168.0.4       30
  255.255.255.255  255.255.255.255      192.168.0.4           40002       1
  255.255.255.255  255.255.255.255      192.168.0.4           40006       1
  255.255.255.255  255.255.255.255      192.168.0.4     192.168.0.4       1
Standardgateway:       192.168.0.1
===========================================================================

mit VPN mit ip-win32 ipapi gestzt und route 192.168.0.0. 255.255.255.0 192.168.0.1 rausgenommen aus der Client-Config-VPN

Code: 
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0      192.168.0.1     192.168.0.4       30
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.0.0    255.255.255.0      192.168.0.4     192.168.0.4       30
      192.168.0.0    255.255.255.0  192.168.200.105           40002       1
      192.168.0.4  255.255.255.255        127.0.0.1       127.0.0.1       30
    192.168.0.255  255.255.255.255      192.168.0.4     192.168.0.4       30
    192.168.200.0    255.255.255.0  192.168.200.105           40002       1
  192.168.200.104  255.255.255.252  192.168.200.106           40002       30
  192.168.200.106  255.255.255.255        127.0.0.1       127.0.0.1       30
  192.168.200.255  255.255.255.255  192.168.200.106           40002       30
        224.0.0.0        240.0.0.0      192.168.0.4     192.168.0.4       30
        224.0.0.0        240.0.0.0  192.168.200.106           40002       30
  255.255.255.255  255.255.255.255      192.168.0.4     192.168.0.4       1
  255.255.255.255  255.255.255.255  192.168.200.106           40006       1
  255.255.255.255  255.255.255.255  192.168.200.106           40002       1
Standardgateway:       192.168.0.1

Ich will eigendlich wie in Wikki beschrieben satt mit Realer- IP-Bereich 192.168.178.0 habe ich die 192.168.0.0 .
Oder wäre tap der bessere weg?
 
1. Ja.
2. Diese Frage/Aussage habe ich nicht verstanden :confused:

Was mir noch nicht ganz klar ist, sind deine Netze und dein "Zielszenario":

Du bist mit dem Client schon im Netzt 192.168.0.0 und baust dann eine Verbindung in das gleiche Netz auf? Oder ist das jetzt nur dein Test? Eine Route für ein angeschlossenes Netz durch das VPN ist natürlich nicht unbedingt sinnvoll bis hin zu "tödlich" für deine Kennektivität (du baust damit eine Routingschleife, weil Pakete für das LAN und auch solche, die das VPN "herstellen" durch das VPN geroutet werden sollen) ...

Jörg
 
Was ich mit ip-win32 ipapi meine ist das man damit eine Verbindung aufbauen kann und die Meldung
Route addition via IPAPI failed
Zum Vergrößern anklicken....
nicht mehr auftritt.

Nur kann ich mir diese Meldung
CreateFile failed on TAP device:
Zum Vergrößern anklicken....
immer noch nicht erklären? Was dabei
FlushIpNetTable failed on interface
Zum Vergrößern anklicken....
Resultiert.

MaxMuster schrieb:
Du bist mit dem Client schon im Netzt 192.168.0.0 und baust dann eine Verbindung in das gleiche Netz auf? Oder ist das jetzt nur dein Test?
Zum Vergrößern anklicken....

Ja bin ich, hast recht und will eigendlich auch keine doppel Schleife einbauen.
Aber ich will eine OPNVPN _Verbindung testen und dann muss ich ja den Server/Box im LAN mit seiner IP ansprechen können um zu sehen das sich ein VPN Network aufbaut in 192.168.200.0 Bereich. Sollte ich dann etwa eine Verbindung wenn ich im selben LAN bin die BOX/Server mit der VPN IP eine Verbindung aufbauen? Hier wäre es die 192.168.200.1 die der OPENVPN-Server hat!? Leider hab ich noch keine möglichkeit das von ausserhalb zu testen. Bei nutzung von WLAN-Netzt die nicht Verschlüsselt ist zb. ist es doch auch möglich (OPEN)VPN als Verschlüsselung einzusetzten als Alternative zu WPA1/2.
 
Hi,

Code: 
CreateFile failed on TAP device:
Kommt normalerweise, wenn das Betriebssystem das virtuelle Interface "nicht findet" oder nicht aktivieren kann, weil es deaktiviert ist, eine falsche "dev-node" Zeile in der Config ist usw.

Zur "internen Verbindung": Ist ja alles kein Problem, nur darfst du dann eben nur mit den "VPN-IPs" (192.168.200.x) testen un darfst dann keine Routen für dein internes Netz (192.168.0.0) eintragen oder per pull holen...

Jörg
 
Hallo,

habe jetzt route mal rausgenommen für die Test im Internen Netz.

Die Verbingung Log des Client sieht jetzt so aus:

Code: 
Sat Jan 26 22:45:49 2008 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2006
Sat Jan 26 22:45:52 2008 Control Channel Authentication: using 'D:\Internet\OpenVPN\config\static.key' as a OpenVPN static key file
Sat Jan 26 22:45:52 2008 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 26 22:45:52 2008 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 26 22:45:52 2008 LZO compression initialized
Sat Jan 26 22:45:52 2008 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sat Jan 26 22:45:52 2008 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Sat Jan 26 22:45:52 2008 Local Options hash (VER=V4): 'ec497616'
Sat Jan 26 22:45:52 2008 Expected Remote Options hash (VER=V4): '7cd8ed90'
Sat Jan 26 22:45:52 2008 UDPv4 link local: [undef]
Sat Jan 26 22:45:52 2008 UDPv4 link remote: 192.168.0.1:1194
Sat Jan 26 22:45:52 2008 TLS: Initial packet from 192.168.0.1:1194, sid=b586788d afd49c73
Sat Jan 26 22:45:54 2008 VERIFY OK: depth=1, /C=DE/ST=CA/L=Home/O=RCB/OU=RCB/CN=fritzbox/[email protected]
Sat Jan 26 22:45:54 2008 VERIFY OK: nsCertType=SERVER
Sat Jan 26 22:45:54 2008 VERIFY OK: depth=0, /C=DE/ST=CA/O=RCB/OU=RCB/CN=fritzbox/[email protected]
Sat Jan 26 22:45:57 2008 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 26 22:45:57 2008 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 26 22:45:57 2008 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 26 22:45:57 2008 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 26 22:45:57 2008 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sat Jan 26 22:45:57 2008 [fritzbox] Peer Connection Initiated with 192.168.0.1:1194
Sat Jan 26 22:45:58 2008 SENT CONTROL [fritzbox]: 'PUSH_REQUEST' (status=1)
Sat Jan 26 22:45:58 2008 PUSH: Received control message: 'PUSH_REPLY,route 192.168.200.0 255.255.255.0,dhcp-option DNS 192.168.0.1,dhcp-option DNS 192.168.0.1,ping 10,ping-restart 120,ifconfig 192.168.200.102 192.168.200.101'
Sat Jan 26 22:45:58 2008 OPTIONS IMPORT: timers and/or timeouts modified
Sat Jan 26 22:45:58 2008 OPTIONS IMPORT: --ifconfig/up options modified
Sat Jan 26 22:45:58 2008 OPTIONS IMPORT: route options modified
Sat Jan 26 22:45:58 2008 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Jan 26 22:45:58 2008 CreateFile failed on TAP device: \\.\Global\{7C0F6B0A-FB30-489B-8B13-03DFB75C2E63}.tap
Sat Jan 26 22:45:58 2008 TAP-WIN32 device [NULL] opened: \\.\Global\{8AAD2D46-E62B-488A-9E84-742978BFE15E}.tap
Sat Jan 26 22:45:58 2008 TAP-Win32 Driver Version 8.4 
Sat Jan 26 22:45:58 2008 TAP-Win32 MTU=1500
Sat Jan 26 22:45:58 2008 NOTE: FlushIpNetTable failed on interface [262150] {8AAD2D46-E62B-488A-9E84-742978BFE15E} (status=259) : Es sind keine Daten mehr verfügbar.  
Sat Jan 26 22:45:58 2008 Succeeded in adding a temporary IP/netmask of 192.168.200.102/255.255.255.252 to interface {8AAD2D46-E62B-488A-9E84-742978BFE15E} using the Win32 IP Helper API
Sat Jan 26 22:45:58 2008 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Sat Jan 26 22:45:58 2008 route ADD 192.168.200.0 MASK 255.255.255.0 192.168.200.101
Sat Jan 26 22:45:58 2008 Route addition via IPAPI succeeded
Sat Jan 26 22:45:58 2008 Initialization Sequence Completed

Was mich immer noch stört ist
FlushIpNetTable failed on interface [262150] {8AAD2D46-E62B-488A-9E84-742978BFE15E} (status=259) : Es sind keine Daten mehr verfügbar.
Zum Vergrößern anklicken....
. Hat das eine Aussmass an die VPN-Verbindung. Dann
Sat Jan 26 22:45:58 2008 CreateFile failed on TAP device: \\.\Global\{7C0F6B0A-FB30-489B-8B13-03DFB75C2E63}.tap
Zum Vergrößern anklicken....
Was ja schon angesprochen ist. Ich habe den dev-node auf tun stehen und die Adapter sind im System aktiviert. Kann es sein das das ich zwei Tap-Adapter habe weil ich 2 Verbindungen rim zum Hoster Server und die zweite Testverbindung zur Box das es da zu Problemen mit den Adapter kommen kann? Aber das denke ich wird doch über OPENVPN GUI verwaltet!?
Ich kann sondz die IP von der Box 192.168.200.1 anpingen bzw. mit dem Browser auf die WebGui gelangen. Die Client IP auf 192.168.200.101 kann ich soweit auch anpingen.
 
Moin,

ich denke, dass das "NOTE: FlushIpNetTable failed on interface " ist in der Form egal, denn das Setzen der IPs und Routen danach klappt ja.

Hast du denn eine zweite OpenVPN Verbindung und mehrere Vpn-Adapter auf dem selben PC?
Dann wäre das "CreateFile failed on TAP device:" klar: wenn der erste "Adapter" ist belegt, und er nimmt den zweiten.

Mein Vorschlag an dieser Stelle: Da überall "succeeded" steht und die Verbindung läuft: Freu dich und bleib ruhig ;-)

Mit dem sich "mit dem Log auseinandersetzen" kann jetzt ruhen, bis du wieder Probleme hast. Deine "Fehler" oder "Anmerkungen" im Log sind nur noch "Windows-Client-Dinge", da müsstest du wenn du wirklich tiefer einsteigen willst, vielleicht noch an anderer Stelle suchen...

Jörg
 
Ja ich nutze zwei Verbindungen und habe zwei Adapter dafür install
Wenn dannn soweit läuft ist es prima.

Ich bedanke mich noch mal hier für die Hilfe und Betrachte dieses Thema erstmal für mich gelöst.
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.
Kostenlos!
Jetzt holen

Neueste Beiträge

Kategorien

Wissenswertes

Statistik des Forums

Themen
248,869
Beiträge
2,303,409
Mitglieder
378,530
Neuestes Mitglied
fanboy

3CX jetzt einen Monat kostenlos testen

Die Verbindung, Zusammenarbeit und Kommunikation mit Ihrem Team und Ihren Kunden war noch nie so einfach. Nutzen Sie unsere kostenlose 30-Tage-Testversion und entdecken Sie die richtige Lösung für Ihr Unternehmen.

3CX start your free trial guy
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten