[Problem] OpenVPN Konfigurations-Problem - Client hat keinen Internetzugriff

[horst123456]

Hallo allerseits,

ich habe auf meiner Fritzbox Freetz mit OpenVPN laufen - ich habe als Einstellungen Tunnel, Zertifikate und TLS-Authentifizierung gewählt.
Es soll sich (zur Zeit) ein einziger Client zum Netzwerk verbinden und darüber im Internet surfen können (Sicherheit bei öffentlichen Hotspots).

Ich habe die ganzen Zertifikate/Schlüssel erstellt und eingetragen, mein Client kann sich zum Netzwerk verbinden, kommt jedoch nicht ins Internet. Die Fritzbox kann ich über die "192.168.200.1" (siehe Konfiguration weiter unten) aufrufen. "www.heise.de" kann ich nicht anpingen, dafür aber "193.99.144.80". Der Browseraufruf von "www.heise.de" schlägt ebenfalls fehl. Trage ich die Heise-IP im Browser ein, so ändert sich dich Adresszeile zu "www.heise.de" (Cache und Verlauf gelöscht), mehr passiert dann aber auch nicht.
Hier bin ich etwas verwirrt - erst dachte ich, es liegt an der Namensauflösung (ping auf IP funktioniert, auf Adresse hingegen nicht) - die Tatsache, dass bei IP-Aufruf im Browser die Adresse angezeigt wird, würde doch aber das Gegenteil bedeuten, oder nicht?

Auf der Fritzbox habe ich in der Datei "/var/flash/ar7.cfg" bei den "forwardrules" eingefügt (kommen noch weitere Regeln, daher ein Komma am Ende):

"udp 0.0.0.0:1194 0.0.0.0:1194 # OpenVPN",

So sieht die openvpn.conf auf der Fritzbox (192.168.178.1) aus:

#  OpenVPN 2.1 Config, Sat Jul 28 23:06:41 CEST 2012
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
tls-auth /tmp/flash/openvpn/static.key 0
port 1194
ifconfig 192.168.200.1 192.168.200.2
push "route 192.168.178.0 255.255.255.0"
push "redirect-gateway"
tun-mtu 1500
mssfix
verb 3
daemon
cipher AES-256-CBC
comp-lzo
float
keepalive 10 120
status /var/log/openvpn.log
chroot /tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

Da nur ein Client verbinden soll, habe ich "DHCP-Range für Clients" leer gelassen, so bekommt der Client ja nun die 192.168.200.2.
Weiterhin habe ich "Jedes Paket des Clients umleiten" angekreuzt, als DNS-Server hatte ich schon folgendes versucht:
- leer lassen
- 192.168.178.1
- 192.168.200.1
- 8.8.8.8 und weitere öffentliche DNS-Server

Bei meinem Client sieht die Config so aus:

client
dev tun
proto udp
remote name.no-ip.org 1194
resolv-retry infinite
nobind
persist-key
persist-tun
tls-client
ifconfig 192.168.200.2 192.168.200.1
route 192.168.178.0 255.255.255.0
ca "C:\\Program Files (x86)\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files (x86)\\OpenVPN\\config\\client1.crt"
key "C:\\Program Files (x86)\\OpenVPN\\config\\client1.key"
tls-auth "C:\\Program Files (x86)\\OpenVPN\\config\\key.key" 1
cipher AES-256-CBC
comp-lzo
verb 3

Ich wäre euch sehr dankbar, wenn mir jemand bei der Problemlösung weiterhelfen kann.

Was sollte ich als DNS-Server unter den Server-Einstellungen im Freetz-Webinterface eintragen?
Was muss ich an den Konfigurationen ändern?
Wozu sollte ich mich vielleicht noch weiter belesen, um dem Problem auf die Spur zu kommen?

 

[MaxMuster]

Füge mal beim Client ein “pull “ hinzu. Wird dem Client denn ein DNS-Server übertragen? Schau das im Log beim Client oder direkt in der Shell nach, welcher DNS eingetragen ist.

 

[horst123456]

