Opened 7 years ago

Last modified 3 years ago

#828 new Bug / Defect

Bridged Windows 7 Connection Not Functional

Reported by: mpfrench Owned by:
Priority: major Milestone: release 2.4.11
Component: tap-windows6 Version: OpenVPN 2.4.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: selva.nair@…, chipitsine@…

Description

I suspect that Microsoft has recently changed the way Windows 7 Ultimate x64 handles bridged connections. Now a bridged TAP and LAN adapter is put in the "Unidentified Network" category which results in no Internet connection.

openvpn-install-2.4.0-I601.exe was installed.

Attachments (29)

Network Connections.jpg (42.7 KB) - added by mpfrench 7 years ago.
Network Connection Details.jpg (29.1 KB) - added by mpfrench 7 years ago.
Network Bridge Status.jpg (20.4 KB) - added by mpfrench 7 years ago.
openvpnserv2.InstallLog (824 bytes) - added by mpfrench 7 years ago.
Installer Log
Unidentified Network Properties.jpg (24.2 KB) - added by mpfrench 7 years ago.
Work-around
TAP IPv4 Settings.jpg (36.0 KB) - added by mpfrench 7 years ago.
netsh_int_ip_show_config.txt (2.2 KB) - added by mpfrench 7 years ago.
netsh_int_ip_show_route.txt (2.1 KB) - added by mpfrench 7 years ago.
netsh_int_ip_show_config-after_bridging_LAN-TAP.txt (1.8 KB) - added by mpfrench 7 years ago.
netsh_int_ip_show_route-after_bridging_Lan-TAP.txt (1.9 KB) - added by mpfrench 7 years ago.
netsh_int_ip_show_config-after_manual_bridge_IPv4_setting.txt (1.9 KB) - added by mpfrench 7 years ago.
netsh_int_ip_show_route-after_manual_bridge_IPv4_setting.txt (1.9 KB) - added by mpfrench 7 years ago.
Network_and_Sharing_Center_20170214.jpg (70.7 KB) - added by mpfrench 7 years ago.
TAP_Driver_Details_20170216.jpg (18.3 KB) - added by mpfrench 7 years ago.
LAN_Driver_Details_20170216.jpg (23.8 KB) - added by mpfrench 7 years ago.
Network&Sharing_Center_AVG16_Disabled_Bridged_20170217.jpg (71.0 KB) - added by mpfrench 7 years ago.
w7br0etc.tar.gz (7.7 KB) - added by tct 7 years ago.
W7 srv 2.4.0 tap/bridge + WXP cli 2.3.14 tap (config, logs etc)
IPCONFIG_No_Bridge.txt (3.5 KB) - added by mpfrench 7 years ago.
IPCONF_Bridge.txt (2.8 KB) - added by mpfrench 7 years ago.
Main_Server_20170415.txt (10.3 KB) - added by mpfrench 7 years ago.
Test_Server_20170415.txt (4.2 KB) - added by mpfrench 7 years ago.
Main_Server_No_Bridge_20170415.txt (12.5 KB) - added by mpfrench 7 years ago.
Event_Log_20170415.txt (1.5 KB) - added by mpfrench 7 years ago.
Registry_20170416.jpg (81.5 KB) - added by mpfrench 7 years ago.
LAN1-LAN2_Bridge.jpg (42.5 KB) - added by mpfrench 7 years ago.
gpo.html (65.9 KB) - added by mpfrench 7 years ago.
gpo2.html (65.9 KB) - added by mpfrench 7 years ago.
gpresult /H gpo2.html
GPO.zip (14.0 KB) - added by mpfrench 7 years ago.
zipped files gpo.html and gpo2.html
Win7_Unidentified_Networks_Properties.jpg (31.1 KB) - added by mpfrench 4 years ago.
Windows 7 Unidentifed Network Properties Changes to Allow Bridging

Download all attachments as: .zip

Change History (123)

Changed 7 years ago by mpfrench

Attachment: Network Connections.jpg added

Changed 7 years ago by mpfrench

Changed 7 years ago by mpfrench

Attachment: Network Bridge Status.jpg added

comment:1 Changed 7 years ago by Gert Döring

This is lacking information - what are you trying to bridge where? LAN to TAP? What does the OpenVPN log show (verb 3 or verb 4)? Are these snapshots taken while openvpn is connected or when it is disconnected?

We do have a crystall ball, but it's already in use, so you'll have to provide relevant data yourself.

Last edited 7 years ago by Gert Döring (previous) (diff)

comment:2 Changed 7 years ago by mpfrench

I bridged the LAN to the TAP as can be seen from attachment Network Connections.jpg. Without trying to initiate an OpenVPN connection, all Internet connectivity was lost. There is no point trying to use the OpenVPN tunnel in this condition.

I've been using OpenVPN for years without seeing this behavior which made me think M$ made recent changes to Windows.

I've enclosed the installer log but it does not contain any information that is useful to fixing this problem.

Someone else needs to try to bridge the LAN to the TAP to verify this behavior.

Changed 7 years ago by mpfrench

Attachment: openvpnserv2.InstallLog added

Installer Log

Changed 7 years ago by mpfrench

Work-around

comment:3 Changed 7 years ago by mpfrench

I had this same problem on two out of three servers. I'm convinced that the root cause is a subtle change made by M$ in the Windows infrastructure in the last month although I'm not exactly sure where. However, I did find a work-around.

I changed the Local Security Policies for the Network List Manager Policies for Unidentified Networks to the values shown on the attached screen shot titled Unidentified Network Properties.jpg. Before I made this change, both fields had the Not Configured selection enabled.

Since this change is rather inconvenient for the OpenVPN user to make, I recommend that the OpenVPN developers find an alternative that does not involve changing Windows policies.

Changed 7 years ago by mpfrench

Attachment: TAP IPv4 Settings.jpg added

comment:4 Changed 7 years ago by mpfrench

The work-around that I described above quit working sometime while I was sleeping. Now it does not work at all. The only way I can get network connectivity is to delete the network bridge between the LAN and TAP.

Windows always puts the TAP into the Unidentified Network category even when I manually entered IPv4 network settings to make it part of the LAN before bridging. See TAP IPv4 Settings.jpg. Then when I bridge the LAN and the TAP, the resulting bridge is also put in the Unidentified Network category which is prevented from accessing any network.

I'm out of ideas. For me, bridging just does not work.

comment:5 Changed 7 years ago by Samuli Seppänen

Cc: selva.nair@… added

Selvanair: do you have any ideas about this?

comment:6 Changed 7 years ago by Samuli Seppänen

Can you trace the exact change (e.g. Windows update number) which caused this breakage? What is different about the one server that does not have this problem (yet)?

comment:7 Changed 7 years ago by Samuli Seppänen

Cc: chipitsine@… added

comment:8 Changed 7 years ago by mpfrench

The problem started in January 2017. There were no problems before January. The current version is as follows:
Windows 7 Ultimate x64
OS Version 6.1.7601.23572 (Win7 RTM)
OS Installation Date 17 Jan 2017 with all critical Windows Updates.
(This problem caused me to rebuild the server thinking malware crept in but it did not.)

comment:9 Changed 7 years ago by Samuli Seppänen

Does the unaffected Windows server have all the same Windows updates as the affected ones?

comment:10 Changed 7 years ago by chipitsine

ok, I'll have a look.
can you please describe "bridged" setup in details ?
from one point of view, people often use windows bridges with wrong purpose.
from another point of view, TAP driver might not be well tested (if tested at all) with bridges :)

I need detailed description in order to reproduce and debug

comment:11 Changed 7 years ago by mpfrench

I have the same problem on two different sets of hardware. However, when I installed Win 7 in a VMware virtual machine, I don't see the problem.

Chip, to see my problem, all you have to do is bridge the LAN adapter to the TAP. This has nothing to do with OpenVPN configuration files. On my two real computers, Windows classifies the TAP as an Unidentified Network. Then when I bridge the LAN to the TAP, Windows classifies the bridge as an Unidentified Network and prevents all network communication.

By the way, I've used OpenVPN for several years in this bridged mode so that when I'm physically away from my LAN I can still use it virtually just the same as any computer that is physically inside the LAN.

comment:12 Changed 7 years ago by chipitsine

Windows detects network by several mechanisms, like "link layer topology discover", no wonder when it marks tap or bridge as " undefined" and blocks traffic.

There might be things on openvpn side to put tap to ptoper zone and/or manipilate firewall rules. Currently, unfortunately openvpn is not capable of such kind of operation (well, you can assign some action on up/down/... script)

So, what do you use bridge for?

And... it is not reproducible in virtual environment? I was going to play in hyper-v...

comment:13 Changed 7 years ago by mpfrench

My OpenVPN server is set-up with a bridge so that I can "see" and use every computer inside the LAN when I use the OpenVPN client on a portable computer while away from the LAN. This is a Windows-only network. This bridged set-up has worked great for years up until this month.

comment:14 Changed 7 years ago by chipitsine

good news, I reproduced the described behavour

comment:15 Changed 7 years ago by chipitsine

@mpfrench, I installed "win 7 without sp" + tried various tap-9.21.N, no luck.
were you "running for years" tap-9.9.N (which is previous tap driver) ?

comment:16 Changed 7 years ago by mpfrench

I kept my OpenVPN installation updated constantly over the years. I ran openvpn-install-2.3.14-I601-x86_64.exe for most of December without a problem. I think it has the same TAP version as openvpn-install-2.4.0-I601.exe. I also ran that 2.4.0 version successfully until mid January until I started having problems. I then wiped the old Win 7 installation and re-installed new but had the same problem.

I even tried uninstalling version 2.4.0 and re-installing 2.3.14 but this also had the same problem.

The conclusion I made was that M$ changed Windows to cause this problem. I hope you can find a solution. I could not.

comment:17 Changed 7 years ago by Selva Nair

If you bridge TAP to a LAN adapter it may show up as unidentified network until you set an IP number and default route on it. After that windows should identify it and classify as work or home. That said, is it a problem if the network remains unidentified and classified as public?

Your real issue may not be "Unidentified network" but the adapter (bridge) not getting setup properly for some reason even though the adapter properties GUI may show all the right IP, gateway etc -- it happens. Try setting the address on the bridge manually using netsh. Also please post the routing table ( route print or netsh int ip show route) and interface config ( netsh int ip show config )

comment:18 Changed 7 years ago by chipitsine

@selvanair, I tried to disable firewall completely, IP was supposed to be setup via DHCP, no luck. I noticed some weird messages in Event/System? journal during bridge creation (but not after reboot).

so, it still did not work for me, even with old win7

I'll try other things today

comment:19 Changed 7 years ago by chipitsine

Microsoft gradually sunset SHA-1

http://www.entrust.net/knowledge-base/technote.cfm?tn=8766

"1 Jan 2017 – Windows will stop accepting SHA1 SSL certificates"

can we try setup a Windows, which will think it is still December 2016 ?

comment:20 Changed 7 years ago by mpfrench

I set the server's clock to 1 Dec 2016 and disabled NTP updates. The bridged LAN and TAP was again put in the Unidentified Network zone and Windows prevented all network data flow.

By the way, I did previously try to fool Windows by assigning the TAP manually to be in the LAN address space before the bridge was built. See the screen shot above titled TAP IPv4 Settings.jpg. Windows still put the bridge in the Unidentified Network zone and prevented network data flow.

comment:21 Changed 7 years ago by tct

I will try to set this up myself, I have been using bridge setup for a while too.
(I have HyperV on W10 .. may be it is a W7 thing)

Last edited 7 years ago by tct (previous) (diff)

comment:22 Changed 7 years ago by chipitsine

I'm going to test (Vista, Win7, Win8, Win8.1,Win10) x (ndis5, ndis6) x (dec 2016, jan 2017) x (dhcp, static)

it will take some time.
well, I could not get it working on any Win7 yet

comment:23 Changed 7 years ago by tct

I setup a W10 bridge and --server-bridge vpn
server-bridge 10.10.101.110 255.255.255.0 10.10.101.171 10.10.101.179
and all works normally. (possibly even perfectly)

