Buggy Windows 8 network charms - works from command-line!

I have struggled with two network related problems on my older laptop for some time after upgrading it to Windows 8 and later 8.1. Both problems occur when I try to go to the Settings charm (Winkey+I), in the submenu under the networking icon (upper left of the icons). Both however seem to have one very simple workaround: Using the command-line equivalents.

Problem 1 - Connect to WLAN: Sometimes, registering to a known WLAN does not work, or the connection is randomly or immediately lost after being registered. Sometimes, the desired WLAN network is not even visible in the networks list, although any other WLAN capable device (e.g. a phone etc.) can find the WLAN in question.

Solution 1 - Connect to WLAN from the command line: For some reason, connection works great when doing it from the command line. To see all avaiable WLANS:

netsh wlan show networks

Issue the following command to connect to one of them:

netsh wlan connect name=WlanName

-where WlanName is the name of the WLAN. Observe that this name is case sensitive!

Those are the basics - explore other possibilities by using the help system (a ? sign  will give you available commands).

Possible mitigating factor to this problem: I am using an Intel 4965AGN network card, which some suggest is not supported under Windows 8. However, the Windows Compatibility Center suggests otherwise - at least for Windows 8 (while 8.1 is marked with "no info"). I have had bluescreen problems with both the Windows 8 native driver and the latest Intel driver, but the latest Dell driver works for me (version 12.4.3.9 dated May 28, 2009) on my Latitude D830 without bluescreen problems.

Problem 2 - Connect to RAS (PPTP) connection: When trying to connect to one of my RAS connections (VPN to another location), sometimes I loose the WLAN connectivity even by clicking the desired RAS connection on the Settings-networking charm, without even clicking its Connect button that will now be displayed. Needless to say, when my WLAN is gone, so are my chances to connect to the RAS connection. I am stuck.

Solution 2 - Connect to RAS from the command line: Again, performing the same task from the command line succeeds without any hassle. Here's the command:

rasdial "RAS connection name" username password

More information about problem 2: What happens when clicking the RAS link, seems to be that the WLAN Extensibility Module crashes and logs an event 10003 and an event 10000, "WLAN Extensibility Module has failed to start" with a reference to the file IWMSSvc.dll and an error code 1726

SyncBack hang/freeze on Windows 7 - SMB version problem

Problem: SyncBack Free is a brilliant free tool for synchronizing two folders' contents fast and accurate. I had been using a Windows XP computer with two network cards standing as a bridge between two networks to sync folders between two computers residing on each side of the bridge. Old of age the XP computer were looking forward to its retirement as a young Win7 computer were set up to take over its place. The same SyncBack running the same SyncBack profile on the Win7 computer completely hung the SyncBack process within seconds after syncing was attempted. Only a reboot would kill the process - not even Task Manager managed to take it down.

Factors in the picture:

• The two remote computers were running Win7  and Server 2008 R2.
• Syncing between a local folder on the Win7 computer and one of the remote computers would work. Just not syncing between the two remote computers.
• It made no difference whether Windows Shell (on the Copy/Delete tab) was used to sync or not.
• Copying files between the remote computers from Windows explorer works just fine.

Problem reason: The reason proved to be SMB version. WinXP uses SMB 1.0, whileas Win7 uses SMB 2.0. For some reason, SyncBack does not manage to copy files between two remote computers as long as the computer is set up to use SMB 2.0.

Solution: Disable SMB v. 2.0, forcing the Win7 computer to revert to using SMB 1.0. This excellent article on Petri explains how - or here in short: From an administrative command line window run the following commands and then reboot to activate (Observe that "bowser" is actually correctly spelled - or rather, it is spelled the way that the computer understands):

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled

If you need to revert to SMB 2.0, use the following commands:

sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc config mrxsmb20 start= auto 

I have not put any effort into researching whether security is an issue with these settings or whether other functionality is negatively affected, for me it gave me what I needed, so I am happy.

Cannot connect to any computer except DC

Problem: The only network traffic (ping etc.) that could pass in a Win7/Server 2008 R2 domain was from each client computer to the domain controller. No client computer could contact each other. Even the domain controller could not initiate contact towards a client computer.

Reason: In the Server 2008 R2 active directory domain organizational unit (OU), a Group Policy Object (GPO) had been created to disable the local client's firewall and allow any network traffic (which was ok from a security point of view, since the network was completely disconnected from anything outside). When applied, the firewall was indeed not started, but somehow the idea backfired by blocking all but those client computer connections made to the DC.

Solution: The Firewall service was reenabled in the GPO:
Policies-Windows Settings-Security Settings-System Services-Windows Firewall-Startup type=Automatic
Instead the Firewall setting was set to off for the domain profile (which is the active profile for computers within a domain):
Policies-Windows Settings-Security Settings-Windows Firewall with Advanced Security-Domain Profile Settings-Firewall state = off

It seems absolutely illogical to me that switching off the firewall service would block most network traffic. Maybe some special case in my domain caused it - nevertheless, there was no doubt that my changes were the solution to my problem - even proven by the fact that reversing them would lead to reintroducing the problem.

Cannot set fixed IP

Funny problem: Set the fixed IP of a network interface - once you have clicked OK back out of the network interface properties dialog box, it reverts to an automatically assigned IP of 169.254.x.x. Go back into properties for the network interface, and IPv4 settings still holds the static IP you set. It is not possible to ping the interface on that address, and ipconfig shows only the automatically assigned address.

I had this problem on a Windows Server 2008 R2 today, and spent a fair amount of time troubleshooting it, including running Windows Update, several reboots etc..

Solution: In the end, I uninstalled all network interfaces found under Network Interfaces in Device Manager (right-click Computer > Manage > Devices) and then right-clicked the device root and selected "scan for hardware changes" to automatically reinstall the network interfaces. Voilla, the IP settings now sticks and actually works!

Possible reason: I am not sure what messed up the system, but my main suspect would be a special high performance frame grabber driver from Pleora that was installed on this server for two other network interfaces (not the one I was trying to set the IP on). This driver obviously digs deep into the device hierarchy, because it removes the network interfaces it controls out of the Network Interfaces tree entry in Device manager over to a new tree entry called "Pro/1000 grabber devices".

Anyways, I got my solution - now it works!

ISP blocking ports

Unless you are a customer of the Norwegian ISPs Get or Telenor, this post will only be a general guide to what your ISP might or might not do to your connection. It should be a part of your consideration when troubleshooting an internet link that does not seem to do what you think it should.

After transferring from Telenor to Get as my internet service provider, I noticed that some of my mail accounts would not let any mail through anymore. As I discovered, there were no response from any SMTP mailserver but one, namely Gets own SMTP server. Telenor also blocks communication to other servers than their own over TCP port 25 (SMTP), but at least there is a choice to switch this extra filtering off via your user webpages. When contacting Get about the same feature, after a loong wait, they responded that they are blocking all of the following ports to their customers:

21          TCP         FTP         In
25 *        TCP         SMTP        In and out (except Get)
69          UDP         TFTP        In and out
80          TCP         WEB/http    In
137-139     TCP/UDP     NetBios     In and out
161         UDP         SNMP        Out
548         TCP         AFPoverTCP  In
12345       ICMP/TCP    Netbus      In and out
27374 *     TCP         ASP         In and out

ASP above means Address Search Protocol, not Active Server Pages, in this list.

It is an annoying fact that this info is not available on all ISP's webpages (e.g. under FAQ or a technical info section) that runs such a practice - you have to beg for it. If you have higher requirements than mainstream web browsing and mail via your ISP's own servers, it is better to check with your potential new ISP before moving your business there and find out later that you have not gotten the connection you need.

If you need to run your own web, SMTP or FTP service over standard ports (running them on unstandard ports are of course no problem), and you have an internet provider that does not think that your internet conection should be fully open and your own responsibility, you could use services like the free DynDNS to get traffic in and out.

References:
Telenor's info on blocking/opening SMTP port 25 (Norwegian)
Get's only info on the subject - not much (Norwegian)

XP Firewall option "My network (subnet) only" blocks traffic from local subnet

Problem: The weirdest problem occurred on a Windows XP Service Pack 3 computer: I changed a firewall rule scope from "Any computer" to "Local subnet only," only to find that the service did not accept traffic from my local subnet anymore. I started investigating, and ended up testing several different services and ports. The same thing happened: Once the port or service had been restrained to the scope "My network only", no traffic from comptuers on the local subnet was allowed through.

Symptoms: I noticed first because I tried to ping the computer. The name was not resolved, because the UDP 137 port (part of the File and Printer sharing entity) for NetBios name resolving blocked when set to "my network only" scope. Same thing happened to the VNC server service - once the 5900 port or the VNC server service was set to "my network only", it was no longer possible to connect to the comptuer from another local host.