Meine ersten Versuche waren vom Smartphone aus - da habe ich das Problem wie folgt gelöst:
Ich habe ihm beim VPN selbst als DNS die "192.168.200.1" eingetragen, damit klappt es nun.

Auf meinem Notebook ist er beim Verbinden bei "Route: Waiting for TUN/TAP interface to come up..." nicht weitergekommen, die Meldung kam einfach immer wieder. Dabei war es egal, was ich auf dem Server für einen DNS eingetragen habe - auch mit und ohne "pull" bei der Client-Config.

Nun habe ich beim Notebook das gleiche gemacht wie beim Smartphone:
Bei dem VPN-Netzwerk-Adapter habe ich als DNS die "192.168.200.1" eingetragen. Damit verbindet er ohne Probleme und ich kann auch surfen - im Log steht aber dennoch "ROUTE_default_gateway 192.168.43.1".
Selbige Meldung steht auch, wenn ich aus dem Netzwerk-Adapter den DNS lösche und auf "automatisch beziehen" stelle, trotzdem hat er dann als DNS die "192.168.200.1" stehen und ich kann surfen. Scheinbar hat er sich den DNS irgendwo gespeichert oder so.

Ist es ratsam, ihm von Hand den DNS einzutragen oder eher nicht?

Zum Testen habe ich jetzt sowohl beim Smartphone als auch beim Notebook die gleiche Config genutzt, ich hatte nur noch ein zweites Zertifikat für das Notebook erstellt und die Pfade angepasst.

Was muss ich an der Konfiguration ändern, damit beide gleichzeitig per VPN verbinden können?
Beim Server habe ich die "Max. Clients" auf 2 gesetzt, als DHCP-Range habe ich "192.168.200.3 192.168.200.4" angegeben.
Nun ist dem Notebook scheinbar egal, ob ich in der Config "ifconfig 192.168.200.3 192.168.200.1" schreibe, er bezieht trotzdem die "192.168.200.2".
Lasse ich beide gleichzeitig verbinden (in der Config "ifconfig 192.168.200.2 192.168.200.1"), dann verbindet einer mit der "192.168.200.2", der andere mit der "192.168.200.6". Letztere Adresse ist jedoch keine aus dem DHCP-Range des Servers?!


Nächstes Mysterium:
Ich habe die VPN-Verbindung beim Notebook beendet und mich vom Wlan-Hotspot des Smartphones getrennt. Danach habe ich die Wlan-Verbindung zur Fritzbox aufgebaut, erhalte jedoch nur eingeschränkte Konnektivität.
Trotz aktiviertem DHCP ist als IP die "192.168.43.131" und als Gateway die "192.168.43.1" drin - erst nachdem Deaktivieren/Aktivieren des Adapters wird eine korrekte IP bezogen.

 

[MaxMuster]

Auf meinem Notebook ist er beim Verbinden bei "Route: Waiting for TUN/TAP interface to come up..." nicht weitergekommen, die Meldung kam einfach immer wieder....

Windows Vista oder 7? Dann dürte ein “route-method exe” and “route-delay 2″ in der Konfig fehlen und dir helfen.

.. im Log steht aber dennoch "ROUTE_default_gateway 192.168.43.1"...

Klar, das sagt auch nur, welches DG dein PC hat(te), als das VPN gestartet wurde. Das ist der "ist Zustand" und hat nix mit dem VPN zu tun.

Selbige Meldung steht auch, wenn ich aus dem Netzwerk-Adapter den DNS lösche und auf "automatisch beziehen" stelle, trotzdem hat er dann als DNS die "192.168.200.1" stehen und ich kann surfen. Scheinbar hat er sich den DNS irgendwo gespeichert oder so.

Wenn du den DNS im Server eingetragen hast, sollte er ihn per pull holen. Wird er übertragen? Was Windows alles wo zwischenspeichert übersteigt mein Wissen...

