Wirey.com

Earlier this evening I got a text message from a colleague saying he was having trouble getting his new corporate laptop working on his home WiFi network. This colleague works in sales at VMware, hence I reasoned it would probably be something basic that would only take us 5 minutes to troubleshoot, so I gave him a call. 😉

I suspect many of you reading this know how these things go; you start off ascertaining what OS you’re dealing with, move on to getting them to click various components of the GUI, before progressing to some command-line stuff.

In this case, the WiFi connection was sound; the adapter was receiving a DHCP lease, and we could ping IPs on the Internet.
However, we couldn’t ping the router, or get the router to respond to DNS queries.

I was moments away from manually configuring a known-good external DNS server when I thought we should venture into a quick look at the routing table. As tough as it might be over the phone, I got my colleague to read out the entries from his “route print” output.

This revealed a few entries I didn’t like the sound of – several for 192.168.1.0/24 (the default internal subnet used by his router). So, I got him to read out his full ipconfig output – suspecting something might be up.

Sure enough, it turned out VMware Workstation had randomly chosen 192.168.1.0/24 as the subnet to use for the VMnet8 (NAT) network. I assume that when the machine was first built it was on a corporate 10.x.x.x network. So when Workstation randomly chose a couple of /24s from the 192.168 range to use for VMnet1 and VMnet8, 192.168.1.0/24 was available – but choosing this means clashing with perhaps the most commonly used private IP range in the world.

For those not familiar with VMware Workstation, it supports up to 8 virtual networks and provides a DHCP service which can run on these networks to allocate IPs to VMs connected to them. At install (or first run) it randomly selects two /24 ranges from 192.168.0.0/16 (e.g. 192.168.114.0/24) for use on these virtual networks.

A quick visit to the Virtual Network Editor (Start / All Programs / VMware / Virtual Network Editor) allowed my colleague to change the subnet used for VMnet8 to another /24 range – and the problem disappeared.

Certainly one to chalk up to experience!

In my view, Workstation should avoid using this specific subnet out of the box – I’m sure it must catch out a fair few users (who seemingly have a 2 in 254 chance of having either VMnet1 or VMnet8 picking this range).

Please let me know (leave a comment) if you’ve also suffered from this issue.