Eddie 2.19.6 won't connect using Wintun Adapter.

[blockchain420 0]

Hello,

 I have been using Eddie 2.18.9 Windows 10 x64 with no problems connecting using TAP adapter. I decided to upgrade to the new Eddie 2.19.6 version with Wintun support after I read about the performance enhancements i.e faster speeds then using the TAP adapter but can't seem to get it to work. Every time I attempt to connect to any server, I get the following error message on my logs: "OpenVPN > ERROR: netsh command failed: returned error code 1." I can't seem to figure out what I am doing wrong. I have uninstalled both Wintun driver and Eddie then did a clean re-install and still won't connect. It is very frustrating. Someone please provide assistance. Thanks in advance.

Here are the logs from my failed connection attempt:

I 2020.12.02 04:42:39 - Session starting.
I 2020.12.02 04:42:39 - Checking authorization ...
. 2020.12.02 04:42:40 - IPv6 disabled with packet filtering.
! 2020.12.02 04:42:40 - Connecting to Bootes (United States of America, Phoenix, Arizona)
. 2020.12.02 04:42:40 - OpenVPN > OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
. 2020.12.02 04:42:40 - OpenVPN > Windows version 10.0 (Windows 10 or greater) 64bit
. 2020.12.02 04:42:40 - OpenVPN > library versions: OpenSSL 1.1.1h  22 Sep 2020, LZO 2.10
. 2020.12.02 04:42:40 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
. 2020.12.02 04:42:40 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
. 2020.12.02 04:42:40 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
. 2020.12.02 04:42:40 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
. 2020.12.02 04:42:40 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]193.37.254.6:2018
. 2020.12.02 04:42:40 - OpenVPN > Socket Buffers: R=[65536->524288] S=[65536->524288]
. 2020.12.02 04:42:40 - OpenVPN > UDP link local: (not bound)
. 2020.12.02 04:42:40 - OpenVPN > UDP link remote: [AF_INET]193.37.254.6:2018
. 2020.12.02 04:42:40 - OpenVPN > TLS: Initial packet from [AF_INET]193.37.254.6:2018, sid=87415253 00b5af41
. 2020.12.02 04:42:40 - OpenVPN > VERIFY KU OK
. 2020.12.02 04:42:40 - OpenVPN > Validating certificate extended key usage
. 2020.12.02 04:42:40 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2020.12.02 04:42:40 - OpenVPN > VERIFY EKU OK
. 2020.12.02 04:42:40 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Bootes, emailAddress=info@airvpn.org
. 2020.12.02 04:42:40 - OpenVPN > Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 4096 bit RSA
. 2020.12.02 04:42:40 - OpenVPN > [Bootes] Peer Connection Initiated with [AF_INET]193.37.254.6:2018
. 2020.12.02 04:42:41 - OpenVPN > SENT CONTROL [Bootes]: 'PUSH_REQUEST' (status=1)
. 2020.12.02 04:42:41 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.26.154.1,dhcp-option DNS6 fde6:7a:7d20:169a::1,tun-ipv6,route-gateway 10.26.154.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:169a::100f/64 fde6:7a:7d20:169a::1,ifconfig 10.26.154.17 255.255.255.0,peer-id 2,cipher AES-256-GCM'
. 2020.12.02 04:42:41 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp'
. 2020.12.02 04:42:41 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS6 fde6:7a:7d20:169a::1'
. 2020.12.02 04:42:41 - OpenVPN > Pushed option removed by filter: 'tun-ipv6'
. 2020.12.02 04:42:41 - OpenVPN > Pushed option removed by filter: 'ifconfig-ipv6 fde6:7a:7d20:169a::100f/64 fde6:7a:7d20:169a::1'
. 2020.12.02 04:42:41 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2020.12.02 04:42:41 - OpenVPN > OPTIONS IMPORT: compression parms modified
. 2020.12.02 04:42:41 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2020.12.02 04:42:41 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2020.12.02 04:42:41 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2020.12.02 04:42:41 - OpenVPN > OPTIONS IMPORT: peer-id set
. 2020.12.02 04:42:41 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625
. 2020.12.02 04:42:41 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified
. 2020.12.02 04:42:41 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM'
. 2020.12.02 04:42:41 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2020.12.02 04:42:41 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2020.12.02 04:42:41 - OpenVPN > interactive service msg_channel=0
. 2020.12.02 04:42:41 - OpenVPN > ROUTE_GATEWAY 10.0.0.1/255.255.255.0 I=6 HWADDR=ec:e2:fd:80:96:99
. 2020.12.02 04:42:41 - OpenVPN > open_tun
. 2020.12.02 04:42:41 - OpenVPN > wintun device [Local Area Connection] opened
. 2020.12.02 04:42:42 - OpenVPN > NETSH: C:\Windows\system32\netsh.exe interface ip set address 9 static 10.26.154.17 255.255.255.0
. 2020.12.02 04:42:43 - OpenVPN > NETSH: C:\Windows\system32\netsh.exe interface ip delete dns 9 all
E 2020.12.02 04:42:43 - OpenVPN > ERROR: netsh command failed: returned error code 1
. 2020.12.02 04:42:48 - OpenVPN > NETSH: C:\Windows\system32\netsh.exe interface ip delete dns 9 all
E 2020.12.02 04:42:48 - OpenVPN > ERROR: netsh command failed: returned error code 1
. 2020.12.02 04:42:52 - OpenVPN > NETSH: command failed
. 2020.12.02 04:42:52 - OpenVPN > Exiting due to fatal error
! 2020.12.02 04:42:52 - Disconnecting
. 2020.12.02 04:42:52 - Connection terminated.
. 2020.12.02 04:42:52 - IPv6 restored with packet filtering.
I 2020.12.02 04:42:53 - Cancel requested.
! 2020.12.02 04:42:53 - Session terminated.

 