Beim Server habe ich die "Max. Clients" auf 2 gesetzt, als DHCP-Range habe ich "192.168.200.3 192.168.200.4" angegeben.
Nun ist dem Notebook scheinbar egal, ob ich in der Config "ifconfig 192.168.200.3 192.168.200.1" schreibe, er bezieht trotzdem die "192.168.200.2".
Lasse ich beide gleichzeitig verbinden (in der Config "ifconfig 192.168.200.2 192.168.200.1"), dann verbindet einer mit der "192.168.200.2", der andere mit der "192.168.200.6". Letztere Adresse ist jedoch keine aus dem DHCP-Range des Servers?!

Wenn das "ifconfig" vor dem "pull" kommt, dürften die vom Server geschickten Befehle die lokalen überschreiben. Wie sieht jetzt die Config des Servers aus? Wie die übertragenen Werte? Ist dort jeweils ein "topology subnet" drin?

Ich habe die VPN-Verbindung beim Notebook beendet und mich vom Wlan-Hotspot des Smartphones getrennt. Danach habe ich die Wlan-Verbindung zur Fritzbox aufgebaut, erhalte jedoch nur eingeschränkte Konnektivität.
Trotz aktiviertem DHCP ist als IP die "192.168.43.131" und als Gateway die "192.168.43.1" drin - erst nachdem Deaktivieren/Aktivieren des Adapters wird eine korrekte IP bezogen.

Ist denn diese IP (192.168.43.131) nicht richtig? Welches ist die "korrekte" IP? Und um ehrlich zu sein, will ich garnicht wissen, wann es nach der werten Meinung von Windows für ein Netzwerk gegeben ist, volle Konnektivität zu haben ;-)

 

[horst123456]

Windows Vista oder 7? Dann dürte ein “route-method exe” and “route-delay 2″ in der Konfig fehlen und dir helfen.

Windows 7 - ich habe beide Sachen in der Config hinzugefügt, keine Änderung.

Hier mal die Config:

client
dev tun
proto udp
remote name.no-ip.org 1194
resolv-retry infinite
nobind
persist-key
persist-tun
tls-client
route-method exe
route-delay 2
pull
ifconfig 192.168.200.2 192.168.200.1
route 192.168.178.0 255.255.255.0
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\client2.crt"
key "C:\\Program Files\\OpenVPN\\config\\client2.key"
tls-auth "C:\\Program Files\\OpenVPN\\config\\key.key" 1
cipher AES-256-CBC
comp-lzo
verb 3

Klar, das sagt auch nur, welches DG dein PC hat(te), als das VPN gestartet wurde. Das ist der "ist Zustand" und hat nix mit dem VPN zu tun.

Witzig nur, dass die IP absolut nichts mit meinem Netzwerk zu tun hat. Mein Router hat die "192.168.178.1", alle Rechner usw. bewegen sich in "192.168.178.xx". Da hat die "192.168.43.131" nichts zu suchen, genauso wenig wie der DNS "192.168.43.1".

Wenn du den DNS im Server eingetragen hast, sollte er ihn per pull holen. Wird er übertragen?

Auch mit der obigen Config kommt keine VPN-Verbindung zustande:

