Saturday, 26 April 2014

A Tip on Managing Multiple Subnets in VMware Workstation

Often when I’m playing around with my labs in VMware
Workstation*, I need to use many different subnets. Trying to manage multiple
subnets using the “Virtual Network Editor” I’d always found was a bit of a
chore. So - since I just happened to be setting it up again - I thought I’d
share how I’ve been doing it.

*I’m still using
VMware Workstation 9, not yet upgraded to 10.

In Virtual Network Editor, I simply have two VMnet’s:

- VMnet0 is
bridged to my home network

- VMnet1 is a
custom network - no NAT, no bridging, no host connection, no DHCP, and it’s
totally irrelevant what the subnet is!

Image: VMware WkS 9
- Virtual Network Editor

In fact, since I don’t use VMware Workstation’s DHCP or
NAT services, I disable them in services.msc.

Image: Services -
VMware DHCP Service and VMware NAT Service disabled

All of my VMs are configured on the VMnet1 network, except my special one, my ROUTER.

The ROUTER is simply a Windows Server 2003 VM (actually
R2 SP1.) And it is configured with VMware Workstation 9’s maximum of 10 network
adapters. 1 of the network adapters is on VMnet0
which is bridged to my home network. The other 9 network adapters are in the VMnet1 network.

Image: VMware
Workstation ‘ROUTER’ with 10 Network Adapters

When the ROUTER VM is powered up, I manually configure an
IP address on all the network adapters.

The bridged
adapter - is given a static IP addresses on my home network.

The other nine
adapters - are configured as the default gateways for up to 9 other VM network
subnets as per requirements.

Note: Only the
bridged adapter has default gateway and DNS configured.

The Network Connections are renamed to clearly identify
their purpose - as in the picture below.

Image: 10 x Network
Connections on VM ROUTER

Configuring the Windows Server 2003 box as a router with
the ability to do NAT is a doddle.

In the ‘Routing and Remote Access’ MMC, right-click your
server name (ROUTER in this instance), and then click ‘Configure and Enable
Routing and Remote Access’

Image: R&RA -
Configure and Enable Routing and Remote Access

Routing and Remote Access Server Setup
Wizard: Welcome...

Click Next >

Routing and Remote Access Server Setup
Wizard: Configuration

Select ‘Custom configuration’

Click Next >

Image: R&RA
Server Setup Wizard Configuration options

Routing and Remote Access Server Setup
Wizard: Custom Configuration

Tick the boxes -

‘NAT and basic
firewall’

‘LAN routing’

Click Next >

Image: R&RA
Server Setup Wizard Custom Configuration options

Routing and Remote Access Server Setup
Wizard: Completing the...

Click Finish

And then click ‘Yes’ to the “The Routing and Remote
Access service has now been installed. Do you want to start the service?”

Image: R&RA ...
start the service?

And that’s all you need to do to get your inter VM
networks to communicate with either other. The router acts as the gateway for
these networks and passes the traffic from subnet to subnet.

Image: Interfaces
in Routing and Remote Access

We’re not finished yet though!

So, you’ll probably want to connect to your VMs from your
workstation or home subnet (in case you’re wondering why not simply use a HOST
connection in VMware Workstation to get to the VM Networks, well, I certainly
could, just had some oddness in the past with host connections - the statically
assigned host IP kept failing to an APIPA address after rebooting my
workstation - which is one of the reasons why I do it this way.) Your
workstation will need a route to get to these networks.

As an example to
configuration:

We have a VM network 10.0.0.0/16. Our ROUTER is
configured on 192.168.0.254. So, we need to configure out PC with a route to
10.0.0.0/16 via 192.168.0.254. To do this from the DOS shell type (the -p makes it persistent across
reboots):

route
ADD -p 10.0.0.0 MASK 255.255.0.0 192.168.0.254

An example of my
output (abridged for brevity) is below, where I also check the route, and check
I can ping something on the 10.0.0.0/16 subnet:

*This is not
necessary for what we want to do - I tend to do it all the same!

Image: R&RA
Network Address Translation Properties

And now we’re completely finished! Our VMs can talk to
each other on different subnets, we can talk to our VMs from our home network, and
our VMs can talk to the outside world.

But wait ... when you enable NAT, from your home network
you will not be able to talk to your VMs. This could be fixed by enabling the
host connection in VMware Workstation’s Virtual Network Editor and not
configuring static routes in DOS. Personally though, I quite like this - I don’t
want my VMs talking to the internet unless I’ve got a specific reason to let
them. To re-enable access from your home network to your VMs simply right-click
the interface under NAT/Basic Firewall in Routing and Remote Access and click
Delete.

Image: R&RA
deleting a NAT Interface

Note: If we had
SNAT (Source Network Address Translation) in Windows Server 2003 R&RA, we
could have our cake and eat it (VMs connecting to the internet, and us
connecting to them from our home networks.) Perhaps it’s about time I found a
replacement for my tried and trusted 2003 R&RA!?