Tested with ping/http(s)/(s)ftp/ssh from client to server side default gw.
Server net: 10.10.101.0/24, Client net: 10.1.101.0/24 (real separate networks)

Notes:

OS Bridge: vEthernet (HyVeth0) + taps0 (TAP-Windows V9, 9.0.0.21 21/04/2016)
Bridge config: Windows TCPIP IPv4 + IPv6, Windows IPv6 LL drivers, MS MAC Bridge
Bridge status: Private network
TCPIP: ip 10.10.101.110/24, gw 10.10.101.1, dns 10.10.101.1
Openvpn version: Server 2.4.0 Windows, Client 2.4.0 Linux
Windows Firewall: Disabled to setup, Enabled there after
Other enabled network connections: NONE

As I understand it, to make the bridge a Private network the bridge must have the only local default gateway.

I do have limited access to W7 but not until four days time.

Last edited 7 years ago by tct (previous) (diff)

comment:24 Changed 7 years ago by mpfrench

chipitsine, referring to your previous comment regarding M$'s sunset of the use of SHA1 signing certificates, I noticed that the current TAP is signed with both the SHA1 and SHA256 certificates. It would be worth trying signing the TAP with only the SHA256 cert to see if this solves the problem. Who at OpenVPN can generate this resigned TAP?

comment:25 Changed 7 years ago by chipitsine

anyone who has EV code signing cert can do that.
I do have code signing, but not EV.

@mattock can resign.

what I am going to do is to try with not signed tap driver. I studied this subject a bit, it seems that unsigned driver might be even better than sha1 signed

comment:26 Changed 7 years ago by Samuli Seppänen

If my memory serves me right, Windows will check the signature when you try to install the driver, and when the driver is loaded into the memory. If you have the TAP interface it means the driver is already loaded into the memory and it should "just work". That said, there's always the possibility that Windows sneakily adjusts adapter parameters depending on the signature.

comment:27 in reply to:  17 Changed 7 years ago by Samuli Seppänen

Replying to selvanair:

Your real issue may not be "Unidentified network" but the adapter (bridge) not getting setup properly for some reason even though the adapter properties GUI may show all the right IP, gateway etc -- it happens. Try setting the address on the bridge manually using netsh. Also please post the routing table ( route print or netsh int ip show route) and interface config ( netsh int ip show config )

mpfrench: can you give us the information selvanair is asking (above)? That would help us find the culprit, and hopefully, the solution.

Changed 7 years ago by mpfrench

Changed 7 years ago by mpfrench

Attachment: netsh_int_ip_show_route.txt added

comment:28 Changed 7 years ago by mpfrench

I've added a couple of files that show the results of the netsh commands before the bridge is built and before the netsh command to manually assign the TAP its address. I don't use netsh enough to know how to do that. I would be willing to execute the command if you would list it. However, since chipitsine reproduced the problem, it would probably save everyone time if selvanair would try it on real hardware, not a VM. (My VM version of Windows 7 on VMware does not display the problem.)

comment:29 Changed 7 years ago by Selva Nair

Those outputs looks as expected, but then you have no problems with internet before the bridge is built, do you?
Please post the same after the bridging and internet connectivity is lost as you reported originally.

I did bridge LAN to TAP on a win7 machine (physical hardware) and could not reproduce the problem.

comment:30 Changed 7 years ago by mpfrench

I've added the routing files after the bridge was made between the LAN and TAP adapters.

comment:31 Changed 7 years ago by Selva Nair

You had a static address on the LAN adapter but now you have the bridge set to DHCP. But the adapter has not obtained any address by dhcp -- this could be unrelated, so could you please assign a static address to the bridge for testing purposes at least.

You can do this using the GUI but then make sure the netsh int ip show config output correctly displays the address thus set. Alternatively set it from command line (as admin) as below:

netsh int ip set address "Network Bridge" static 192.168.113.2 255.255.255.0 192.168.113.1

Here I reused the address 192.168.113.2 that was previously set on the LAN, if that is not appropriate use another free address.

You will also want to set DNS servers as it was on the LAN adapter. At least set one:

netsh int ip set DNS "Network Bridge" static 8.8.8.8 validate=no

comment:32 Changed 7 years ago by mpfrench

I've added a couple more files after the bridge was formed and IPv4 manually set.

comment:33 Changed 7 years ago by Selva Nair

Sorry, I cant spot anything wrong. You should be able to ping the gateway 192.168.113.1 now. If not, something is indeed wrong with the bridge.

comment:34 Changed 7 years ago by mpfrench

I have no network functionality when the bridge is formed, manually entered IPv4 settings or DHCP.

Changed 7 years ago by mpfrench

Changed 7 years ago by mpfrench

Changed 7 years ago by mpfrench

comment:35 Changed 7 years ago by mpfrench

I installed the latest version of OpenVPN (openvpn-install-2.4.0-I602.exe) and formed the LAN-TAP bridge. It functioned normally for several hours. Windows 7 was happy with it at the start. See the attachment Network_and_Sharing_Center_20170214.jpg.

However, after less than 24 hours, Windows 7 became unhappy with it and labeled the bridge as "Unidentified Network" and prevented all network connectivity.

I don't know enough about the algorithm Windows 7 uses to decide whether or not a network is "Unidentified" to explain the several hour delay in reclassifying the bridge. But I have learned that once Windows 7 decides your network is "Unidentified", you are not getting anything through it, including the whole computer.

I've also noticed that the TAP driver is unsigned. See attachment TAP_Driver_Details_20170216.jpg. This lack of a signature may be causing the identification problem. What would it take to get it signed?

I've also enclosed attachment LAN_Driver_Details_20170216.jpg to show that the LAN driver is signed.

comment:36 Changed 7 years ago by Samuli Seppänen

The only thing you need to sign is the catalog file (see MS docs). That said, some dialogs in Windows incorrectly show the driver as unsigned, probably because they're looking at the .sys file, which does not need a signature, even though it can have one.

On my Windows 7 system a very large percentage (50%?) of driver .sys files are unsigned. This can be tested with a simple (admin) Powershell invocation:

PS C:\Windows\system32> cd C:\
PS C:\> Get-ChildItem -Recurse -Filter "*.sys"|Get-AuthenticodeSignature|Select Status|Format-List

If you run this command, you will see "Status: Valid" and "Status: NotSigned" flashing by.

Quite often these really odd issues with the tap-windows driver are caused by antivirus programs. Do you happen to have one running?

comment:37 Changed 7 years ago by mpfrench

I disabled the anti-virus system on two different computers that have the TAP installed. One runs M$'s Security Essentials and the other runs AVG16. After rebooting each computer, the LAN-TAP bridges would not allow either computer to access the network. See the enclosed screenshot labeled Network&Sharing_Center_AVG16_Disabled_Bridged_20170217.jpg.

I don't think that there is anything else left for me to try to fix the problem. The root cause has to be due to the interaction of Win7 and the TAP when bridged. Something very basic is causing this problem.

comment:38 Changed 7 years ago by Samuli Seppänen

mpfrench suggested that simply forming a LAN-TAP bridge on Windows 7 computer without activating OpenVPN should be enough to reproduce the issue within a day or so.

comment:39 Changed 7 years ago by chipitsine

I suspect dhcp + tap might be an issue.
I'm out of time right now, will back to the issue as soon as I get time

comment:40 Changed 7 years ago by mpfrench

Samuli pointed out the MS driver signing policy above. However, after reading the MS documentation, I'm not sure that simply signing the catalog file is sufficient. See https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/signing-drivers-for-public-release--windows-vista-and-later-

I did some more tinkering today to see whether or not any Windows Updates affected this problem. I installed Windows 7 x64 Ultimate with SP2 (2009 vintage) on a fresh hard drive and purposely selected never check for or install Windows updates. I then installed .Net Framework 4.6.2 and OpenVPN 2.4.0 with I602 [openvpn-install-2.4.0-I602.exe].

I then bridged the LAN adapter with the TAP adapter but never ran OpenVPN, i.e., never activated OpenVPN with a config file.

At first, everything functioned normally and I let the computer run continuous pings to a google.com server. However, as I suspected, after running for several hours, the computer's network quit passing any data. Even re-booting the computer would not let the computer's network function.

The only way I could make the computer's network function was to delete the bridged connection.

I came to several conclusions:
1) Windows Updates do not have anything to do with this problem.
2) This same problem occurred to me now on four different computers and they all took quite a long time to display the network seizing problem which intimates that there must be some communication back to Microsoft that does not happen very often.
3) Since this bridging problem started in January 2017, I believe that Microsoft changed a policy that is checked on-line, infrequently that caused this problem.

Additionally, I did notice that the TAP driver in I602 is now signed by OpenVPN whereas prior releases of this same driver were unsigned. However, I'm not sure that this signature is good enough to suit Microsoft nowadays.

Recommendation
If OpenVPN has not gone through the formal process of driver signing mentioned above, I recommend that you do this. A driver signing problem is the only thing that makes sense to me.

comment:41 Changed 7 years ago by tct

I have been running openvpn tap server-bridge on W7 for over a week and I cannot replicate this problem. The server OS. Bridge has been 100% stable throughout. (attached complete vpn confs/logs etc)
(Unable to add attachments: IndexError: list index out of range )

Briefly:

  • Server:
    W7HomePro-SP1 (M$ fully upto date), Openvpn 2.4 (also tested with 2.3.14)
    Operating System bridge: eth0 + taps0
  • Clients:
    WXPPro-SP3 (M$ whatever), Openvpn 2.3.14
    Linux Ubuntu 16.04 (upto date), Openvpn 2.4

OS. Bridge and --server-bridge + --dev tap clients all work as expected.

Version 6, edited 7 years ago by tct (previous) (next) (diff)

comment:42 Changed 7 years ago by mpfrench

Tincantech, was your server running in a virtual machine or on real hardware?

comment:43 Changed 7 years ago by tct

W7 Server is a real laptop. W10 Server is a real laptop. #828 comment:23 above

These --server-bridges are not over lapping in any way : pki, subnets, wire or clients.

Note on W10 + HyperV ..
Today, after extensive testing and obviously reconfiguring different bridges between HyperV-Host + VMs and OS Net Interface + TAP .. I found that --server-bridge did not pass data while the Control channel was fully functional. I had to rebuild the entire stack, taking many individual steps plus reboot(s) before the OS network bridge would function correctly. (Although the HyperV Switch worked locally, it would not function within the OS bridge with TAP adaptor, even though wireshark showed decrypted pings from the client on the local TAP .. routing is enabled).

Note on W7
For what ever reason, human error possibly, I was also forced to reboot this machine before the --server-bridge worked.

I'll update this post if anything changes over night.

[Edit] 24 hours later:

  • W10 Server + client are working normally.
  • W7 Server needed rebooting, not sure why. Will wait for similar failure and see if I can work out what is going wrong (probably due to power save). But the bridge was still identified as private.
Last edited 7 years ago by tct (previous) (diff)

comment:44 Changed 7 years ago by tct

Well Well ..

Windows 7 and 10 both do not re-establish the OS bridge correctly after Sleep mode.

Openvpn works as expected (wireshark shows unencrypted ARP on the TAP device) but the OS bridge must be restarted, either by reboot or network interface disable/enable.
Something to do with #316 ?

If anybody knows where M$ admit this bug please post here.

Last edited 7 years ago by tct (previous) (diff)

comment:45 Changed 7 years ago by mpfrench

On all four of the Windows 7 x64 servers, I had the power settings adjusted to prevent sleep mode or hibernate mode. On all four, the TAP-LAN bridge prevented all data passing within a day's time. These servers were running on real hardware.

However, when I ran Win7x64 in a virtual machine, the bridge never locked up. I will next try to determine why the VM version acts differently which may help us find a fix.

Changed 7 years ago by tct

Attachment: w7br0etc.tar.gz added

W7 srv 2.4.0 tap/bridge + WXP cli 2.3.14 tap (config, logs etc)

comment:46 Changed 7 years ago by mpfrench

I ran Win 7x64 in a VMware virtual machine for four days but could not get it to duplicate the problem of the LAN-TAP bridge being put in the Unidentified Network zone. The bridge stayed in the Home Network zone.

However, on real hardware running Win 7x64, the bridge is consistently put into the Unidentified Network zone. Sometimes it takes just an hour to happen. Sometimes it takes several hours to happen. However, Windows will not let any data pass through the bridge when it is in the Unidentified Network zone. By the way, OpenVPN is not even running when this happens. This is strictly an adverse interaction between Windows 7 and the TAP driver.

I've tried to find documentation on the algorithm Windows uses to classify a network as Unidentified but have not been successful. I've also not been successful manually trying to change the bridge to a friendlier zone.

Furthermore, I've turned off the Windows firewall but it did not allow any data to pass through the bridge.

I believe that the TAP driver author needs to tackle this problem. There is nothing else a user can try.

comment:47 Changed 7 years ago by Selva Nair

Looking through this thread again, one thing I noticed: the metric shown for the bridge is 10 which appears to imply the link speed on the network card adapter is set to 1Gbps. If so, that may cause issues when bridged with TAP which is a 100mbps adapter. If the adapter is indeed set to 1Gbps change it to auto-negotiate and try.

comment:48 in reply to:  46 Changed 7 years ago by chipitsine

Replying to mpfrench:

I ran Win 7x64 in a VMware virtual machine for four days but could not get it to duplicate the problem of the LAN-TAP bridge being put in the Unidentified Network zone. The bridge stayed in the Home Network zone.

However, on real hardware running Win 7x64, the bridge is consistently put into the Unidentified Network zone. Sometimes it takes just an hour to happen. Sometimes it takes several hours to happen. However, Windows will not let any data pass through the bridge when it is in the Unidentified Network zone. By the way, OpenVPN is not even running when this happens. This is strictly an adverse interaction between Windows 7 and the TAP driver.

I've tried to find documentation on the algorithm Windows uses to classify a network as Unidentified but have not been successful. I've also not been successful manually trying to change the bridge to a friendlier zone.

Furthermore, I've turned off the Windows firewall but it did not allow any data to pass through the bridge.

I believe that the TAP driver author needs to tackle this problem. There is nothing else a user can try.

I'm not sure I've caught your idea.
you tell "tap is in unidentified network zone and that is an issue itself"
can you please describe why do you think it is the root cause of the issue ?

comment:49 Changed 7 years ago by chipitsine

I mean, there might be two directions

"packets do not flow through the bridge" --> "bridge adapter display unidentified network zone"
"bridge adapter display unidentified network zone" --> "packets do not flow through the bridge"

comment:50 Changed 7 years ago by tct

Please note, I have this setup:

  • Win10 OS Bridge fully functional Private Network since 2017-02-01, in use now.
    Plus working TAP --server-bridge with working clients. (Openvpn 2.4.0)
    Real laptop
  • Win7 OS Bridge fully functional Home Network since 2017-02-24, in use now.
    Plus working TAP --server-bridge with working clients (Openvpn 2.4.0 - Also tested 2.3.14)
    Real Laptop

I can not replicate this problem ...

@mpfrench please post details of ipconfig /all before and after the network reconfigures.

Last edited 7 years ago by tct (previous) (diff)

Changed 7 years ago by mpfrench

Attachment: IPCONFIG_No_Bridge.txt added

Changed 7 years ago by mpfrench

Attachment: IPCONF_Bridge.txt added

comment:51 Changed 7 years ago by mpfrench

All - Sorry for the delay in answering your questions. I've been experimenting and wanted to report the results.

Chipitsine - When Windows classifies a network as Unidentified, it prevents data from going in and out. Both directions are blocked on my servers. Also, it's not that Windows classifies the TAP as Unidentified. When the TAP is bridged with the LAN, the bridge becomes labeled as Unidentified after a relatively long time. (More on this below.)

TinCanTech? - I've loaded the ipconfig /all print outs before and after the bridge is formed on one of my test servers. I've assigned the bridge a fixed IP address. There is nothing wrong as far as I can see.

All - Something has changed in the way Windows now acts regarding the LAN-TAP bridge. After TinCanTech? reported that he could not reproduce the problem, I tried to do so myself but have not been successful. I've turned on OpenVPN (openvpn-install-2.4.0-I602.exe) with a bridged LAN-TAP on my production server. For the last 49 hours, there has been no problem. Windows has kept the bridge in the Home Network zone as it should. This is without my changing any software on the server.

During the last 49 hours, I've also installed a second LAN card in a test server and bridged the two LAN adapters (excluding the TAP) just to see if there was some inherent problem with Windows bridging. During that time, the bridge remained classified as Home Network as it should have been.

Also on this test computer, after concluding that there was nothing inherently wrong with the bridging function, I deleted the LAN1-LAN2 bridge and formed a LAN-TAP bridge as before. After this runs for a few days, I'll report the results.

I've scoured the Internet trying to find the algorithm Windows uses to classify a network as Home or Unidentified but have not been successful. If we knew this algorithm, we could easily fix the root cause of the problems I've had.

comment:52 Changed 7 years ago by mpfrench

Selvanir - I forgot to answer your question. The bridge was set for Auto Negotiation in all circumstances.

comment:53 Changed 7 years ago by chipitsine

Let me describe what I mean.
you think you are not happy becase network is put into "unidentified mode". ok.
let us change it

please perform the following steps

1) run "gpedit.msc"
2) Open Computer configration –>Windows Settings –>Security Settings –>select Network list manager policies --> Change "unidentified" to ... whatever you wish

if the root cause of your problem is "unidentified" network location, so, it should repair after above mentioned manipulation.

comment:54 Changed 7 years ago by mpfrench

Chipitsine - I did what you suggested in early February and it did not prevent the LAN-TAP bridge from blocking data in both directions. That is, I still had the problem after doing as you suggested.

Bridge update: I've now run OpenVPN in bridged mode on my main server (Win7x64) for over three days continuously without experiencing any problems. I've also run the LAN-TAP bridge on two other servers without running OpenVPN for about 29 hours continuously without experiencing any problems. All of this success without my performing any changes. It is beginning to look as though somebody is toying with us.

I'll report back in a few days to let you know whether or not the problem re-appears.

comment:55 Changed 7 years ago by mpfrench

Update -- I have not experienced the problem for over 5 days on my main server which is running OpenVPN 2.4.0 with I602 [openvpn-install-2.4.0-I602.exe] and a bridged LAN-TAP. On three other computers running continuously where I bridged the LAN-TAP, but not run OpenVPN, I have not had the problem for over three days.

All of these results were gathered without my performing any configuration changes.

It's as though some entity has the ability, at will, to destroy OpenVPN's function in a bridged configuration. Frankly, this is a serious vulnerability.

Let's recap the facts:
1) The problem is that Windows, after a brief (1-24 hours) time period classified the bridge as an Unidentified Network which prevented all data flow in both directions, effectively locking the computer regardless of OpenVPN running or not.

2) I am not the only person to experience this problem. Chipitsine reported experiencing the problem in late January.

3) The problem started in early January and continued until early March.

4) The problem was experienced during this time running OpenVPN versions 2.3.14, 2.4.0 (I601 and I602).

5) The problem was experienced on four different computers (real hardware) running Windows 7 x64 but not on Windows 7 x64 running in a VMware virtual machine.

6) The problem is not related to any Windows Updates. I experienced the problem on a clean install of a 2009 vintage Win 7x64 (SP1) system where I made sure no Windows updates were installed and no virus protection software was installed.

7) Disabling Windows firewall does not prevent the problem. Virus protection software does not affect the problem.

Recommendations:
1) OpenVPN developers should pursue finding the root cause of this problem since it is a way to destroy the VPN in a bridged configuration.

2) OpenVPN developers should find the algorithm Windows uses to classify a network as "Unidentified Network". I can't find it but believe that finding the root cause of the problem will be obvious once we understand this algorithm.

Thanks to all who have contributed to solving this problem. OpenVPN is a great piece of software and I appreciate your efforts.

comment:56 Changed 7 years ago by Selva Nair

I could never reproduce this behaviour and here is my take:

1) The problem is that Windows, after a brief (1-24 hours) time period classified the
bridge as an Unidentified Network which prevented all data flow in both directions,
effectively locking the computer regardless of OpenVPN running or not.

I think the classification as unidentified network happens when the bridge loses network connection and not the other way. AFAIK network classifications are only used for deciding which firewall profile to apply and the root cause of losing connectivity may lie elsewhere, unrelated to what heuristics Windows uses to classify connections.

So my take is that somehow the bridge loses connection to the router and then Windows shows the network as unidentified. Note that the bridge gets no IP by DHCP when the problem occurs.

Anti-virus and firewall products, among other things, are known to affect network connectivity in unexpected ways, so unless this can be independently reproduced there is hardly any indication that the fault lies in the TAP driver.

That said if the problem is triggered by suspend resume or some such identifiable events it could be a TAP driver problem worth investigating.

comment:57 Changed 7 years ago by mpfrench

This problem happened to me on a clean Win 7x64 without any antivirus installed and Windows firewall turned off.

Also, after the bridge locked up, rebooting the computer would not restore network connectivity. The bridge remained in the "Unidentified Network" zone. The only thing that would restore connectivity was deleting the bridge which immediately restored network connectivity.

We need to know the precise algorithm Windows uses to decide that a network is "Unidentified" and quit guessing. I tried my best but could not find it.

comment:58 Changed 7 years ago by mpfrench

The Windows Bridge "Unidentified network" problem reappeared yesterday at 19:12 CDT, destroying all network connectivity on two separate computers. One of them had OpenVPN running while the other did not. Both had bridged LAN-TAP adapters.

Again, the only way to restore network connectivity on these two computers was to delete the bridge.

comment:59 Changed 7 years ago by tct

While there may be other factors hidden by M$, to my knowledge, "unidentified network" only happens for networks without a default gateway. @mpfrench, next time it happens post full ipconfig /all and route print .. before changing anything. It may be worth searching the windows system log for relatable network errors. Btw, my W10 and W7 pc's are still running with network bridges (as both openvpn server and client on different instances) and no problems have occurred.

Changed 7 years ago by mpfrench

Attachment: Main_Server_20170415.txt added

Changed 7 years ago by mpfrench

Attachment: Test_Server_20170415.txt added

comment:60 Changed 7 years ago by mpfrench

I've attached the output of the commands tincantech requested for both my main server and a test server which has only a bridged LAN-TAP and no running OpenVPN.

Both computers block the network connectivity immediately upon forming the bridge. Deleting the bridges and rebooting always clears the problem.

Changed 7 years ago by mpfrench

comment:61 Changed 7 years ago by mpfrench

I've added a printout from my main server without the bridge. Network connectivity is OK.

Changed 7 years ago by mpfrench

Attachment: Event_Log_20170415.txt added

Changed 7 years ago by mpfrench

Attachment: Registry_20170416.jpg added

comment:62 Changed 7 years ago by mpfrench

I've added an event log file excerpt that shows that OpenVPN is trying to find a registry key that does not exist. I've also enclosed a screen shot of the OpenVPN registry entry.

"openvpnserv error: The system cannot find the file specified. (0x2)
Error querying registry value: HKLM\SOFTWARE\OpenVPN\ovpn_admin_group"

I'm not sure whether or not this error bears any significance on my Unidentified Network problem, but I found this same error message in both my main server which runs OpenVPN and a test server that did not run OpenVPN but had the Windows bridge formed with the LAN adapter and the TAP adapter.

comment:63 in reply to:  62 ; Changed 7 years ago by Selva Nair

Replying to mpfrench:

"openvpnserv error: The system cannot find the file specified. (0x2)
Error querying registry value: HKLM\SOFTWARE\OpenVPN\ovpn_admin_group"

This "error" may be ignored. The service will use the default value and proceed. The error is there because of reusing existing code for reading registry which treats all missing entries as an error. I know its a lame excuse and this should be a warning if at all logged.

comment:64 in reply to:  63 ; Changed 7 years ago by Samuli Seppänen

Replying to selvanair:

Replying to mpfrench:

"openvpnserv error: The system cannot find the file specified. (0x2)
Error querying registry value: HKLM\SOFTWARE\OpenVPN\ovpn_admin_group"