Sun Jul 29 17:32:02 2012 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sun Jul 29 17:32:02 2012 PUSH: Received control message: 'PUSH_REPLY,route 192.168.178.0 255.255.255.0,route 192.168.200.1,dhcp-option DNS 192.168.200.1,redirect-gateway,ping 10,ping-restart 120,ifconfig 192.168.200.2 192.168.200.1'
Sun Jul 29 17:32:02 2012 OPTIONS IMPORT: timers and/or timeouts modified
Sun Jul 29 17:32:02 2012 OPTIONS IMPORT: --ifconfig/up options modified
Sun Jul 29 17:32:02 2012 OPTIONS IMPORT: route options modified
Sun Jul 29 17:32:02 2012 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Jul 29 17:32:02 2012 ROUTE default_gateway=192.168.43.1
Sun Jul 29 17:32:02 2012 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{BF8FE274-A302-45B1-B7F7-A0B1AC0F39EC}.tap
Sun Jul 29 17:32:02 2012 TAP-Win32 Driver Version 9.7 
Sun Jul 29 17:32:02 2012 TAP-Win32 MTU=1500
Sun Jul 29 17:32:02 2012 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.200.2/255.255.255.252 on interface {BF8FE274-A302-45B1-B7F7-A0B1AC0F39EC} [DHCP-serv: 192.168.200.1, lease-time: 31536000]
Sun Jul 29 17:32:02 2012 Successful ARP Flush on interface [16] {BF8FE274-A302-45B1-B7F7-A0B1AC0F39EC}
Sun Jul 29 17:32:04 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:04 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:06 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:06 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:08 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:08 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:09 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:09 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:10 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:10 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:11 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:11 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:12 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:12 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:13 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:13 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:14 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:14 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:15 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:15 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:16 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:16 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:18 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:18 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:19 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:19 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:20 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:20 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:21 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:21 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:22 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:22 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:23 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:23 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:24 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:24 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:25 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:25 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:26 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:26 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:27 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:27 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:28 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:28 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:29 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:29 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:30 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:30 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:31 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:31 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:32 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:32 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:33 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:33 2012 Route: Waiting for TUN/TAP interface to come up...
Sun Jul 29 17:32:34 2012 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down
Sun Jul 29 17:32:34 2012 C:\WINDOWS\system32\route.exe ADD xx.xx.xx.xx MASK 255.255.255.255 192.168.43.1
 OK!
Sun Jul 29 17:32:35 2012 C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 192.168.43.1
 OK!
Sun Jul 29 17:32:35 2012 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 192.168.200.1
Hinzufgen der Route fehlgeschlagen: Element nicht gefunden.
Sun Jul 29 17:32:35 2012 C:\WINDOWS\system32\route.exe ADD 192.168.178.0 MASK 255.255.255.0 192.168.200.1
Hinzufgen der Route fehlgeschlagen: Element nicht gefunden.
Sun Jul 29 17:32:35 2012 C:\WINDOWS\system32\route.exe ADD 192.168.178.0 MASK 255.255.255.0 192.168.200.1
Hinzufgen der Route fehlgeschlagen: Element nicht gefunden.
Sun Jul 29 17:32:35 2012 OpenVPN ROUTE: omitted no-op route: 192.168.200.1/255.255.255.255 -> 192.168.200.1
SYSTEM ROUTING TABLE
31.16.21.105 255.255.255.255 192.168.43.1 p=0 i=13 t=4 pr=3 a=0 h=0 m=26/0/0/0/0
127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=3 a=914 h=0 m=306/0/0/0/0
127.0.0.1 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=3 a=914 h=0 m=306/0/0/0/0
127.255.255.255 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=3 a=914 h=0 m=306/0/0/0/0
169.254.0.0 255.255.0.0 169.254.75.8 p=0 i=16 t=3 pr=3 a=899 h=0 m=286/0/0/0/0
169.254.75.8 255.255.255.255 169.254.75.8 p=0 i=16 t=3 pr=3 a=899 h=0 m=286/0/0/0/0
169.254.255.255 255.255.255.255 169.254.75.8 p=0 i=16 t=3 pr=3 a=899 h=0 m=286/0/0/0/0
192.168.43.0 255.255.255.0 192.168.43.131 p=0 i=13 t=3 pr=3 a=532 h=0 m=281/0/0/0/0
192.168.43.131 255.255.255.255 192.168.43.131 p=0 i=13 t=3 pr=3 a=532 h=0 m=281/0/0/0/0
192.168.43.255 255.255.255.255 192.168.43.131 p=0 i=13 t=3 pr=3 a=532 h=0 m=281/0/0/0/0
224.0.0.0 240.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=3 a=914 h=0 m=306/0/0/0/0
224.0.0.0 240.0.0.0 169.254.75.8 p=0 i=16 t=3 pr=3 a=909 h=0 m=286/0/0/0/0
224.0.0.0 240.0.0.0 192.168.43.131 p=0 i=13 t=3 pr=3 a=900 h=0 m=281/0/0/0/0
255.255.255.255 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=3 a=914 h=0 m=306/0/0/0/0
255.255.255.255 255.255.255.255 169.254.75.8 p=0 i=16 t=3 pr=3 a=909 h=0 m=286/0/0/0/0
255.255.255.255 255.255.255.255 192.168.43.131 p=0 i=13 t=3 pr=3 a=900 h=0 m=281/0/0/0/0
SYSTEM ADAPTER LIST
TAP-Win32 Adapter V9
  Index = 16
  GUID = {BF8FE274-A302-45B1-B7F7-A0B1AC0F39EC}
  IP = 169.254.75.8/255.255.0.0 
  MAC = 00:ff:bf:8f:e2:74
  GATEWAY = 0.0.0.0/255.255.255.255 
  DHCP SERV = 0.0.0.0/255.255.255.255 
  DHCP LEASE OBTAINED = Sun Jul 29 17:32:35 2012
  DHCP LEASE EXPIRES  = Sun Jul 29 17:32:35 2012
  DNS SERV =  
