How to make a private Unidentified Network identifiable and private?
Windows 7 seems to be unable to effectively identify my VPN connection. I'm running Windows 7 Professional 32-bit. I've installed OpenVPN 2.1RC20 (the latest release of OpenVPN). OpenVPN creates a virtual network connection using the "TAP-Win32 Adapter V9". When I connect to the VPN, I am not prompted to identify the network. This is apparently due to the fact that the network to which I'm connecting does not supply a default gateway. That is, I'm connecting to a private network and I only need access to the private nodes on the network. For example, here are the relevant lines in the routing table after connecting: IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 10.204.102.1 10.204.102.113 25 <-- this is my internet connection 10.244.31.1 255.255.255.255 10.244.31.33 10.244.31.34 30 <-- this is the VPN gateway 10.244.31.32 255.255.255.252 On-link 10.244.31.34 286 10.244.31.34 255.255.255.255 On-link 10.244.31.34 286 10.244.31.35 255.255.255.255 On-link 10.244.31.34 286 192.168.48.0 255.255.255.0 10.244.31.33 10.244.31.34 30 <-- this is the remote private network So as you can see, the default gateway applies to my internet connection only and not to the newly-connected private network. As a result, Windows automatically classifies this VPN connection as an Unidentified Network and forces its classification to public. There appears to be no way to manually identify this network and mark it as private. I found that if I did assign a default gateway using route add 0.0.0.0 mask 0.0.0.0 10.244.31.33 metric 50 that Windows would immediately ask me to identify the network, and I could identify it as private. However, if I disconnect from the VPN and reconnect, the network is again classified as an "Unidentified Network". Is there any way, without defining a default gateway (via an undesirable routing table entry), to configure Windows to recognize the connection as a private connection? Is there a way to force any connection on this interface to be treated as private? In Windows Vista, these connections could be defined as private and the setting would be remembered across disconnects, so this is a regression.
October 22nd, 2009 7:44pm

The following thread does provide a technique to have the Windows Firewall ignore that interface. http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/b9cd4de4-274e-45b4-95e3-94ac13127b37 This doesn't seem like the right solution. First, the connection should still be protected by whatever firewall settings are appropriate. Second, the connection is still treated as public when in should be private.
Free Windows Admin Tool Kit Click here and download it now
October 22nd, 2009 8:31pm

When it successfully connects to a VPN server, the Default Gateway must be the VPN server. Otherwise, although it prompts that the VPN connection is successful, you cannot access any resources via the VPN. Certainly in this case the network cannot be identified properly. Obviously the OpenVPN program cannot successfully configure the Default Gateway for the VPN connection. I suggest that you run it as administrator, or try to find a new released version that is compatible with Windows 7. Arthur Xie - MSFT
October 24th, 2009 11:12am

Arthur, Thanks for the response, but I believe you're mistaken. A default gateway is just another name for a route for all unknown networks. Since the purpose of this VPN is not to provide connectivity for all Internet addresses, but only to provide access to the private LAN, it only needs to provide routing entries for the private networks. These are the route entries I described above, and this is the correct configuration. This configuration works for all of our clients and describes precisely the architecture we desire. The route configuration is the same on Windows Vista. The difference is that on Windows 7, the UI refuses to provide a mechanism to mark the connection as private if it has no default gateway. This seems counter-intuitive and incorrect. I can imagine many scenarios where a system is connected to a private network without a default gateway (route to the Internet) but still needs to be treated as a private network. Adding a default gateway with a high metric is not the correct solution - it creates a spurious routing table entry that has no effect on the routing. That is, because the user's Internet connection that he's using to establish the VPN connection already has a default gateway with a lower metric, it will be used for all Internet traffic. If the the VPN default gateway had a lower metric, it would prevent the connection to the VPN server (without yet another routing table entry to direct the tunnel traffic). Is there any way to force this connection to be a private connection without adding a default gateway? Is this by design? If so, respectfully, it's a bad design, and it should be corrected in SP1 (if not sooner). I network without a default gateway is as private as a network gets. Forcing it to be a public network seems like a grand oversight, especially since many VPNs will have a very similar configuration. If for some reason I'm mistaken, please point me at resources that indicate why I'm wrong and all networks without a default gateway should be considered unsecured. Otherwise, there should be a way in Windows 7 to designate this network connection as private.
Free Windows Admin Tool Kit Click here and download it now
October 29th, 2009 4:35pm