Edited ... by OpenSourcerer
Apply LOG format to logs

[OpenSourcerer 1435]

Try to connect again but upload/paste a support file instead (Logs > lifebelt icon).

[bluesjunior 43]

I had the same problem when I installed v2.19.6 I ended up uninstalling the existing Wintun install as well as Eddie and Openwent for a clean install of v2.19.6. I also used CCleaner to delete left over registry files. Restarted my PC and it worked straight away. My OS is Windows 10 Home v 20H2 up to date.

[blockchain420 0]

I did some research on the Internet and discovered WinTun adapter that DHCP is disabled for that adapter. Please read a copy/paste from Openvpn.net: https://community.openvpn.net/openvpn/ticket/875
 

ERROR: netsh command failed: returned error code 1

 

I haven't seen this bug before. Connection is being established, but in the end I'm getting:

Thu Apr 13 15:23:43 2017 NETSH: C:\Windows\system32\netsh.exe interface ip set address LAN-Verbindung 3 dhcp
Thu Apr 13 15:23:43 2017 ERROR: netsh command failed: returned error code 1

Three times ("LAN-Verbindung 3" meaning "LAN Connection 3" in english). Whole log attached.

 

You have a knack for finding interesting (and well-hidden) spider-webs... :-)

This code is run if OpenVPN notices that the tap adapter is not set to use DHCP, to re-enable DHCP (and then poke the to-be-set IP address into the TAP adapter, so it can play DHCP server).

Without checking very closely, I assume that openvpn is run with interactive service, so openvpn.exe does not have the necessary privileges to do what it tries, and thus fails. (I dimly remember that we've had this before in another ticket, but can't remember the details... @selva, can you?)

 

Yes, this has to be due to dhcp disabled in the adapter and openvpn started using interactive service. As @cron2 said, it did come up in the past: See Trac #823

As suggested there we better implement dhcp mode setting through interactive service. Though not relevant here, also mutate --ip-win32 netsh to ipapi so that a run as admin with that option will not disable dhcp.

As a quick fix, set the adapter to use dhcp and reconnect:
netsh.exe int ip set addr "LAN-Verbindung 3" dhcp from an elevated cmd prompt will do it.

Thanks.

 

[blockchain420 0]

On 12/3/2020 at 3:15 AM, OpenSourcerer said:

Try to connect again but upload/paste a support file instead (Logs > lifebelt icon).

Here's another log file in the form of a text file for my failed connection attempt.

I tried the following command "netsh.exe int ip set addr "Local Area Connection" dhcp" to set my WinTun adapter to enable DHCP and it still doesn't work. Eddie is trying to assign the WinTun adapter a static IP address in "OpenVPN > NETSH: C:\Windows\system32\netsh.exe interface ip set address 18 static 10.17.26.83 255.255.255.0" instead of using DHCP. Also when I disconnect, the Wintun adapter IP settings are retained instead of resetting them to the default settings before connecting.

Thanks in advance.

Eddie_20201211_215928.txt

[OpenSourcerer 1435]

C'mon, it's not a support file! Logs > lifebelt icon. You are repeatedly only copying the log output.
Also, connect and let it fail! Don't cancel the connection attempt when clicking on that lifebelt icon. Thank you.

[blockchain420 0]

4 hours ago, OpenSourcerer said:

C'mon, it's not a support file! Logs > lifebelt icon. You are repeatedly only copying the log output.
Also, connect and let it fail! Don't cancel the connection attempt when clicking on that lifebelt icon. Thank you.

Sorry, I didn't understand what you meant by a support file. I am new to posting here.

When you say support file, you mean click on the red circle icon under Logs options on Eddie, correct?

Sorry for the confusion.

[blockchain420 0]

5 hours ago, OpenSourcerer said:

C'mon, it's not a support file! Logs > lifebelt icon. You are repeatedly only copying the log output.
Also, connect and let it fail! Don't cancel the connection attempt when clicking on that lifebelt icon. Thank you.

Let's try this again. Hopefully this is the right file you are looking for.

Support file.txt

[OpenSourcerer 1435]

23 minutes ago, blockchain420 said:

Let's try this again. Hopefully this is the right file you are looking for.

Yes, perfect. Thanks.

The error is thrown when OpenVPN uses netsh to delete something DNS-related, something you've explicitly configured. Let's first see if it's truly settings-related. Go to C:\Users\Administrator\AppData\Local\Eddie\ and rename the default.profile to something.else. The relaunch Eddie and don't change any settings, just try to connect. Regardless of the result, report back with another support file.

[blockchain420 0]

3 hours ago, OpenSourcerer said:

Yes, perfect. Thanks.

The error is thrown when OpenVPN uses netsh to delete something DNS-related, something you've explicitly configured. Let's first see if it's truly settings-related. Go to C:\Users\Administrator\AppData\Local\Eddie\ and rename the default.profile to something.else. The relaunch Eddie and don't change any settings, just try to connect. Regardless of the result, report back with another support file.

Ok. I did what you asked me to do in deleting the config file and creating a new one without changing the settings and still get the dreaded ERROR: netsh command failed: returned error code 1 message. 

I think the error might been caused because OpenVPN is importing certain options before attempting a connection:  Example OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified.

Here's a copy of the new support file you requested.

Thanks in advance.

New Support Log.txt

[OpenSourcerer 1435]

10 hours ago, blockchain420 said:

Ok. I did what you asked me to do in deleting the config file and creating a new one without changing the settings and still get the dreaded ERROR: netsh command failed: returned error code 1 message. 

Really, you did what I asked? Quite the contrary, I'd say:

network.ipv6.mode: block
windows.disable_driver_upgrade: True
windows.tap_up: False
windows.wintun: True

I thought we agreed on not changing ANY settings. And yes, this means letting Eddie upgrade and use TAP, and also route IPv6. Using wintun could just be the problem, you know.
We must observe the default behavior of Eddie to rule out any issues introduced by the experimental features Eddie 2.19.x offers. 2.18.9 worked, after all! I advise you to follow the instructions to the letter. Your dishes will never get better if you insist on putting mustard into it despite the recipe not mentioning it, just because you like mustard so much.

[blockchain420 0]

On 12/13/2020 at 7:27 AM, OpenSourcerer said:

Really, you did what I asked? Quite the contrary, I'd say:

network.ipv6.mode: block
windows.disable_driver_upgrade: True
windows.tap_up: False
windows.wintun: True

I thought we agreed on not changing ANY settings. And yes, this means letting Eddie upgrade and use TAP, and also route IPv6. Using wintun could just be the problem, you know.
We must observe the default behavior of Eddie to rule out any issues introduced by the experimental features Eddie 2.19.x offers. 2.18.9 worked, after all! I advise you to follow the instructions to the letter. Your dishes will never get better if you insist on putting mustard into it despite the recipe not mentioning it, just because you like mustard so much.

I disabled the Tap Adapter upgrade because I have issues when using the newer one is upgraded instead of the one that works for me in Tap Adapter 9.0.0.9. Eddie 2.18.9 works well with Tap Adapter 9.0.0.9. The only reason I would want to upgrade and use WinTun is to increase my connection speeds. I only get 140 Mb/s of a possible 250 Mb/s when connected using Tap Adapter.

Thanks for the support but I will continue to use Tap Adapter to connect instead of WinTun. It's not worth the hassle. You can close this thread.

Later.

[OpenSourcerer 1435]

12 hours ago, blockchain420 said:

Thanks for the support but I will continue to use Tap Adapter to connect instead of WinTun. It's not worth the hassle.

No, sometimes it's not. Neither Wintun nor Eddie 2.19.x are released, so issues are to be expected.