Opened 11 years ago

Closed 10 years ago

Last modified 6 years ago

#316 closed Bug / Defect (fixed)

Windows 8 issue: TUN/TAP adapter does not start

Reported by: Samuli Seppänen Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.3.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: tap windows
Cc: Heiko Hund

Description

Original report sent by Richard Weinberg to openvpn-devel.

"I'm facing a strange issue on Windows 8. It happens very often that the TUN/TAP adapter is not started and OpenVPN is unable to setup IPs and routes.

openvpn.exe writes over and over "Waiting for TUN/TAP interface to come up...". After ~30 seconds it continues without a proper network configuration. This is very nasty because from the users point of few it looks like the tunnel is up but nothing works.

On the net I found some halve baked "solutions" for that issue. Like disabling the Windows Firewall, disabling IPv6, setting the DHCP-Client service to autostart, and so on. But nothing helped so far nor really explained the root issue.

Please see the attached log file. (It is sightly censored to hide my customers name and public IP.)

I ran also Wireshark on my TUN/TAP device while connecting. When facing the issue zero packets were captured. So, it is not really a networking issue between server and client.

Change History (42)

comment:1 Changed 11 years ago by Samuli Seppänen

Discussed this issue in a community IRC meeting:

  • derRichard has reproduced this issue on two separate physical Win8 computers
  • raidz has had the same issue on some physical Windows 8 computers, but never on virtual ones
  • derRichard will try to reproduce this issue on a VirtualBox VMs
  • mattock will build a debug version of the TAP-Windows driver (makes sense in any case)
    • The problem might output something to the logs
    • If route-method netsh is also not working, it seems to point away from DHCP as being the culprit

Things that can be tried:

  • try --route-method netsh
  • try the "manual" method and use those same commands from an elevated prompt to try and pin down if it's a syntax issue, or something specific to openvpn
  • try --route-delay
    • derRichard reported this did not help
  • try --tap-sleep
    • derRichard will test if this help
Last edited 11 years ago by Samuli Seppänen (previous) (diff)

comment:2 Changed 11 years ago by Samuli Seppänen

Raidz has an extra laptop with this issue. He will put it to OpenVPN Tech LAN. Swg0101 will try to reproduce this on various Windows 8 and 8.1 VMs and on raidz's laptop.

Last edited 11 years ago by Samuli Seppänen (previous) (diff)

comment:3 Changed 11 years ago by Samuli Seppänen

Snippets from IRC logs:

pekster: I got Win8 "Release Preview" eval copy build 8400 to work with
        --ip-win32 netsh
pekster: It gets an address fine (in tun mode, not other windows options
         besides --ip-win32)

The logs related to this connection here:


    Thu Aug 08 12:13:39 2013 us=937191 PUSH: Received control message: 'PUSH_REPLY,t
    opology subnet,ping 10,ping-restart 60,ifconfig 10.123.123.100 255.255.255.0'
    Thu Aug 08 12:13:39 2013 us=937191 OPTIONS IMPORT: timers and/or timeouts modifi
    ed
    Thu Aug 08 12:13:39 2013 us=937191 OPTIONS IMPORT: --ifconfig/up options modifie
    d
    Thu Aug 08 12:13:39 2013 us=937191 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv
    6_setup=0
    Thu Aug 08 12:13:40 2013 us=967615 NETSH: C:\Windows\system32\netsh.exe interfac
    e ip set address Local Area Connection static 10.123.123.100 255.255.255.0
    Thu Aug 08 12:13:43 2013 us=452008 NETSH: C:\Windows\system32\netsh.exe interfac
    e ip delete dns Local Area Connection all
    Thu Aug 08 12:13:45 2013 us=61372 NETSH: C:\Windows\system32\netsh.exe interface
     ip delete wins Local Area Connection all
    Thu Aug 08 12:13:45 2013 us=373857 open_tun, tt->ipv6=0
    Thu Aug 08 12:13:45 2013 us=373857 TAP-WIN32 device [Local Area Connection] open
    ed: \\.\Global\{005EC8A6-B425-4600-9875-FF88A49254CF}.tap
    Thu Aug 08 12:13:45 2013 us=389494 TAP-Windows Driver Version 9.9
    Thu Aug 08 12:13:45 2013 us=405109 TAP-Windows MTU=1500
    Thu Aug 08 12:13:45 2013 us=405109 Set TAP-Windows TUN subnet mode network/local
    /netmask = 10.123.123.0/10.123.123.100/255.255.255.0 [SUCCEEDED]
    Thu Aug 08 12:13:45 2013 us=405109 Successful ARP Flush on interface [16] {005EC
    8A6-B425-4600-9875-FF88A49254CF}
    Thu Aug 08 12:13:50 2013 us=108243 TEST ROUTES: 0/0 succeeded len=0 ret=1 a=0 u/
    d=up
    Thu Aug 08 12:13:50 2013 us=108243 Initialization Sequence Completed

According to netsh_ifconfig_options() in tun.c netsh should handle DNS and other settings.

Last edited 11 years ago by Samuli Seppänen (previous) (diff)

comment:4 Changed 11 years ago by Christian Rank

We have also some users who upgraded to Win 8 complaining on OpenVPN connections to our campus no longer working. I can reproduce the issue on a Win 8 Pro x64 laptop:

Fri Aug 23 12:06:08 2013 us=753756 OpenVPN 2.3.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013
...
Fri Aug 23 12:06:15 2013 us=4044 TAP-WIN32 device [Local Area Connection] opened: \\.\Global\{0407F437-B9C0-4962-864B-80228D6CD9B1}.tap
Fri Aug 23 12:06:15 2013 us=4044 TAP-Windows Driver Version 9.9
Fri Aug 23 12:06:15 2013 us=4044 TAP-Windows MTU=1500
Fri Aug 23 12:06:15 2013 us=4044 Set TAP-Windows TUN subnet mode network/local/netmask = 132.231.178.128/132.231.178.132/255.255.255.192 [SUCCEEDED]
Fri Aug 23 12:06:15 2013 us=4044 Notified TAP-Windows driver to set a DHCP IP/netmask of 132.231.178.132/255.255.255.192 on interface {0407F437-B9C0-4962-864B-80228D6CD9B1} [DHCP-serv: 132.231.178.190, lease-time: 31536000]
Fri Aug 23 12:06:15 2013 us=4044 DHCP option string: 0f0d756e 692d7061 73736175 2e646506 0884e733 0484e701 18
Fri Aug 23 12:06:15 2013 us=4044 Successful ARP Flush on interface [20] {0407F437-B9C0-4962-864B-80228D6CD9B1}
Fri Aug 23 12:06:20 2013 us=35578 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Fri Aug 23 12:06:20 2013 us=35578 Route: Waiting for TUN/TAP interface to come up...
...
Fri Aug 23 12:06:50 2013 us=521308 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )

This error is non-deterministic, since approx. 80% of the connection attempts succeed without errors. Could this be a race condition or timing problem during setup of the TAP adapter?

BTW, I've tested the "--tap-sleep" workaround with no success. Deactivating the "Network List Service" (which causes every now and then trouble with network connectivity) did not help, too.

I think this problem will get more prominent with the increasing number of Win 8 installations ...

comment:5 Changed 11 years ago by novaflash

Note: the below I believe is valid for the open source client as well since Connect Client uses the same process and it is the openvpn process that reports the error.

I have had the dubious fortune of having a customer with multiple laptops with Windows 8 that were reporting problems with OpenVPN Connect Client. In the openvpn connection log this shows up:

Mon Aug 26 08:57:42 2013 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Mon Aug 26 08:57:42 2013 Route: Waiting for TUN/TAP interface to come up...


Soooo when I dug a little deeper I discovered that while the internet connection was up and running, I could disconnect/reconnect just fine and no errors showed up. However, with Connect Client attempting to connect while wifi was down, and the wifi then set to connect, it fails in the manner that Connect Client will CLAIM that it is connected and everything is fine, and it will put the routes in place, but the traffic won't go.

In the meantime, in my scripts for my customers that were affected by this problem on their Windows 8 laptops I have implemented a simple ping test + ovpncli disconnect/connect command. And that resolves it when they need to access resources on their VPN. Obviously it would be better if this could be resolved in Connect Client however.

I am seeing this in the log file:

Mon Aug 26 08:57:37 2013 Notified TAP-Win32 driver to set a DHCP IP/netmask of 172.47.2.205/255.255.255.0 on interface {E42A1D1B-3CE2-4263-864D-F5DCEA5976AF} [DHCP-serv: 172.47.2.1, lease-time: 31536000]
Mon Aug 26 08:57:37 2013 Successful ARP Flush on interface [19] {E42A1D1B-3CE2-4263-864D-F5DCEA5976AF}
Mon Aug 26 08:57:37 2013 NOTE: Release of DHCP-assigned IP address lease on TAP-Win32 adapter failed: Het systeem kan het opgegeven bestand niet vinden.   (code=2)
Mon Aug 26 08:57:37 2013 WARNING: Failed to renew DHCP IP address lease on TAP-Win32 adapter: Het systeem kan het opgegeven bestand niet vinden.   (code=2)
Mon Aug 26 08:57:42 2013 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Mon Aug 26 08:57:42 2013 Route: Waiting for TUN/TAP interface to come up...
Mon Aug 26 08:57:45 2013 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Mon Aug 26 08:57:45 2013 Route: Waiting for TUN/TAP interface to come up...
etc...

The line "Het systeem kan het opgegeven bestand niet vinden." means "The system cannot find the specified file". Which is a little odd. It's almost (intuitive leap here) like the DHCP process of the wifi adapter interferes with the DHCP process of the TUN/TAP adapter. As mentioned, once the wifi is up and running, there is no problem. I can disconnect/reconnect over and over and I get a 100% success rate. But _while_ the OpenVPN process attempts to establish, and the wifi adapter is doing its 'connecting to blabla network' phase, things go south.

Hopefully this will give someone some idea as to where to look and how to reproduce.

Last edited 11 years ago by novaflash (previous) (diff)

comment:6 Changed 11 years ago by egroeper

Just wanted to link to my bug report #289, that wasn't linked to this issue, yet.
I was doing my tests with a VirtualBox VM.

I can try to reproduce the issue with current OpenVPN 2.3.2.

comment:7 in reply to:  6 Changed 11 years ago by egroeper

Replying to egroeper:

I can try to reproduce the issue with current OpenVPN 2.3.2.

I succesfully reproduced my tests with 2.3.2. Nothing changed.

comment:8 Changed 11 years ago by rw

If you deactivate and activate the TUNTAP adapter in the control panel it *seems* to help.
Did have not enough time to verify...

comment:9 in reply to:  8 Changed 11 years ago by rw

Replying to rw:

If you deactivate and activate the TUNTAP adapter in the control panel it *seems* to help.
Did have not enough time to verify...

This really seems to work.
Has OpenVPN a knob to execute a script *before* it touches the TUN-Adapter?
--up is too late and there is no --pre-up.

Thanks,
richard

comment:10 Changed 11 years ago by Christian Rank

I noticed that one of my Win8 installations having this problem had multiple TAP adapters in the system, although only one shows up in GUI (Network and Sharing Center).
"c:\Program Files\TAP-Windows\bin\devcon.exe" findall tap0901
says "2 matching device(s) found.". Maybe these multiple TAP devices are the cause of the problem?

Could the others with this issue please check the output of the devcon command and post the results here? Perhaps this would help in finding the root cause of the issue.

Thanks a lot,
Chris

comment:11 in reply to:  10 Changed 11 years ago by egroeper

Replying to rw:

Replying to rw:

If you deactivate and activate the TUNTAP adapter in the control panel it *seems* to help.
Did have not enough time to verify...

This really seems to work.
Has OpenVPN a knob to execute a script *before* it touches the TUN-Adapter?
--up is too late and there is no --pre-up.

--up enabletap.cmd
with enabletap.cmd:

C:\Windows\System32\netsh interface set interface %1 Enabled

does a pretty decent job here. But in my case simply opening the control panel resolves the issue (see #289).

Replying to c_rank:

Could the others with this issue please check the output of the devcon command and post the results here? Perhaps this would help in finding the root cause of the issue.

"1 matching device(s) found." when having the issue.

comment:12 Changed 11 years ago by Christian Rank

During the last week, I had two Windows 7 laptops on my desk which are hit by the same problem.
I suspect some kind of race condition occuring in the TUN/TAP driver.

comment:13 Changed 11 years ago by paulsmith

I've been searching google for hours as to why all of the sudden my Windows 8 64-bit VPN client stopped working (as in it no longer gets an IP Address but shows connected 'green light'). My other client is on a windows 7 64-bit box and works perfect everytime.

So far i've encountered this issue twice on Windows 8. The first time is when I initially setup the client on windows 8 64-bit (and through misconfiguration) was assigned the same IP address for 2 different clients, so I thought somehow the server had a dhcp lease that it wouldn't let go and the client was trying to use it, causing an IP address conflict. After several days, I tried it again and it just worked and has worked for months until recently when I saw the IP address conflict again and I made sure no other clients are/were connecting, but now it just loops the 'Route: Waiting for TUN/TAP interface to come up...'.

I've restarted the openvpn server/daemon, deleted and re-created the TAP interface/driver. Nothing seems to work at the moment.

Windows 8 Enterprise | 6.2.9200
OpenVPN | 2.3.2.0
OpenVPN-GUI | 5.0.0.0
tap0901.sys | 9.0.0.9 (Product version 9.9.2 9/9)

comment:14 in reply to:  13 ; Changed 11 years ago by Christian Rank

Replying to paulsmith:

So far i've encountered this issue twice on Windows 8. The first time is when I initially setup the client on windows 8 64-bit (and through misconfiguration) was assigned the same IP address for 2 different clients, so I thought somehow the server had a dhcp lease that it wouldn't let go and the client was trying to use it, causing an IP address conflict. After several days, I tried it again and it just worked and has worked for months until recently when I saw the IP address conflict again and I made sure no other clients are/were connecting, but now it just loops the 'Route: Waiting for TUN/TAP interface to come up...'.

It seems very interesting that the problem could be triggered by an IP address conflict. How did you notice the address conflict? AFAIK, no warning is logged by OpenVPN ...

comment:15 in reply to:  14 Changed 11 years ago by paulsmith

Replying to c_rank:

It seems very interesting that the problem could be triggered by an IP address conflict. How did you notice the address conflict? AFAIK, no warning is logged by OpenVPN ...

I noticed the conflict when I had 2 different clients connect and was given the same IP address (as being reported from the Openvpn-gui in Windows, not sure if one of them was actually connected). It makes me wonder how OpenVPN is managing the DHCP lease on the server.

I tried again on the problematic Windows 8 machine again today and it worked (without performing any changes to the server or client), however after I disconnected and tried to reconnect I get the same issue, i'm beginning to think it's a race condition as mentioned earlier.

comment:16 Changed 11 years ago by hdagelic

It doesn't work on my Windows 8 test virtual machine either, with 2.3.2. It says "waiting for tun/tap interface to come up..." for around 30 seconds and then connects, and TAP interface doesn't have a gateway set. Routes look the same (route print) but under "interface" there is an IP of the external adapter, not VPN IP. (Edit: they are not the same, i'll post the whole route print)

When it doesn't work:
Network Destination - Netmask - Gateway - Interface - Metric
0.0.0.0 - 128.0.0.0 - 10.128.0.1 - 192.168.168.15 - 11
....

When it does work:
Network Destination - Netmask - Gateway - Interface - Metric
0.0.0.0 - 128.0.0.0 - 10.128.0.1 - 10.129.2.4 - 30
....

(10.x.x.x is VPN, 192.168.x.x is external)

I found a youtube video that just opening control panel -> network and sharing center -> change adapter settings helps, and it does. After this openvpn connects normally with a gateway set and no waiting. Just setting "Network Connections" service to an automatic start doesn't help.

Last edited 11 years ago by hdagelic (previous) (diff)

comment:17 Changed 11 years ago by hdagelic

Here is the route print in both cases, if you'd like to, I can give you my Virtualbox machine to test it, just tell me where to send you the link.

Doesn't work:

C:\Users\hdagelic>route print
===========================================================================
Interface List
 15...00 ff 1a b0 d3 2b ......TAP-Windows Adapter V9
 12...08 00 27 4f cf 35 ......Intel(R) PRO/1000 MT Desktop Adapter
  1...........................Software Loopback Interface 1
 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.168.2   192.168.168.15     10
          0.0.0.0        128.0.0.0       10.128.0.1   192.168.168.15     11
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
        128.0.0.0        128.0.0.0       10.128.0.1   192.168.168.15     11
     161.53.129.5  255.255.255.255    192.168.168.2   192.168.168.15     10
    192.168.168.0    255.255.255.0         On-link    192.168.168.15    266
    192.168.168.2  255.255.255.255    192.168.168.2   192.168.168.15     10
    192.168.168.3  255.255.255.255    192.168.168.2   192.168.168.15     10
   192.168.168.15  255.255.255.255         On-link    192.168.168.15    266
  192.168.168.255  255.255.255.255         On-link    192.168.168.15    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link    192.168.168.15    266
        224.0.0.0        248.0.0.0       10.129.2.4   192.168.168.15     11
        232.0.0.0        248.0.0.0       10.129.2.4   192.168.168.15     11
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link    192.168.168.15    266
===========================================================================


Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
 14    306 ::/0                     On-link
  1    306 ::1/128                  On-link
 14    306 2001::/32                On-link
 14    306 2001:0:9d38:6abd:2871:7dc:3f57:57f0/128
                                    On-link
 12    266 fe80::/64                On-link
 14    306 fe80::/64                On-link
 12    266 fe80::15ec:9a86:4364:da2e/128
                                    On-link
 14    306 fe80::2871:7dc:3f57:57f0/128
                                    On-link
  1    306 ff00::/8                 On-link
 14    306 ff00::/8                 On-link
 12    266 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Works:

C:\Users\hdagelic>route print
===========================================================================
Interface List
 15...00 ff 1a b0 d3 2b ......TAP-Windows Adapter V9
 12...08 00 27 4f cf 35 ......Intel(R) PRO/1000 MT Desktop Adapter
  1...........................Software Loopback Interface 1
 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 16...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.168.2   192.168.168.15     10
          0.0.0.0        128.0.0.0       10.128.0.1       10.129.2.4     30
       10.128.0.0      255.224.0.0         On-link        10.129.2.4    286
       10.129.2.4  255.255.255.255         On-link        10.129.2.4    286
   10.159.255.255  255.255.255.255         On-link        10.129.2.4    286
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
        128.0.0.0        128.0.0.0       10.128.0.1       10.129.2.4     30
     161.53.129.5  255.255.255.255    192.168.168.2   192.168.168.15     10
    192.168.168.0    255.255.255.0         On-link    192.168.168.15    266
    192.168.168.2  255.255.255.255    192.168.168.2   192.168.168.15     10
    192.168.168.3  255.255.255.255    192.168.168.2   192.168.168.15     10
   192.168.168.15  255.255.255.255         On-link    192.168.168.15    266
  192.168.168.255  255.255.255.255         On-link    192.168.168.15    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link        10.129.2.4    286
        224.0.0.0        240.0.0.0         On-link    192.168.168.15    266
        224.0.0.0        248.0.0.0         On-link        10.129.2.4     30
        232.0.0.0        248.0.0.0         On-link        10.129.2.4     30
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link        10.129.2.4    286
  255.255.255.255  255.255.255.255         On-link    192.168.168.15    266
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
 14    306 ::/0                     On-link
  1    306 ::1/128                  On-link
 14    306 2001::/32                On-link
 14    306 2001:0:5ef5:79fb:106d:2738:f57e:fdfb/128
                                    On-link
 15    286 fe80::/64                On-link
 12    266 fe80::/64                On-link
 14    306 fe80::/64                On-link
 14    306 fe80::106d:2738:f57e:fdfb/128
                                    On-link
 12    266 fe80::15ec:9a86:4364:da2e/128
                                    On-link
 15    286 fe80::218a:a1ed:bf0a:d34/128
                                    On-link
  1    306 ff00::/8                 On-link
 14    306 ff00::/8                 On-link
 15    286 ff00::/8                 On-link
 12    266 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

comment:18 in reply to:  16 ; Changed 11 years ago by egroeper

Replying to hdagelic:

I found a youtube video that just opening control panel -> network and sharing center -> change adapter settings helps, and it does. After this openvpn connects normally with a gateway set and no waiting. Just setting "Network Connections" service to an automatic start doesn't help.

Simply opening Network Adapter Applet (Network an Sharing Center) should be enough. See #289.
I'm pretty sure my workaround enabletap.cmd would work in your case.

comment:19 in reply to:  18 Changed 11 years ago by hdagelic

Yes it does, opening Network an Sharing Center makes it work every time. It looks to me as a similar bug as #289, I also get "Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv)".

I tried playing with nesh as in #289, it worked a couple of times to make a redneck fix, and then it didn't, but my netsh always says "this network interface does not exist" (it does).

Replying to egroeper:

Replying to hdagelic:

I found a youtube video that just opening control panel -> network and sharing center -> change adapter settings helps, and it does. After this openvpn connects normally with a gateway set and no waiting. Just setting "Network Connections" service to an automatic start doesn't help.

Simply opening Network Adapter Applet (Network an Sharing Center) should be enough. See #289.
I'm pretty sure my workaround enabletap.cmd would work in your case.

Version 2, edited 11 years ago by hdagelic (previous) (next) (diff)

comment:20 Changed 11 years ago by hdagelic

I tried to diff running services 5 times using net run before and after opening the applet and there are no differences in 3 cases, and in other 2 they are accidental. I tested if OpenVPN worked in all cases - before opening the applet (it didn't) and after (it did).

I tried (as administrator):

C:\Windows\System32\netsh interface set interface %1 Enabled

but I have some funny netsh that prints an error ("this interface does not exist" or "an interface with this name is not registered with the router). I guess that I'll launch network sharing center from the shortcut :)

Last edited 11 years ago by hdagelic (previous) (diff)

comment:21 Changed 11 years ago by Trader121

Hi I had the same issue yesterday but I solved it:

In my case, the reason was IPV6. It seems that the OPENVPN Client was confused that IPV4 and IPV6 was active and that created the issue

Go to your Standard Ethernet or WLAN Adapter (not the TAP Connection, the Standard Connection) and uncheck Internet Protocol Version 6 and it will most likely work

comment:22 Changed 11 years ago by Trader121

Also, if you look at the route print screenshot in the above post, under "Active Routes" there are IPV6 adresses. That's probabably the reason why it doesn't work. Try it again without IPV6

comment:23 in reply to:  21 Changed 11 years ago by hdagelic

Thanks, but in my case there was no difference, after restarting it doesn't work.

comment:24 Changed 11 years ago by Gert Döring

Cc: Heiko Hund added

2.3 handles IPv6 fine, at least on XP and Win7, so that shouldn't be the reason. Most likely due to removing IPv6 you just triggered the magic "something" that makes it work again.

So we still do not know for sure what triggers this and how to get rid of it? novaflash, any clues from your side?

(2.4 should have a magic solution with the interactive service using proper windows APIs to handle that, but that won't help today, nor will it be imported into 2.3)

comment:25 Changed 11 years ago by Plasmodino

I had this problem for a long time with the tun/tap adapter not starting up, i finally solved it by removing "route-gateway 172.16.0.1" (with 172.16.0.1 being the servers IP) from my server configuration.

comment:26 Changed 11 years ago by peter.vanpoucke

I solved this problem by restarting my DHCP client service...

comment:27 Changed 10 years ago by heperez

Well. I have a windows 8.1 64 bits.

None of the workaround listed above worked for me except, open the Network and Share center. I don't know why, but opening the Network and share center before proceed to conect makes the Tap driver work.

Neither worked for me execute "netsh interface set interface <name of interface> enabled", nor delltap.bat and addtap, makes any difference. The Tap driver continues down.

The only solution was opening the Network and share center of the control panel. This problem affected me since windows 8 appeared, and with more a more machines running it, the problem is every day, bigger.

comment:28 Changed 10 years ago by leifcr

After testing all options in various combinations, I've found that these options work:

In your openvpn configuration:

 route-method exe
 route-delay 5 120
 tap-sleep 5

In addition, you have to set your Tap Adapter to "always connected"

To do this do the following steps:

  1. Go into device manager
  2. Find your Tap Adapter
  3. Right click
  4. Select "Propterties"
  5. Select "Advanced Media Status"
  6. Set it to "Always Connected"
  7. Click Ok
  8. Restart computer.

I've successfully used this on both Windows Server 2012 R2 and Windows 8.1

It is easier to reproduce the bug on Windows Server 2012 R2, as it is always occuring there, while on Windows 8.1 it might happen.

comment:29 Changed 10 years ago by rw

Now we have some workarounds, but is there any progress in fixing the driver for real?

Thanks,
richard

comment:30 in reply to:  description Changed 10 years ago by ibraheems

I'm not sure if this is common knowledge at this point but I haven't seen other people mentioning it and none of the above fixes (or other fixes that I could find online) were able to solve this problem for me on Win 8.1 on a Surface Pro 1 Tablet computer.

I have discovered that the TAP Driver for Windows has not yet been compiled/modified for NDIS 6.4 which is the default for Windows 8.1. (http://msdn.microsoft.com/en-us/library/windows/hardware/ff567893%28v=vs.85%29.aspx)

I imagine that the large quantity of bugs for Windows 8.1 networking related issues have to do with this incompatibility.

Whenever somebody with driver programming experience gets a chance, please compile TAP for Windows 8.1/NDIS 6.4 ... We'd love you for it! :D

https://github.com/OpenVPN/tap-windows6
http://msdn.microsoft.com/en-us/library/windows/hardware/dn449734%28v=vs.85%29.aspx

comment:31 Changed 10 years ago by David Sommerseth

Please have a look here:
<http://openvpn.net/index.php/open-source/downloads.html>

openvpn-install-2.3.4-I603-i686.exe and openvpn-install-2.3.4-I603-x86_64.exe should ship with tap-windows6 driver.

comment:32 Changed 10 years ago by ibraheems

I am not going to pretend that I know what I am doing when it comes to driver programming, or programming even as I am not a programmer. At best, I am an admin-scripter for IT... This is just speculation from my part from briefly looking over the code.

*I Believe* that the latest version which is shipped with OpenVPN is compiled for NDIS 6.30 (Windows 8.0 as per the link I provided). 8.1 uses NDIS 6.40 which somewhat changes the data structure which could be causing the TAP failures that I'm dealing with.

Also, after looking at more code, I found the following:

#if defined(NDIS60_MINIPORT)
#  define TAP_NDIS_MAJOR_VERSION    6
#  define TAP_NDIS_MINOR_VERSION    0
#elif defined(NDIS61_MINIPORT)
#  define TAP_NDIS_MAJOR_VERSION    6
#  define TAP_NDIS_MINOR_VERSION    1
#elif defined(NDIS620_MINIPORT)
#  define TAP_NDIS_MAJOR_VERSION    6
#  define TAP_NDIS_MINOR_VERSION    20
#elif defined(NDIS630_MINIPORT)
#  define TAP_NDIS_MAJOR_VERSION    6
#  define TAP_NDIS_MINOR_VERSION    30
#else
#define TAP_NDIS_MAJOR_VERSION      5
#define TAP_NDIS_MINOR_VERSION      0
#endif

If this is how the logic of the program works, then Windows 8.1 is actually getting an NDIS 5 driver implementation because it has NDIS 6.40 which is not being explicitly defined here. As of NDIS 6.20, it seems like compatibility for the older NDIS has been discontinued which could also be the cause of my IT woes with OpenVPN on Windows 8.1.

Please investigate further because I may be on to something here haha :)

Thanks!

comment:33 in reply to:  31 Changed 10 years ago by Samuli Seppänen

Replying to dazo:

Please have a look here:
<http://openvpn.net/index.php/open-source/downloads.html>

openvpn-install-2.3.4-I603-i686.exe and openvpn-install-2.3.4-I603-x86_64.exe should ship with tap-windows6 driver.

Just to clarify this a bit:

  • Installers with build number of I0xx have an NDIS 5 driver
  • Installers with build number of I6xx have an NDIS 6 driver

We do not have any installers which have both NDIS 5 and NDIS 6 installers in the same package. On Windows 8.x you should definitely use the NDIS 6 version.

comment:34 Changed 10 years ago by ibraheems

Ok... I'm going to stop suggesting causes for the problem...

It's 8/21/2014 here using the latest version of OpenVPN server and client on Windows 8.1 x64 Surface Pro 1 Computer with the latest drivers for all hardware devices reporting that the tap driver is not working with the same symptoms as originally posted for this ticket.

The TAP Adapter fails to start properly. I see the client computer authenticated with the server on the server logs, but then cannot perform any network operations. After it turns green (after waiting for about 30 seconds to a minute with the TEST ROUTES message continually repeated) I still cannot perform any network operations. After a short while (probably about 2 minutes for the ping timeout to take effect), the connection continually re initiates the handshake and never turns green again. Also, if I try to close the connection (established either through GUI, cmd console window, or Windows Service), it simply refuses to close. The only way to stop it is to reboot the pc.

The computer wirelessly connects to the internet. I have tried using both TAP TCP and UDP to no effect. I have also tried modifying the client config and driver configuration as mentioned above. I have also tried disabling windows firewall and running everything as Administrator. My setup includes both certificate and HMAC authentication. My setup works fine for the other computers connected using both Windows 7 x86 and x64 and the latest version of the OpenVPN client. None of the suggestions posted here work to fix the issue for me on Windows 8.1.

comment:35 Changed 10 years ago by wadew

This is my naive fix under Windows 8.1 Enterprise:

I downloaded OpenVPN from http://swupdate.openvpn.org/community/releases/openvpn-install-2.3.2-I006-x86_64.exe, removed the virtual ethernet adapter (Tap-windows), and installed the standalone driver installer located at http://swupdate.openvpn.org/community/releases/tap-windows-9.9.2_3.exe

After that it seemed to work fine!

Important Note: When I run the OpenVPN client, I right click on it and select "Run As Administrator."

Last edited 10 years ago by wadew (previous) (diff)

comment:36 Changed 10 years ago by michal.sokolowski

I've tested the newest versions few days ago:
openvpn-install-2.3.4-I603
openvpn-install-2.3.4-I003

with:
tap-windows-9.21.0.exe
tap-windows-9.9.2_3.exe

It's still unresolved. Only thing what helped me was solution provided by leifcr.
Be aware that in such configuration TAP adapter in Windows 8 will be always on, wrongly if tunnel is not working. I've tested any other workaround. The other which is helpful is to open the Network and Share center in Windows. It helps every time.

I've tested it in Windows 8 and 8.1, more than ten installations. For me it was failing everytime after system reboot. (when OS is busy most likely)

I have seen this problem at least from Openvpn 2.3.0 version.

For everyone who wants to do it automatically (to open Network and Share Center), u can:

add for config file (on client side):

script-security 2
up "sharing-center.bat"

Contents of sharing-center.bat:

control.exe /name Microsoft.NetworkAndSharingCenter
EXIT /B 0
Last edited 10 years ago by michal.sokolowski (previous) (diff)

comment:37 Changed 10 years ago by alurian

Haven't done a thorough testing, but this seems to be working now.

Steps:
Installed openvpn-install-2.3.4-I603x86_64
Installed tap-windows-9.9.2_3.exe
Copied config from my old laptop
Profit

Connection seems to be cutting on and off properly and Samba, ssh, etc is running across it successfully

Just make sure to install "As Administrator". It should already be doing that...but it failed when I didn't.

comment:38 Changed 10 years ago by michal.sokolowski

openvpn-install-2.3.5-I601-x86_64 and tap-windows-9.21.1 fixes problem for me!

Last edited 10 years ago by michal.sokolowski (previous) (diff)

comment:39 Changed 10 years ago by egroeper

openvpn-install-2.3.5-I602 fixes my problems (this issue existed only with NDIS5 on Win8, but NDIS6 driver didn't work for me till 2.3.5-I602).

comment:40 Changed 10 years ago by Samuli Seppänen

Resolution: fixed
Status: newclosed

comment:41 Changed 8 years ago by mltgames

If you have windows 8 or 10 I fixed this by doing an full restart/reboot on windows.

If I was fast restarting, it wasnt enought, but the full restart/reboot worked.

You need to run cmd.exe as admin and run this command "shutdown /s /t 0" it will perform a full restart and now everything will work after that.

comment:42 Changed 6 years ago by artem.komisarenko

Reproduced on Windows 8.1 with 2.4.6 client. Able to connect after long play with enable/disable TAP adapter, reboot machine and so on. I'm still have no stable workaround or reproduce. Timeouts, open Network control center, made TAP adapter always connected did not help.

Note: See TracTickets for help on using tickets.