Hi, Jason. If you'll observe thread http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/4fd9d3e8-8b1b-4a55-9190-2a61410aff6a you'll see that there's currently no solution to your problem, and this is likely by design. I've also stuck with this stupid prob having two LANs, one to provider and one to y small home network. The irony is that prov network can become private where it shouldn't and home network is stated as unidentified. so I must do some magic to get it work (not a solution, just workaround). Experts are ignoring our questions. I assume there was a dumbhead in architects division who proposed this change. Such behavior has absolutely no sence with the presence of ICS module, because it's one of the commonest scenarios with ICS - one interface has connection to provider and obviously has GW set; another network iface is looking into small home network and obviously has NO DEFAULT GATEWAY because this PC is a GW itself for home network. MS guys, you're surely sawing the branch you're sitting on. If you wanted people throw your new shiny OS and switch to older versions or to Linux, you've done this. (Sigh) I and many other people are still waiting for proper solution. I though to buy a copy of W7 this winter or near, but this prob pushed me from it. Thx for attention. (sorry for grammar, I'm not English native)
October 30th, 2009 12:26am

This thread seems to have a workaround by changing the NdisDeviceType of the VPN adapter. I'm not sure what the implications are of this, but I use this same technique for my VMWare local adapters so they don't interfere with the firewall either. I'll report back how this solution works.
Free Windows Admin Tool Kit Click here and download it now
November 10th, 2009 12:36am

I have successfully worked around a similar issue. This is to use any IP address of an attached resource on the closed network as your default gateway (DO NOT USE THE IP ADDRESS OF YOUR OWN NETWORK ADAPTER). This will allow you to name the "unidentified network" and declare it private.If you mistakenly apply the default gateway to be one of your own network interfaces, you will need to remove all default gateway addresses with the following command ROUTE DELETE 0.0.0.0then redefine any necessary default gateways associated with interfaces.Microsoft as of VISTA, 2008, WIN-7 has made the default gateway address a persistent route. This can possibly create a "unidentified network" of phantom creation that is hard to remove without using the above ROUTE DELETE command.Good systems are supportable
November 10th, 2009 4:24am

The following thread does provide a technique to have the Windows Firewall ignore that interface.http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/b9cd4de4-274e-45b4-95e3-94ac13127b37This doesn't seem like the right solution. First, the connection should still be protected by whatever firewall settings are appropriate. Second, the connection is still treated as public when in should be private. Arthur assumed that your connection would be using the VPN connection as its default gateway because that is the way the VPN client works. In your case this is not so. The VPN client has only a host routeto the VPN server.Referringto it as an interface is more accurate than referring to it as a network. In fact it is simply a point to point link between this machine and the server. Nothing else can use it. I would have expected NLA (and the firewall) toignore it. Since it doesn't, forcing NLA to ignore it is probably the best option, in my opinion. Like the problem with ICS mentioned above, it looks like an oversight in the design. Lots of interfaces don't need default gateway settings. I had similar problems to TargeT-San with Server 2008R2 and routing to virtual networks. (Steve Hathaway's suggestion is not appropriate, as the interface cannot have a DG because it is itself the DG for the "private" LAN). I gave up and ran the router in a vm, not the host.Bill
Free Windows Admin Tool Kit Click here and download it now
November 10th, 2009 7:11am

Hi, Bill Thanks a lot for your answer. For W7, I've solved this problem like I've done this in XP, by just disabling all services except IPv4 in external adapter config. But I'm still asking why NM was designed in this way regardless of such mass of negative feedback since RC.
November 11th, 2009 4:06pm

Hi. Have You tried this: http://www.vistax64.com/vista-networking-sharing/35031-openvpn-vista-not-working-why.html Works for my Vista perfectly. Could work with 7. Tom
Free Windows Admin Tool Kit Click here and download it now
November 22nd, 2009 9:55pm

Xand: Thanks, but that article is almost completely unrelated to my problem. I can use OpenVPN just fine under Windows 7. The problem is the way that Windows 7 handles network identification for networks without gateways, and the fact that there's no effective workaround.
November 22nd, 2009 10:26pm

