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.

Start > All Programs > Control Panel > Administrative Tools > Routing and Remote Access

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:

C:\DOS>route ADD -p 10.0.0.0 MASK 255.255.0.0 192.168.0.254
 OK!

C:\DOS>route print 10.0.0.0
...
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
         10.0.0.0      255.255.0.0    192.168.0.254       1

C:\DOS>ping 10.0.8.20

Pinging 10.0.8.20 with 32 bytes of data:
Reply from 10.0.8.20: bytes=32 time<1ms ttl="254<o:p">

We’re (still) not finished yet though!

Now you might want your VMs to be able to get out to the internet.

Routing and Remote Access > ROUTER (local) > IP Routing > NAT/Basic Firewall
Right-click in the empty ‘NAT/Basic Firewall’ pane and choose ‘New Interface...’

Image: R&RA - creating a NAT interface
Select your NAT interface and click OK.

Image: R&RA selecting a new interface for NAT

Then on the NAT/Basic Firewall tab -
Interface Type: Select ‘Public interface connected to the Internet
And check the boxes:
Enable NAT on this interface
Enable a basic firewall on this interface’*
Click OK

*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!?

THE END

... quite a long tip!?

No comments:

Post a Comment