Resolution: Sifting through probably a few dozens of webpages left me empty handed. At the end, I decided to rebuild the firewall settings from scratch by clicking the "Restore default settings" button of the advanced tab in Windows Firewall. When I now selected a "Local subnet only" scope, it worked like a charm. My firewall configuration was obviously messed up and needed a reset.

Reason: Who knows?

Apart from understanding what went wrong, the hardest thing in such a situaiton is to know when you should stop wasting time searching for the reason and resort to a tedious rebuild of firewall rules. Most boring: I still do not know what had went wrong, only what solved it. :(

ICS (Internet Connection Sharing) disturbed by VPN client software

Setup: [Computer]---[ICS Computer]---[Internet router]---Internet
The ICS Computer runs Vista, Computer runs Windows XP, Windows Server 2000 or any other.
The ICS Computer also has one or more VPN client software packets installed. In my case, the Checkpoint SecuRemote VPN client and AnchorFree HotSpot Shield were installed, but not running at the time where this problem occurred.

Problem: Computer can not browse websites, Skype will not log on, FTP to internet FTP servers will not work. Computer can however ping all destinations, local as well as internet addresses using DNS names or IP addresses.

Obviously, some (ICMP/ping and DNS requests), but not all of the network traffic is correctly passed through the ICS Computer. After having played around with disabling any firewall on Computer and ICS Computer without any improvement, i tried the following:

Solution: I removed the two software pieces known to create virtual network interfaces on the ICS Computer, hence the CheckPoint SecuRemote and AnchorFree HotSpot Shield had to go. Reboot, and voilla, it worked!

Prime suspect: Since the AnchorFree HotSpot Shield was still wanted on the system, I reinstalled it. ICS still works, bringing me to the strong assumption that the CheckPoint SecuRemote was the one that messed things up.

The Nerd's little blowout: I have been working with a variety of VPN software client solutions, like Cisco, CheckPoint, RSA etc.. In my experience, they all have in common that they in various forms deprive you of an unrestricted simultaneous access to other network segments that are normally accessible from your computer. Try connecting a VPN client and at the same time access your local LAN server. You have luck if it works. Try reaching two different remote sites over two different VPN clients at the same time, and you may even see the good old bluescreen of death. Try running ICS to let another computer connect to the internet on a computer where VPN client software is installed - you get ping and DNS and nothing else. Now THAT's why I'd rather have any VPN link over site-to-site VPN on dedicated VPN routers.

Tunnelling a subset of a routed subnet on a Juniper Netscreen

(This post assumes that you have a general knowledge of setting up a Juniper device for VPN tunnelling).

The following chain represents my setup:

(internet) --- [Internet router] --- [Juniper Netscreen] ---(LAN)--- [Router] ---(General 10.0.0.0/24 network segment)---

On the Juniper device*, this means that a route of 10.0.0.0/8 is pointing towards Router. In addition, a default route is pointing towards Internet router, allowing for comptuers on LAN (which has the Juniper device LAN IP set as their default gateway) to reach both the 10.x.x.x computers behind Router and to reach internet destinations.

Now I want to create a VPN tunnel over the internet to some other place, tunnelling to that place's internal network 10.10.10.0/24.

Problem: Because of the route of 10.0.0.0/8 is pointing towards [Router], even packets destined for 10.10.10.x-addresses are routed that way. Normally on a Netscreen device, having set up policies for the VPN traffic is enough to route through the tunnel, but routing entries seem to take presedence over policies.

Solution: Set a Metric higher than 1 (e.g. 10) for the 10.0.0.0/8 route. Then create a route of 10.10.10.0/24 pointing towards the [Internet router] IP address (this would be the same as your default gateway points to, of course a public IP address). The 10.10.10.0/24 route will by default receive a lower metric and therefore have priority over the 10.0.0.0/8 route.

Gotcha: Of course, this means that you will not be able to reach 10.10.10.x computers on the network behind Router. You literally can't have it both ways...

* I have done this on a Juniper Netscreen 5xp, but I would assume this would work on all Juniper devices, for instance the successor Juniper SSG.

CheckPoint VPN keepalive kills the tunnel

I had the strangest experience when setting up a CheckPoint VPN device the other day. The tunnel built fine, but sometime between a few seconds and 1-2 minutes after coming up fine, it logged a "no proposal chosen" and went dead again. I researched every parameter with no luck, until I came to a checkbox on the last screen of the CheckPoint's VPN tunnel wizard stating something like "Keep this tunnel alive." Naturally I had wanted to keep the tunnel up, so I had checked it.

Funny thing, not until I cleared it again, the tunnel became rock stable. So, as long as you don't ask it to, it keeps your tunnel alive. I guess it just does not like being pushed around...

How to talk to a remote device that only talks to local network devices

I was asked to find out how to spare an engineer the trip to his customer abroad only to do a five minute's upload job to a device that was talking TCP/IP. The device was on a subnet that had a VPN site-to-site connection to his office, however, the device did not have a routing entry making it aware of the subnet on the other side of the VPN tunnel.

Because of limitations to the device, configuring the needed routing entry into the device was not an option, even if we were able to telnet into the device from a Remote Desktop session on a Windows computer on the same subnet.

Solution: The solution was to create a simple PPTP VPN dial-in access on that Windows computer, so that the engineer's computer could receive an IP from the same IP pool as the device he wanted to control. Yes, it meant creating a PPTP VPN tunnel back through the established site-to-site VPN tunnel, but it would work.

Caveat: Only trouble was, it didn't. Setting up a simple Routing and Remote Access server in Windows Server 2003 is a simple task, still, it just did not work. What I found after scratching my head pretty sore was that the firewall in the site-to-site VPN device on my side (the one responsible for the "outer" tunnel) was blocking all traffic that did not originate from my subnet. The PPTP GRE protocol packets from the remote site did not look like they were talking to established traffic from my side, and hence was blocked, effectively blocking the creation of the PPTP tunnel within the site-to-site tunnel. To make it work, I had to open the firewall on the site-to-site device to allow full traffic flow while running the PPTP tunnel.

After that it worked, but was quite slow, probably due to the double encrypted, double tunneled packets.

Narrow-masked site-to-site VPN caveats on a Checkpoint device

I consider myself to be relatively experienced in setting up site-to-site (LAN to LAN) VPN tunnels, and to pinpoint what is wrong if the tunnel does not come up, but working today with a technician on the other side of the Atlantic to set up such a link turned out to be a challenge.

We had agreed on all cryptographic parameters, on what private subnet to be used on each side of the tunnel and of course the preshared key. The guy in the other end seemed experienced enough, but going over and in a structural manner fiddling each parameter to try to find a match did not give the break. The scenario was quite funny:

Scenario: Tunnel clears phase 1 of the negotiation, meaning that the preshared key and the IKE parameters are a match on both sides. In phase two, some discrepancy makes a "no proposal chosen" message appear in the logs on the Checkpoint.

Strange: Even though the tunnel did not come up on the Checkpoint side, it did on mine. I was able to ping devices on his side, but he was not able to ping my side.

Solution: After having tested virtually everything, the guy on the other side mentions that his device has defined a class B private network on the interface. The tunnel definition, however, was to be for a much narrower range, a 29 bits mask (255.255.255.248). Although it would be shooting sparrows with a cannon, we broadened the tunnel definition to match his device's network interface, and voilla, it worked! It seems to be a limitation of the Checkpoint device this guy was using (or a limitation of knowledge on how to configure this device correctly) - I have without trouble set up dozens of other links with a narrower tunnel IP range than what the device is running on its network interface.

Caution: If someone else experiencing a similar problem is reading this, my advice would be first to check any firewall that might be blocking traffic (it was my first guess). If you can temporarily isolate vulnerable parts of your network while testing your new tunnel, I would first bring up the tunnel with the firewall completely off.

Fileshares: Connecting with the wrong hostname

Situation: Occasionally I need to connect to servers with names formed from a spoon of alphabet soup - impossible to remember. Of course, since the customer is always right, he gets to choose the names of his own server. I however, need to refer to computer names I can remember or that has a meaning.

Workaround: Put an entry in your hosts/lmhosts file (in the c:\windows\system32\drivers\etc folder), or if you have access to the DNS or WINS server, put the entry there, using your preferred name and the IP of the server you want to reach. If, for instance, a server is named something like SA823SX3B and you want to name it FILESERVER, just put in an entry for FILESERVER with the SA823SX3B's IP. It works for ping and many other services, but:

Problem: This does (by default) NOT work if you want to connect to a NetBIOS fileshare. You can verify that firewalls etc. is not the cause of this problem by connecting via \\SA823SX3B\fileshare and even by using \\192.168.0.1\fileshare (given that that's the IP of our example server).

Solution: You need to hack the following registry key on the server in question:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\
DisableStrictNameChecking

Set the value to 1 and reboot. You can now connect to the server using any name you please, as long as it is referring to the right IP address.

Caveat: On a NT4 computer, you will still not be able to connect without using either the real name or the IP address as reference.

See Microsoft KB 281308 for a description of this parameter.

Which Default Gateway is default?

This is kind of a lightweight post, but still nice to know:

Scenario: I wanted to configure a new VPN device using my laptop. The laptop uses wireless to connect to the company LAN and the internet. I would use the wired network interface to connect to the VPN device to configure it.

Problem: Once the VPN device is connected to the wired interface, all traffic destined for the internet insists on being routed through the wired, not the wireless connection. That's a problem when the wireless interface is on the subnet where internet can be reached.

Dead end: I tried to go to Control panel-Network connections, selecting Advanced-Advanced settings from the menu, to set the wireless interface on top of the "connections" list. This did not work - it would only have worked for network services like file sharing etc..

Clue: Using the command-prompt command "route print" (listing the current routing table of the computer), I can see that the computer has chosen the default gateway (given over DHCP by the VPN device) on the wired interface as default. The default gateway given by the company LAN DHCP server over the wireless interface has a higher metric (30) than the wired interface gateway route (20). Result: Wired interface default gateway becomes the computer's first choice of gateway.

Reason: So I need a way to change the metric of the default gateway defined on the wireless network interface. On Microsoft Knowledge Base, I found article no. 315088. It explains that Windows assigns metrics based on the connection speed. That's normally fine, but it did not tell me how to accomplish what I wanted. The referenced article no. 258487 however does:

Solution: I opened the wireless interface network properties, selected the Internet Protocol and opened its properties, clicked advanced, and manually overrided the Adapter Metric by setting it to 15.

I could set up my VPN device and stay online on the internet while doing it, however I reset the Adapter Metric when I was done. I think Microsoft's assumption that the faster interface should be preferred is generally a good idea, only not in this case!

MTU too large, communication stalls (under research)

I have been researching this problem for some time now, found a workaround, but no problem reason and no good permanent solution:

Environment and problem: LAN1 is connected to LAN2 via a LINUX PC with two network interfaces, running NAT in both directions. On LAN2, a VPN device has a site-to-site VPN tunnel over the internet to a remote LAN3. When computers on LAN1 tries to talk to computers on LAN3, it works well on some computers, while on others, all comms stalls after a few packets. There are other LANs connected to LAN2 via the same VPN device where the problem never occurs.

Clue: When connecting to LAN2 over a VPN client from a remote location, the communication to LAN3 always works.

Technical details: Using the Ethereal Wireshark network protocol analyzer, a bunch of TCP DUP ACK messages occurs around the time of the freeze.

Workaround: On computers where this is a problem, if the MTU value of the network interface used is modified to 1300 (or 514 hex), the problem goes away. This is done here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ID for Adapter
For a reference on this value, see Microsoft Knowledge Base art. no. 314053.

Potential negative effects of workaround: Smaller MTUs cause more network overhead because smaller and thereby more network packets must be transmitted, all with their own network packet header. In practice though, I could see no negative effect in my case.

Problem cause: Not found. The MTU that should have been used for the overall transfer should have been determined by the lowest MTU given by any router along the path the packets take. My assumption is therefore that some router "out there" is set up with a MTU larger than the network packet size it can actually handle (is this possible?). It works for the first few packets, then the router gets overloaded and freezes.

Permanent solution NOT found: A permanent solution where the MTU value of each client computer is untouched has not been found. Given that my assumption is right, a permanent solution can only be found if the router working under false MTU conditions can be identified and accordingly modified.

Further research: I want to try setting the MTU of the interfaces on the LINUX computer that routes between LAN1 and LAN2 to 1300. If my theory holds, this should lower the overall packet size so that the problem goes away. Since traffic load between the two LANs are never significant, it is acceptible in my case to live with that, even though it does not address the problem at the router that I assume is causing the real problem.

UPDATES ON MY RESEARCH WILL (may) FOLLOW