I generally use ZoneAlarm Firewall for my PCs. I can then determine which hosts, subnets, and interfaces are to be trusted and given the ability to share and discover network resources. The ZoneAlarm Internet zone provides locks to prevent Microsoft resource sharing for everything that is not trusted. Programs can be given a set of of trust or distrust permissions by ZoneAlarm. However, ZoneAlarm has no way to filter at the TCP or UDP port what trusts are to be selective allowed or rejected. The most recent incarnation of ZoneAlarm understands the Microsoft NTLM-V2 resource addressing issues. Earlier ZoneAlarm would not allow resource sharing using NTLM-V2. - - The Microsoft Firewall, by default, protects all networks to the same protection level. If a public network is identifed, then no sharing is available unless the Microsoft Firewall is disabled. I do not know why Microsoft identifies a network by its default gateway! This is obsurd! -- Traditionally, a network was defined as a range of network addresses, scoped by a network mask. These could be given names in UNIX systems by making entries in the /etc/networks table. Microsoft, (in their lack of wisdom) or their desire to redefine networking, has declared that a private network must have a default gateway. Any network without a default gateway is therefore declared Public and unidentified. The Microsoft Firewall will, by default, prevent any resource sharing with public networks. Just the presence of a public network will often prevent resource sharing with your private networks if Microsoft Firewall is active. You therefore need to turn off Microsoft Firewall and supply your own 3rd party firewall to assume the protections requirements of your network(s). Good systems are supportable
Free Windows Admin Tool Kit Click here and download it now
December 11th, 2009 2:13am

I have successfully worked around a similar issue. This is to use any IP address of an attached resource on the closed network as your default gateway (DO NOT USE THE IP ADDRESS OF YOUR OWN NETWORK ADAPTER). This will allow you to name the "unidentified network" and declare it private.If you mistakenly apply the default gateway to be one of your own network interfaces, you will need to remove all default gateway addresses with the following command ROUTE DELETE 0.0.0.0then redefine any necessary default gateways associated with interfaces.Microsoft as of VISTA, 2008, WIN-7 has made the default gateway address a persistent route. This can possibly create a "unidentified network" of phantom creation that is hard to remove without using the above ROUTE DELETE command. Good systems are supportable I used this approach for a network consisting of a Vista machine sharing its internet connection via ICS over wireless to a pair of Windows 7 machines. This network was set to Public. The Windows 7 machines which were also directly connected to each other via ethernet, set to Home, to allow for homegroup access. In this case, I had the ethernet NICs on each Windows 7 machine set to use the IP of the other as a gateway, as Steve Hathaway indicated above.For example:Windows 7 A: IP: 10.0.0.1 MASK: 255.255.255.0 GATEWAY: 10.0.0.2Windows 7 B: IP: 10.0.0.2 MASK: 255.255.255.0 GATEWAY: 10.0.0.1However, this only worked for me if the wireless connections were set to "Obtain an IP address automatically". If I defined a gateway manually on the wireless NICs, the ethernet gateway was used, causing internet access to be lost. I checked the route tables ("route print" at the command line) and using automatic IP addresses set the wireless gateway to a lower metric than the ethernet gateway, allowing internet access. Hope this helps anyone looking to get a similar config set up.
December 30th, 2009 1:39am

How to make an Unidentified Network identifiable and private 1. Choose a reachable IP address (Not your NIC card address) and make it a default route or gateway. Now the network can be named and the Microsoft Windows Firewall can be made happy. The IP address does not have to be associated with a router or firewall. Even a printer address will suffice on a closed network. If you have multiple networks on your system and one or more is a Public network (regardless of being Identified) may cause the Windows Firewall to block all resource sharing capability. You may need to install a 3rd party firewall on your workstation computer (Windows Server products have an advanced firewall capability). 2. If you happened to use your NIC card as the default route, you will find a phantom persistent default route in the routing table that needs to be removed. You can see that you have both a private network and an unidentified public network associated with the same network interface. As administrator, on the command console, remove the bad default route with: route delete 0.0.0.0 the-nic-ip-address This will remove the phantom network. Then check step 1 to find an appropriate default route or gateway. 3. With multiple networks, Microsoft will complain if you have more than one default route. Make sure that your Internet default route has a lower metric than all of your other default routes. Good systems are supportable
Free Windows Admin Tool Kit Click here and download it now
February 12th, 2010 7:59pm

Hi Steve. Thanks for the suggestion. As I explained, I'm using OpenVPN to establish a connection to a remote network. A default route on that network, even with a metric of 9999, is technically inappropriate. The proposed solution, while it does appear to work around the problem, seems hackish, brittle, and ungraceful. Say the remote network configuration is changed - the VPN software will automatically reconfigure the IP address, subnet mask, DNS servers, etc., but each user will have to manually go into his adapter configuration and update the bogus gateway. The user install process goes from, "install this software and run it" to "install this software, go to your network adapters (through control panel, ...), right click the adapter, properties, find IPv4, properties, advanced, ..." In other words, it's onerous, especially for an end user. Now it's possible all of the VPN vendors will build in automatically generating bogus gateways for private networks, but this doesn't seem like the right solution at all. Let me be clear: this problem is solved for me. I know the workarounds (in fact, I described them in my original question). I'm more concerned about providing feedback so that it can be fixed for others in future releases. It seems to me, Microsoft could make a very simple change to the network detection algorithm that would fix this problem. When identifying a network, instead of automatically considering a null gateway as an unidentifiable connection, allow the (IP, NULL) pair to be identified just as (IP, GATEWAY) is identified. It's possible this proposed solution would have unintended consequences of which I'm unaware, but if that's the case, it would be nice to know why the current implementation is optimal... in which case, I'll focus more on getting the vendors to address the issue. If an answer to my original question can't be given, I'd also accept a reference to a document that explains why the current implementation is optimal or necessary.
February 12th, 2010 8:25pm

We are trying to get Windows 7 ready to go out with the cisco flavor of vpn client and seem to have run in to the same issue. I'll do more testing to confirm.
Free Windows Admin Tool Kit Click here and download it now
March 11th, 2010 1:29am

After reading miles of forums and trying everything i could, the only logical response was this one: Windows 7 DHCP server emulation (or whatever is their DHCP called) SUCKS badly, so it is not capable to give you a proper DHCP lease (an internal class B IP, a default route, and no stupid settings at all) - negotiation for such a DHCP lease fails because somewhere in your small network is another DHCP, but CONNECTED TO ANOTHER LAN interface and has nothing to do with the one you really want to use. So I haven't seen my solution anywhere, and I give it to you hoping you will spend less time wondering about your drivers, setting stuff manually or other disputable solutions as i did. I can now connect without any hustle whenever i please to do so: I got myself a small DHCP server software, which runs alone as a service; every time i get my laptop at work, i can connect. when i come home to my stupid windows 7, i can also connect, as i have my small dhcp software running and granting me the proper settings in a heartbeat. you can use any spftware you like, this is what i found first: DHCP Server V1.81 written by some guy named Uwe Ruttkamp. I have set the config to something like this: [quote] [General] SUBNETMASK=255.255.255.0 NODETYPE=8 ; Hybrid LEASETIME=86400 ; lease time of 1 day [Settings] IgnoreUnknownClients=1 ; replace X with MAC ADDRESS from the lan/wan card to which you want your secondary computer to connect [XX-XX-XX-XX-XX-XX] IPADDR=192.168.2.3 SUBNETMASK=255.255.255.0 ;this is the address my card is always setting for the router ROUTER_1=192.168.2.1 DNS_1=192.168.2.1 [/quote] and now i can relax and enjoy a decent internet connection EVERY time! I hope this helps dudes,
May 5th, 2010 9:06pm

This cannot be correct. It is a very standard way to use a VPN to only route SOME traffic, not default traffic, to it. Having all Internet traffic and browsing pass through the VPN is sometimes done but seldom desired on a corporate network. This is a very basic way to use a host-based VPN client and definitely not an oversight that Microsoft should have made.Sys Admin
Free Windows Admin Tool Kit Click here and download it now
July 3rd, 2010 8:18pm

I totally agree with Jason, Scott and the others. Users should have the ability to change the attributes of the network associated with the OpenVPN connection (or any similar type of network that is mistakenly marked as an "unidentified network"). We should be able to identify it, name, change the icon and change the location from public to private (home or work). Furthermore, we should only have to set this information once instead of every time we open the connection. That is, our attribute changes should be persistent. Okay, I sort of understand what Microsoft was attempting to do here. I think they were trying to protect unsophisticated users like my mom from accidentally opening up their firewall when connected to a public network. If Windows can't identify the type of network, it defaults to the safest -- public. I get it. However, I'm running Windows 7 Professional , not Home. Therefore, I should know what I am doing. Thus, I should be allowed the opportunity to change these settings if choose to do so.
January 11th, 2011 1:51pm

You can also just enter the following in your client's OpenVPN config file: route network/IP [netmask] [gateway] [metric] Example: route 0.0.0.0 0.0.0.0 192.168.38.0 50 After I did that I connected as a private network without any prompts.
Free Windows Admin Tool Kit Click here and download it now
March 19th, 2011 2:59am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics