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!?
Comments
Post a Comment