This "error" may be ignored. The service will use the default value and proceed. The error is there because of reusing existing code for reading registry which treats all missing entries as an error. I know its a lame excuse and this should be a warning if at all logged.

As openvpnserv does not require ovpn_admin_group registry key this should probably be a NOTICE level message. I think removing the message altogether would be reasonable, as we have documented ovpn_admin_group somewhat adequately now.

comment:65 in reply to:  64 Changed 7 years ago by Selva Nair

Replying to samuli:

As openvpnserv does not require ovpn_admin_group registry key this should probably be a NOTICE level message. I think removing the message altogether would be reasonable, as we have documented ovpn_admin_group somewhat adequately now.

What about adding this key with default value during installation? The default will provide a place holder for anyone wanting to customize it and also silence the error.

comment:66 Changed 7 years ago by mpfrench

Selvanair, your last suggestion is probably the way OpenVPN should have been written in the first place.

Now for an update on my problem: I formed the LAN-TAP bridge again yesterday evening and have not had any network connectivity problems since that time.

Did anyone notice anything abnormal in the ipconfig /all and route print files that I attached the other day when I was having the problem?

comment:67 Changed 7 years ago by Samuli Seppänen

Selvanair: adding that key on install time should take care of this. Can the group name be empty or do we have to set it to the built-in admin group or something?

comment:68 Changed 7 years ago by Selva Nair

@samuli: The code uses the value "OpenVPN Administrators" if this key is not found. So it has to be set to that value as the default. The group itself need not exist.

comment:69 Changed 7 years ago by mpfrench

At 19:05 CDT I again experienced the dreaded Unidentified Network problem which prevents all network connectivity. I had OpenVPN (openvpn-install-2.4.1-I601.exe) running on my main server and just the TAP (tap-windows-9.21.2.exe) running on a test computer. Both computers were running with the LAN-TAP bridge. The full OpenVPN was not installed on the test computer.

Both computers experienced the Unidentified Network problem. Deleting the bridges cleared the network connectivity problem on both computers without changing or rebooting the router.

I believe that this test shows that the problem lies with the interaction of the TAP with Windows.

comment:70 in reply to:  69 Changed 7 years ago by Gert Döring

Replying to mpfrench:

I believe that this test shows that the problem lies with the interaction of the TAP with Windows.

It's certainly not OpenVPN, if the issue happens while openvpn is not running at all.

What I'm wondering is: is this the TAP driver's doing, or is this something in windows' bridge code fighting itself. So if you have a system where this is happening "regularily enough" - could you try setting up a bridge between two LAN ports (second LAN port not connected to anything)? I'm curious what happens then.

Changed 7 years ago by mpfrench

Attachment: LAN1-LAN2_Bridge.jpg added

comment:71 Changed 7 years ago by mpfrench

Cron2 -- Great suggestion to bridge two LAN adapters! I should have thought of that a long time ago.

I installed a second LAN card in a computer and bridged them. No cable was connected to the second LAN card. So it mimiced the condition that the TAP is in when a LAN-TAP bridge is formed.

Lo and behold, the Unidentified Network problem appeared. It didn't make any difference whether I let the bridge run on DHCP or assigned a fixed address to it. I've attached a screen shot of the network configuration as file LAN1-LAN2_Bridge.jpg.

Now how do we complain to M$????? I've never found a successful way.

comment:72 Changed 7 years ago by mpfrench

Since it is not likely to get M$ to change anything about the way Windows works, is it possible for someone to develop a TAP adapter that does not show up in Windows' "Unidentified Network" zone? If so, this should keep Windows from classifying the LAN-TAP bridge as an Unidentified Network.

From the testing I've done, Windows puts the bridge in the Unidentified Network zone if any of the components of the bridge are in the Unidentified Network zone.

Selvanair, chipitsine -- your comments please.

comment:73 Changed 7 years ago by Selva Nair

From the testing I've done, Windows puts the bridge in the Unidentified Network zone if any of the components of the bridge are in the Unidentified Network zone.

Selvanair, chipitsine -- your comments please

I cannot reproduce this so I have no idea. I can bridge TAP to LAN or LAN to Wireless with LAN cable disconnected without issues. In the latter case when WiFi? is down the bridge shows network cable unplugged and the state changes to "Internet access" as soon as WiFi? is connected.

As others have also failed to reproduce this behavior I suspect something specific to your machine causing this.

comment:74 in reply to:  72 Changed 7 years ago by chipitsine

Replying to mpfrench:

Since it is not likely to get M$ to change anything about the way Windows works, is it possible for someone to develop a TAP adapter that does not show up in Windows' "Unidentified Network" zone? If so, this should keep Windows from classifying the LAN-TAP bridge as an Unidentified Network.

From the testing I've done, Windows puts the bridge in the Unidentified Network zone if any of the components of the bridge are in the Unidentified Network zone.

Selvanair, chipitsine -- your comments please.

can you, please, share your GPO settings ?

(run as admin) --> cmd --> gpresult /H gpo.html

I would like to have a look at "gpo.html"

Changed 7 years ago by mpfrench

Attachment: gpo.html added

Changed 7 years ago by mpfrench

Attachment: gpo2.html added

gpresult /H gpo2.html

comment:75 Changed 7 years ago by mpfrench

Chipitsine, I've attached two files. gpo.html was made while the LAN-TAP was working. gpo2.html was made shortly after the bridge went into the Unidentified Network mode and I deleted the bridge and rebooted the computer.

Changed 7 years ago by mpfrench

Attachment: GPO.zip added

zipped files gpo.html and gpo2.html

comment:76 Changed 7 years ago by mpfrench

I just noticed that the web site destroyed the formatting of the html files that I previously uploaded. So I've zipped them and uploaded the zipped file.

comment:77 Changed 7 years ago by Samuli Seppänen

mpfrench: the HTML files look fine if you click on "Original format" at the bottom of the page.

comment:78 Changed 7 years ago by chipitsine

I did not answer on GPO report.
yes, it is easy to see "original format", actually it is very clean report.

no registry magic, not 3rd party software, .... pure Windows
even, no domain

comment:79 Changed 4 years ago by mpfrench

I started this topic in 2017 and am just reporting that the problem still exists in both the latest versions of Windows 7 and 10. I installed openvpn-install-2.4.8-I602-Win7.exe on the Windows 7 computer and openvpn-install-2.4.8-I602-Win10.exe on the Windows 10 computer. Both act the same.

Bridging the LAN adapter with the TAP adapter results in "No internet connection" without even trying to run the OpenVPN software. In other words, there is an incompatibility between modern versions of Windows 7 & 10 and the latest TAP adapters.

For me, this problem started in January 2017. Before that time, I successfully ran a bridged OpenVPN for several years on Windows 7.

I'm hoping that the TAP developers will look into this problem and find a fix. I'm all out of ideas to try and have not been able to find any Microsoft documentation on what they have changed that is responsible for this incompatibility.

comment:80 Changed 4 years ago by Gert Döring

Milestone: release 2.4.0release 2.4.9
Priority: criticalmajor

Bumping the milestone to 2.4.9 - not saying that we can fix it by then, but mostly cleaning up trac and having tickets with milestones pointing to long-done releases is not helpful.

Not sure how to tackle this. It might be a general problem of "bridges" (= you can't do networking on them, just bridge, and use a separate interface out to transport openvpn). It might be a problem with tap driver being "not bridge compatible" with ethernet interfaces nowadays.

Anyone with clueful Microsoft contacts who could find this out...?

Changed 4 years ago by mpfrench

Windows 7 Unidentifed Network Properties Changes to Allow Bridging

comment:81 Changed 4 years ago by mpfrench

I've never been able to find the algorithm Windows uses to classify a network as "Unidentified Network". The logic must be in the kernel since turning off the Windows firewall has no effect on the network classification. If we knew this algorithm, the TAP developers could probably find an elegant solution.

However, I've found a workaround that has worked correctly for four days now. The breakthrough is to change the permissions on the Unidentified Network Properties as shown in the figure labeled Win7_Unidentified_Network_Properties.jpg. This also works for Windows 10.

Interestingly, I tried this workaround a long time ago but it was not successful then. M$ must have changed the kernel in between then and now.

Samuli, I'm going to e-mail you a small Word document that shows step-by-step instructions for the keys to get bridging working on Windows 7 and 10. Although this document is only 390KB, this forum size limit of 256KB would not let me attach it here. Hopefully, somebody will incorporate this knowledge into a revised HOW-TO for Windows bridging.

comment:82 Changed 4 years ago by Gert Döring

This is great news, thanks. You can also mail the document to me, gert <at> greenie.muc.de

comment:83 Changed 4 years ago by tct

If you don't mind, I would also like to see your doc: tincanteksup <at> gmail

comment:88 Changed 4 years ago by ampascual

Spam

comment:85 Changed 4 years ago by mpfrench

I was hoping that somebody would clean-up the HOW-TO section to incorporate my notes. In the mean time, I'll be happy to e-mail the keys to getting bridging working to anyone.

comment:86 Changed 4 years ago by Samuli Seppänen

mpfrench: can you resend the Word doc? I remember waiting for it but I don't think ever appeared to my INBOX.

comment:87 Changed 4 years ago by mpfrench

Samuli, I just resent the doc to you. I suspect your mail system ate my previous message since I did not receive a bounce from your end.

comment:88 Changed 4 years ago by ampascual

Spam

Last edited 4 years ago by Eric Crist (previous) (diff)

comment:89 Changed 4 years ago by kcoombes

Hi Mpfrench. I too would like to review your notes. Would you send them to valleyceltic <at> gmail?

For our stay-at-home lives, over a month ago I setup a bridged Ethernet VPN between a Raspberry Pi at home as the client, and an office lab Hyper-V VM running Debian as the server so that I could access of the lab VLANs of my choice directly as a support engineer, via VLAN trunking. Works great. As you probably know, online documentation and help with the details on setting this up is not cohesive and often sketchy. But after much research and some intelligent guessing as a network engineer, I finally put all the pieces together. I hope to make my own set of notes soon to help others with the same setup.

When I offered my coworkers the same Pi setup, not all want to spend the $ for a Pi even though it's not that expensive. So I thought, "why not use our work laptops"? I installed the community version OpenVPN for Windows, and I used basically the same configuration file as for my Pi. OpenVPN GUI claims the tunnel is up. But from what I can tell no packets flow over the tunnel (looking a packet capture on the Debian server), and though I have spent many hours looking at it, I have not figured out why.

I was about to open a new ticket here describing all in much more detail when I ran across your ticket and your offer of your notes. Before I open a ticket I'd like to compare my attempt with your notes.

Kind Regards,
Kenneth

comment:90 Changed 3 years ago by mpfrench

About one month ago, I installed OpenVPN-2.5.0-I601-amd64.msi on both a Windows 7 server and a Windows 10 server. I can confirm that this OpenVPN version solves the problem in this ticket. Windows bridging has been rock solid.

comment:91 Changed 3 years ago by kcoombes

mpfrench,

This is great news! I had set this project aside having spent too much time on it with no successful results. I will try to find some time maybe this weekend or some night this week to try again with 2.5.0. I read the release notes online and it look promising for sure.

Regards, Kenneth

comment:92 Changed 3 years ago by mpfrench

My last post is wrong. The bug is still present in OpenVPN-2.5.0-I601-amd64.msi.

See bug report 1385 for a consolidated review and testing.

comment:93 Changed 3 years ago by kcoombes

mpfrench,

Thank you for the update. I did try OpenVPN-2.5.0-I601-amd64.msi but it also didn't work for me despite using the same configuration basically as on my Raspberry Pi. The release notes didn't mention anything new related to bridging mode anyway, or so it seemed from what I remember when I read them.

I will look through your bug report 1385 and your setup to see if I can learn what is different from my setup. Despite the new crash issue you found, I'd like to at least get it to work up to that point. :-)

regards,
Kenneth

comment:94 Changed 3 years ago by Gert Döring

Milestone: release 2.4.9release 2.4.11
Note: See TracTickets for help on using tickets.