OpenVPN Client unter Windows 7 erhält keine IP-Adresse via DHCP

Vor kurzem hatte ich das Phänomen, dass ein unter Windows 7 Professional installierter OpenVPN AS Client (1.3.4) nach drei Wochen tadelloser Funktion partout keine Netzwerkdaten via DHCP mehr beziehen wollte. Bei jeder Verbindungsherstellung blieb der Client bei folgendem Dialog stehen:

Im Log der OpenVPN Appliance (1.3.5 unter Debian Lenny) sah der Verbindungsaufbau allerdings völlig normal aus:

OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 MULTI: multi_create_instance called'
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 Re-using SSL/TLS context'
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 LZO compression initialized'
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 Control Channel MTU parms [ L:1544 D:168 EF:68 EB:0 ET:0 EL:0 ]'
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 Data Channel MTU parms [ L:1544 D:1350 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]'
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 Local Options hash (VER=V4): 'bd577cd1''
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 Expected Remote Options hash (VER=V4): 'ee93268d''
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 TCP connection established with 219.101.164.130:50797'
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 Socket Buffers: R=[131072->131072] S=[131072->131072]'
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 Socket flags: TCP_NODELAY=1 succeeded'
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 TCPv4_SERVER link local: [undef]'
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 TCPv4_SERVER link remote: 219.101.164.130:50797'
OVPN-PP 0 OUT: 'Mon May  3 16:53:35 2010 219.101.164.130:50797 TLS: Initial packet from 219.101.164.130:50797, sid=e212da71 1ba2ad01'
OVPN-PP 0 OUT: 'Mon May  3 16:53:38 2010 219.101.164.130:50797 VERIFY OK: depth=1, /CN=OpenVPN CA'
OVPN-PP 0 OUT: 'Mon May  3 16:53:38 2010 219.101.164.130:50797 VERIFY OK: nsCertType=CLIENT'
OVPN-PP 0 OUT: 'Mon May  3 16:53:38 2010 219.101.164.130:50797 VERIFY OK: depth=0, /CN=userid'
OVPN-PP 0 OUT: 'Mon May  3 16:53:40 2010 219.101.164.130:50797 TLS: Username/Password authentication deferred for username 'userid' '
OVPN-PP 0 OUT: 'Mon May  3 16:53:40 2010 219.101.164.130:50797 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key'
OVPN-PP 0 OUT: 'Mon May  3 16:53:40 2010 219.101.164.130:50797 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication'
OVPN-PP 0 OUT: 'Mon May  3 16:53:40 2010 219.101.164.130:50797 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key'
OVPN-PP 0 OUT: 'Mon May  3 16:53:40 2010 219.101.164.130:50797 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication'
AUTH SUCCESS {'status': 0, 'common_name': 'userid', 'reason': 'LDAP auth succeeded on ldap://172.16.0.55/', 'user': 'userid', 'proplist': {'prop_autologin': 'false', 'prop_deny': 'false', 'prop_superuser': 'false', 'prop_autogenerate': 'true'}} : ['push "redirect-private local"', 'push "redirect-private bypass-dhcp"', 'ifconfig-push 10.9.0.5 255.255.255.0', 'push "route-gateway 10.9.0.1"', 'push "route 172.16.0.0 255.255.0.0"', 'push "dhcp-option DNS 10.9.0.1"', 'push "dhcp-option DOMAIN domain.local"', 'comp-lzo yes', 'push "comp-lzo yes"']
OVPN-PP 0 OUT: 'Mon May  3 16:53:40 2010 MANAGEMENT: CMD 'client-auth 3 0''
OVPN-PP 0 OUT: 'Mon May  3 16:53:40 2010 219.101.164.130:50797 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA'
OVPN-PP 0 OUT: 'Mon May  3 16:53:40 2010 219.101.164.130:50797 [userid] Peer Connection Initiated with 219.101.164.130:50797'
OVPN-PP 0 OUT: 'Mon May  3 16:53:40 2010 userid/219.101.164.130:50797 OPTIONS IMPORT: LZO parms modified'
OVPN-PP 0 OUT: 'Mon May  3 16:53:40 2010 userid/219.101.164.130:50797 MULTI: Learn: 10.9.0.5 -> userid/219.101.164.130:50797'
OVPN-PP 0 OUT: 'Mon May  3 16:53:43 2010 userid/219.101.164.130:50797 PUSH: Received control message: 'PUSH_REQUEST''
OVPN-PP 0 OUT: 'Mon May  3 16:53:43 2010 userid/219.101.164.130:50797 SENT CONTROL [userid]: 'PUSH_REPLY,topology subnet,route-delay 5 30,dhcp-pre-release,dhcp-renew,dhcp-release,route-metric 101,ping 8,ping-restart 90,socket-flags TCP_NODELAY,redirect-private local,redirect-private bypass-dhcp,route-gateway 10.9.0.1,route 172.16.0.0 255.255.0.0,dhcp-option DNS 10.9.0.1,dhcp-option DOMAIN domain.local,comp-lzo yes,ifconfig 10.9.0.5 255.255.255.0' (status=1)'