Atheros AR9285 802.11b/g/n WiFi Adapter
  Index = 13
  GUID = {0DCB20D9-E0A7-4BA7-8DDD-FDBDE5FDE095}
  IP = 192.168.43.131/255.255.255.0 
  MAC = xx:xx:xx:xx:xx:xx
  GATEWAY = 0.0.0.0/255.255.255.255 
  DHCP SERV = 192.168.43.1/255.255.255.255 
  DHCP LEASE OBTAINED = Sun Jul 29 17:23:44 2012
  DHCP LEASE EXPIRES  = Sun Jul 29 18:23:44 2012
  DNS SERV = 192.168.43.1/255.255.255.255 
Sun Jul 29 17:32:35 2012 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )
Sun Jul 29 17:32:35 2012 TCP/UDP: Closing socket
Sun Jul 29 17:32:35 2012 C:\WINDOWS\system32\route.exe DELETE 192.168.178.0 MASK 255.255.255.0 192.168.200.1
L”schen der Route fehlgeschlagen: Element nicht gefunden.
Sun Jul 29 17:32:35 2012 C:\WINDOWS\system32\route.exe DELETE 192.168.178.0 MASK 255.255.255.0 192.168.200.1
L”schen der Route fehlgeschlagen: Element nicht gefunden.
Sun Jul 29 17:32:35 2012 C:\WINDOWS\system32\route.exe DELETE xx.xx.xx.xx MASK 255.255.255.255 192.168.43.1
 OK!
Sun Jul 29 17:32:35 2012 C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 192.168.200.1
L”schen der Route fehlgeschlagen: Element nicht gefunden.
Sun Jul 29 17:32:35 2012 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 192.168.43.1
 OK!
Sun Jul 29 17:32:35 2012 Closing TUN/TAP interface

Wenn ich den DNS im VPN-Adapter eintrage, dann läuft's.

Wie sieht jetzt die Config des Servers aus? Wie die übertragenen Werte? Ist dort jeweils ein "topology subnet" drin?

Die Server-Config ist noch die aus dem ersten Post, als DNS habe ich jetzt die "192.168.200.1". Was meinst du mit "topology subnet"?

Ist denn diese IP (192.168.43.131) nicht richtig? Welches ist die "korrekte" IP?

Siehe oben - und wieder musste ich erst den Wlan-Adapter deaktivieren und aktivieren, damit er per DHCP alles korrekt zugewiesen bekommt.

 

[MaxMuster]

Windows 7 - ich habe beide Sachen in der Config hinzugefügt, keine Änderung.

Dann setze das delay mal höher, bis es funktioniert, das IF ist noch immer "down", wenn du versuchst, die Routen zu setzen...

Witzig nur, dass die IP absolut nichts mit meinem Netzwerk zu tun hat. Mein Router hat die "192.168.178.1", alle Rechner usw. bewegen sich in "192.168.178.xx". Da hat die "192.168.43.131" nichts zu suchen, genauso wenig wie der DNS "192.168.43.1".

Glaube ich dir nicht ;-) Kann es vielleicht sein, dass du deinen oben genannten "Wlan-Hotspot des Smartphones" nicht im Blick hattest?!?
In deinem Log oben steht die 192.168.43.131 auch bei deinem "Atheros AR9285 802.11b/g/n WiFi Adapter" drin.

Wenn ich den DNS im VPN-Adapter eintrage, dann läuft's.

Wie, nur DNS eintragen, keine IP und die ganze Sache läuft, mit Routing, IP beziehen und allem?
Naja, wenn es so geht, dann lass es einfach so und unsere Diskussion wird überflüssig .

Was meinst du mit "topology subnet"?

Kurz: Das Windows-Interface konnte (mit früheren OpenVPN-Versionen) nur "Mini-Netze" mit der Maske 255.255.255.252. Um ein komplettes Netz zu nutzen, muss man dies bei neueren Versionen deshalb explizit mit "topology subnet" anweisen. Lies das bei Interesse bei openvpn.net nach, das ist da gut beschrieben.
Ohne diesen Eintrag bekommen die Clients aufeinander folgend immer /30-er Netze zugewiesen.
Das kannst du z.B. im Freetz durch die "erweiterten Clienteinstellungen", bei denen du pro Client Einträge machen kannst, auch mit Freetz erreichen.

Siehe oben - und wieder musste ich erst den Wlan-Adapter deaktivieren und aktivieren, damit er per DHCP alles korrekt zugewiesen bekommt.

Das hat aber wohl eher mit Windows oder deinem "Hotspot" zu tun als mit OpenVPN, was und wie das mit WLAN umgeht...

 

[horst123456]

Kann es vielleicht sein, dass du deinen oben genannten "Wlan-Hotspot des Smartphones" nicht im Blick hattest?!?

Punkt für dich, daran habe ich noch nicht gedacht.

Wie, nur DNS eintragen, keine IP und die ganze Sache läuft, mit Routing, IP beziehen und allem?

Bei meinem Handy gibt's einen Punkt "VPN DNS Server", dort habe ich einfach die "192.168.200.1" eingetragen, damit läuft's - also surfen über VPN und alles.
Genauso beim Notebook - die IP habe ich auf DHCP gelassen, den DNS manuell mit "192.168.200.1" festgelegt, auch damit geht's dann sofort.

Ob er die IP nun vom Server bezieht oder aus der Config nimmt, weiß ich nicht - immerhin wurde auch schon mit der Client-Config "ifconfig 192.168.200.3 192.168.200.1" die "192.168.200.2" oder teilweise auch die "192.168.200.6" (die noch nichtmal im DHCP-Bereich des VPN-Servers liegt, denn dort habe ich als DHCP-Range "192.168.200.3 192.168.200.4") genommen.

Kann ich bei beiden Clients so eine Config nehmen (nur mit Anpassung der Zertifikat-Pfade)?

client
dev tun
proto udp
remote name.no-ip.org 1194
resolv-retry infinite
nobind
persist-key
persist-tun
tls-client
pull
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\client2.crt"
key "C:\\Program Files\\OpenVPN\\config\\client2.key"
tls-auth "C:\\Program Files\\OpenVPN\\config\\key.key" 1
cipher AES-256-CBC
comp-lzo
verb 3

Oder sollten diese beiden Punkte dort noch untergebracht werden (wobei ich auch dann nicht weiß, ob er die IP aus der Config, aus dem DHCP-Bereich des Servers oder eine andere nimmt)?
Z. B.:
Client 1

ifconfig 192.168.200.2 192.168.200.1
route 192.168.178.0 255.255.255.0

Client 2

ifconfig 192.168.200.3 192.168.200.1
route 192.168.178.0 255.255.255.0

Sollte an der Reihenfolge in der Config noch was geändert werden?
Wenn "ifconfig" und "route" mit drin sind, sollte das "pull" davor oder dahinter?

 

[MaxMuster]

Wenn du die IP und Route vom Server aus überträgst, kannst du diese Einträge getrost in der Client-Config weglassen.
Habe das nochmal nachgestellt: Die "gepullten" Werte überschreiben die in der Config unabhängig davon, wo der Befehl steht.

 

[horst123456]

Wenn du die IP und Route vom Server aus überträgst, kannst du diese Einträge getrost in der Client-Config weglassen.
Habe das nochmal nachgestellt: Die "gepullten" Werte überschreiben die in der Config unabhängig davon, wo der Befehl steht.

Alles klar - ich habe beide Punkte nun einfach rausgenommen. Trotz "pull" wird immernoch kein DNS übertragen, daher bleibe ich dann bei der manuellen Konfiguration beim Client.

Eine Sache habe ich aber noch. Wenn ich mich mit meinem Client verbinden möchte, erscheint im Log die Meldung:

WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.

Dabei habe ich aber (wie oben in der Server- sowie Client-Config erkennbar) in der Client-Config "tls-client" stehen und auf dem Server den Punkt "TLS-Authentifizierung" aktiviert - dazu habe ich mit OpenVPN einen Static-Key generiert und sowohl beim Client als auch beim Server eingetragen. Warum kommt also noch diese Meldung?

 

[MaxMuster]

DNS wird schon übertragen (siehe im Log: "...dhcp-option DNS 192.168.200.1..."), warum das nicht angenommen wird???

Die Warnung kommt, weil du nicht überprüfst, ob das Zertifikat des Servers auch ein "Server-Zertifikat" ist. So könnte jemand mit gültig signiertem Client-Zertifikat sich als Server ausgeben.
Die angegebene Webseite zeigt dir die Ursache und auch "Lösungswege", z.B. das von der Freetz-GUI für einen Client eingetragene "ns-cert-type server".

 

[horst123456]

DNS wird schon übertragen (siehe im Log: "...dhcp-option DNS 192.168.200.1..."), warum das nicht angenommen wird???

Gute Frage, nächste!

Die Warnung kommt, weil du nicht überprüfst, ob das Zertifikat des Servers auch ein "Server-Zertifikat" ist. So könnte jemand mit gültig signiertem Client-Zertifikat sich als Server ausgeben.
Die angegebene Webseite zeigt dir die Ursache und auch "Lösungswege", z.B. das von der Freetz-GUI für einen Client eingetragene "ns-cert-type server".

Also reicht es in meinem Fall (da TLS-Auth schon aktiviert und entsprechender Static-Key erstellt wurde) beim Client ein "ns-cert-type server" in die Config einzufügen, und das wars? Oder verstehe ich da noch was falsch?
Einen entsprechenden Unterpunkt dazu sehe ich in der Freetz-GUI nicht.
Auf Empfehlung von OpenVPN habe ich auch noch ein "auth-nocache" in die Client-Config eingefügt.

edit: So, ich hatte jetzt nochmal etwas mehr Zeit.
Um "ns-cert-type server" in die Client-Config zu nehmen, muss man mit "build-key-server server" ein Zertifikat anlegen und das in der Freetz-GUI des Servers unter "Box Cert" eintragen.
Ich habe die ganze Sache unter anderem mit dieser Anleitung konfiguriert, daher habe ich schon ein entsprechendes Zertifikat angelegt und bei "Box Cert" eingefügt. Damit sollte es jetzt also wirklich reichen die Client-Config um den Punkt "ns-cert-type server" zu erweitern, oder?

 

[MaxMuster]

Ja, ein "ns-cert-type server" in der Client Config prüft, ob das Zertifikat des Servers als "Server-Zertifikat" erstellt wurde. Damit entfällt dann die Warnung, dass diese Prüfung nicht erfolgt ist.
In der GUI wird das, wenn du einen Client konfigurierst, standardmäßig geprüft, ist aber "abschaltbar". Bei einer Serverconfig ist sowas nicht sinnvoll nutzbar, da es eine Client-Option ist...

Das ist aber eben auch "nur" eine Warnung, dass eine mögliche Überprüfung nicht gewählt wurde. In einem privaten Umfeld, in dem du selbst die CA unter dir hast, ist das eigentlich überflüssig...