2.3.0 "new stable" crashes on Win 7

[Al@COPE]

I've been attempting to upgrade from 2.2.2 "old stable" to 2.3.0, but have had to rollback to 2.2.2 due to unusable crashing when launching 2.3.0.

The server (in our office) is still running 2.2.2. I have not yet tested whether this is part of the problem.

On two different PC's (one running Win 7 Enterprise 64-bit, 12Gb RAM, and the other Win 7 Home Premium 64-bit, 8Gb RAM) the same problem occurs with the 64-bit version of 2.3.0.

Steps:
1. Manually uninstalled 2.2.2 (32-bit)
2. Installed 2.3.0 x86_64, renamed TAP adapter to match my config (simply "OpenVPN-TAP").
3. Copied config file and cert + key files to 64-bit location.
4. Updated config to use new paths (by removing "(x86)" from old paths).
5. Tested by right-click and "Start OpenVPN on this config file".
6. Process crashes with "Daemon stopped working" message from Windows.
Process reaches "Extracted DHCP router address:" at point of crash.
This is the same crash point for all connection attempts.

Following this repeated crash, I then:
7. Added log file setting and updated logging verb to level 5
8. Log file populates and stops at same point.

Log file content below:

Sun Feb 10 16:13:46 2013 us=316993 OpenVPN 2.3.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Jan 8 2013
Sun Feb 10 16:13:46 2013 us=316993 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun Feb 10 16:13:46 2013 us=675794 Control Channel Authentication: using 'C:\Program Files\OpenVPN\CopeKeys\hmacf-w.key' as a OpenVPN static key file
Sun Feb 10 16:13:46 2013 us=675794 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 10 16:13:46 2013 us=675794 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 10 16:13:46 2013 us=675794 LZO compression initialized
Sun Feb 10 16:13:46 2013 us=675794 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sun Feb 10 16:13:46 2013 us=675794 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun Feb 10 16:13:46 2013 us=738194 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Feb 10 16:13:46 2013 us=738194 Local Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532,proto UDPv4,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Sun Feb 10 16:13:46 2013 us=738194 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532,proto UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Sun Feb 10 16:13:46 2013 us=738194 Local Options hash (VER=V4): '13a273ba'
Sun Feb 10 16:13:46 2013 us=738194 Expected Remote Options hash (VER=V4): '360696c5'
Sun Feb 10 16:13:46 2013 us=738194 UDPv4 link local: [undef]
Sun Feb 10 16:13:46 2013 us=738194 UDPv4 link remote: [AF_INET]<snipped for privacy>
Sun Feb 10 16:13:46 2013 us=769394 TLS: Initial packet from [AF_INET]<snipped for privacy>, sid=9c88dbd1 512f9336
Sun Feb 10 16:13:46 2013 us=987794 VERIFY OK: depth=1, C=UK, ST=Nottinghamshire, L=Nottingham, O=COPE, CN=COPE-CA, emailAddress=<snipped for privacy>
Sun Feb 10 16:13:46 2013 us=987794 VERIFY OK: nsCertType=SERVER
Sun Feb 10 16:13:46 2013 us=987794 VERIFY OK: depth=0, C=UK, ST=Nottinghamshire, O=COPE, CN=server, emailAddress=<snipped for privacy>
Sun Feb 10 16:13:47 2013 us=455795 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Feb 10 16:13:47 2013 us=455795 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 10 16:13:47 2013 us=455795 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Feb 10 16:13:47 2013 us=455795 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 10 16:13:47 2013 us=455795 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sun Feb 10 16:13:47 2013 us=455795 [server] Peer Connection Initiated with [AF_INET]62.172.32.203:8991
Sun Feb 10 16:13:51 2013 us=153002 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sun Feb 10 16:13:51 2013 us=184202 PUSH: Received control message: 'PUSH_REPLY,route-gateway dhcp,ping 10,ping-restart 120'
Sun Feb 10 16:13:51 2013 us=184202 OPTIONS IMPORT: timers and/or timeouts modified
Sun Feb 10 16:13:51 2013 us=184202 OPTIONS IMPORT: route-related options modified
Sun Feb 10 16:13:51 2013 us=199802 open_tun, tt->ipv6=0
Sun Feb 10 16:13:51 2013 us=199802 TAP-WIN32 device [OpenVPN-TAP] opened: \\.\Global\{F6FDBD83-CA17-409B-A741-9E6F600C939B}.tap
Sun Feb 10 16:13:51 2013 us=199802 TAP-Windows Driver Version 9.9
Sun Feb 10 16:13:51 2013 us=199802 TAP-Windows MTU=1500
Sun Feb 10 16:13:51 2013 us=199802 NOTE: FlushIpNetTable failed on interface [17] {F6FDBD83-CA17-409B-A741-9E6F600C939B} (status=5) : Access is denied.
Sun Feb 10 16:13:51 2013 us=293402 Extracted DHCP router address: 10.0.0.2


I'm not worried about /2FlushIpNetTable filed", this is normal message when not running as Admin.

I see several people have posted similar comments about 2.3.0 not working and having to roll back to 2.2.2. It looks like 2.3.0 is not stable and hasn't been fully regression-tested, or there is a compatibility break when connecting to an older server version that is still running 2.2.2.

I did also try the 32-bit client which also failed but with slightly different issues, but have not yet logged the issues in detail for posting.

Comments/feedback/solutions welcomed.

Al

[alangunnsteel]

I had exactly the same experience.
Vanilla OpenVPN installation on a W7Pro laptop -- a very clean and problem-free system (I'm a rather dull system administrator).
Rolled back to the previous release, and everything works great.
Was connecting to a Tomato-based home router.

[ste123]

I also had the same issue, crashing immediately after "Extracted DHCP router address: x.x.x.x".

I tried adding verb 99 to my client.ovpn file however it is still the last log entry.

Client: Win 7 64, "OpenVPN 2.3.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Mar 7 2013"
Server: Ubuntu Server 12.04, "OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 30 2012"

I was able to stop it from crashing by adding option redirect-gateway to my client.ovpn file. Tested with the following flags:

redirect-gateway
redirect-gateway def1

As soon as I remove the option, it crashes at the same point.

Use of this option may or may not be ideal for your setup, but for me it's what got me to establish a connection with 2.3.0. That said, I may roll back to 2.2.2 until the issue is resolved.

[eibgrad]

Can't believe this is STILL broken!

Running 2.3.1 on Windows 7 (x64) and having the exact same problem. When configured as routed tunnel (tun), it works fine. But as soon as I change it to bridged (tap) and NOT pushing the default gateway, it gets to DHCP assignment and crashes the OpenVPN daemon. Take that same bridged config, push the default gateway, it works fine again.

I understand that bugs are inevitable, but how could this still be a problem a year and a revision later? I find it hard to believe this doesn't affect a significant number of users.

[Al@COPE]

Latest client (2.3.2 - I003 x86_64) has corrected whatever the problem was occurring for me under 2.3.0 on Windows 7 (64-bit).
Just thought those of you who had similar issues might like to know this if you hadn't already discovered it.

Took me a while to discover this as I've been using a Linux desktop for the last year instead (just been updating some of the services that are not automatically updated on my Win-7 partition, as it is now very rarely used!).

[arslan1]

I see several people have posted similar comments about 2.3.0 not working and having to roll back to 2.2.2. It looks like 2.3.0 is not stable and hasn't been fully regression-tested, or there is a compatibility break when connecting to an older server version that is still running 2.2.2.

_______________
Arslan1