Die Ursache für das Problem habe ich nicht herausgefunden: Der DHCP-Client Service von Windows 7 lief, die Windows Firewall ließ DHCP-Traffic in beide Richtungen zu und auch mit dem Community Client 2.1.1 traten exakt dieselben Probleme auf. Es gibt allerdings einen Workaround!

Mithilfe der ip-win32 Clientdirektive kann beeinflusst werden, wie OpenVPN die Netzwerkeinstellungen auf den TAP-Win32-Adapter anwendet. Standardmäßig ist dabei laut Dokumentation die Direktive ip-win32 adaptive aktiv (zumindest unter Community OpenVPN 2.1), bei der 20 Sekunden lang versucht wird, die Netzwerkdaten via DHCP zu beziehen. Schläg dies fehl, soll OpenVPN automatisch auf Methode netsh umschwenken, womit die Netzwerkeigenschaften des TAP-Win32-Adapters von dynamisch auf statisch geändert und die Netzwerkdaten fest auf dem Interface eintragen werden.

Das automatische Umschwenken hat in meinem Fall zwar nicht funktioniert. Durch Angabe der Direktive ip-win32 netsh in der Clientkonfiguration ließ sich die alternative Methode aber problemlos erzwingen und die Verbindung schließlich zum Laufen bringen. Neben Netzwerkmaske und IP-Adresse wurde auch der DNS-Server statisch eingetragen.

Wenn jemand mit demselben Problem konfrontiert wird und die Ursache herausfindet, würde ich mich über eine kurze Info sehr freuen.

Update: Im Nachhinein sieht es so aus, als wäre der Fehler durch ein Downgrade der Web’n’Walk UMTS Software von T-Mobile verursacht worden. Offenbar hat der Benutzer die aktuelle Version mit einer alten Version überschrieben und damit einige Winsock Einstellungen zerschossen. Betroffen vom DHCP-Problem war übrigens nicht nur der TAP-Win32-Adapter von OpenVPN, sondern auch jede andere Netzwerkverbindung. Beim Aufruf von ipconfig /renew kam es immer zu folgender Fehlermeldung:

    Der angeforderte Diensteanbieter konnte konnte nicht geladen oder initialisiert werden.

Auf der Suche nach dieser Fehlermeldung bin ich auf den Blog TexHex und damit den Hinweis auf die UMTS-Software gestoßen. Die dort genannte Lösung hat das Problem auch tatsächlich behoben: Durch Eingabe des Befehls netsh winsock reset catalog in der Eingabeaufforderung (Achtung: Unter Windows 7 als Administrator starten!) werden diverse Winsock-Einstellungen wieder zurückgesetzt und alles funktioniert wieder so, wie es soll.

About these ads

2 Responses to “OpenVPN Client unter Windows 7 erhält keine IP-Adresse via DHCP”


  1. 1 Oliver Juni 8, 2010 um 11:24 vormittags

    Îch möchte dem Verfasser dieser hilfreichen Seite mein allergrößtes Lob aussprechen.
    Hätte ich diese Info vorher gehabt, hätte ich mit drei Tage Recherche sparen können und hätte ein Magengeschwür weniger.

    Vielen Dank.

  2. 2 Hans August 6, 2011 um 6:18 vormittags

    Danke ebenfalls, hab einmal “netsh winsock reset catalog” als Admin ausgeführt und schon funktionierte es einwandfrei !


Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ photo

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s





Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

%d Bloggern gefällt das: