#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:2 Changed 11 years ago by
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.
comment:3 Changed 11 years ago by
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.
comment:4 Changed 11 years ago by
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
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.
comment:6 follow-up: 7 Changed 11 years ago by
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 Changed 11 years ago by
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 follow-up: 9 Changed 11 years ago by
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 Changed 11 years ago by
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 follow-up: 11 Changed 11 years ago by
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 Changed 11 years ago by
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
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 follow-up: 14 Changed 11 years ago by
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 follow-up: 15 Changed 11 years ago by
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 Changed 11 years ago by
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 follow-up: 18 Changed 11 years ago by
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.
comment:17 Changed 11 years ago by
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 follow-up: 19 Changed 11 years ago by
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 Changed 11 years ago by
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 to make a redneck fix, it worked a couple of times, 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.
comment:20 Changed 11 years ago by
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 :)
comment:21 follow-up: 23 Changed 11 years ago by
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
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 Changed 11 years ago by
Thanks, but in my case there was no difference, after restarting it doesn't work.
comment:24 Changed 11 years ago by
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
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:27 Changed 10 years ago by
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
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:
- Go into device manager
- Find your Tap Adapter
- Right click
- Select "Propterties"
- Select "Advanced Media Status"
- Set it to "Always Connected"
- Click Ok
- 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
Now we have some workarounds, but is there any progress in fixing the driver for real?
Thanks,
richard
comment:30 Changed 10 years ago by
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 follow-up: 33 Changed 10 years ago by
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
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 Changed 10 years ago by
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
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
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."
comment:36 Changed 10 years ago by
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
comment:37 Changed 10 years ago by
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
openvpn-install-2.3.5-I601-x86_64 and tap-windows-9.21.1 fixes problem for me!
comment:39 Changed 10 years ago by
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
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:41 Changed 8 years ago by
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
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.
Discussed this issue in a community IRC meeting:
Things that can be tried: