VMWare Fusion 5.0 and Remote Desktop (RDP) Port Forwarding

So, the dilemma with my previous post’s setup is that I now have two VM’s that reside on the same VLAN, and one of them is an AD.

The current problem is that I want to access the second (non-AD) server from the outside world, outside of the host machine.  Normally, this is a private VLAN and there’s no access, but you can configure port forwarding so that you map port 3389 (external host) to one of the statically mapped internal hosts (for me, located at 172.16.165.11).

Here’s the deal:

The file /Library/Preferences/VMware Fusion/networking appears to be produced by the VMWare Fusion networking configuration dialogs.  It appears to drive the creation of the files /Library/Preferences/VMware Fusion/vmnet8/dhcp.conf and /Library/Preferences/VMware Fusion/vmnet8/nat.conf.

The latter of these two files, nat.conf, contains the location where we need to change the NAT settings to allow port 3389 requests to the host to be forwarded to the private VLAN.  The problem?  This file is periodically overwritten by VMWare processes when VMWare is restarted, network configuration changes are made in the GUI, etc.

I don’t have a long term fix for you here -> I can’t find any answers online or in the documentation.  Ideally, you would make the changes to the /Library/Preferences/VMware Fusion/networking file, and restart VMWare or reset the VMware network stack, and the system would regenerate working copies of the nat.conf file.  The problem is the VMWare GUI doesn’t support port forwarding configurations, and you can “hand hack” the nat.conf file if you’re willing to backup you changes or risk losing them periodically.

Networking file sample (/Library/Preferences/VMware Fusion/networking)

VERSION=1,0
answer VNET_1_DHCP yes
answer VNET_1_DHCP_CFG_HASH 4DB1B0245BA0BF9FBCD5D55DA675F9D605B179EF
answer VNET_1_HOSTONLY_NETMASK 255.255.255.0
answer VNET_1_HOSTONLY_SUBNET 192.168.163.0
answer VNET_1_VIRTUAL_ADAPTER yes
answer VNET_8_DHCP yes
answer VNET_8_DHCP_CFG_HASH 946433F88FFC278E2E5B8A325353B972A0B5D762
answer VNET_8_HOSTONLY_NETMASK 255.255.255.0
answer VNET_8_HOSTONLY_SUBNET 192.168.58.0
answer VNET_8_NAT yes
answer VNET_8_VIRTUAL_ADAPTER yes
add_bridge_mapping en1 2

Basically, you can see there are no available settings for port forwarding.  None the less, this file is transformed by backend processes into nat.conf, which includes this snippet at the end:

[incomingtcp]

# Use these with care – anyone can enter into your VM through these…
# The format and example are as follows:
# = <VM’s IP address>:<VM’s port number>
#8080 = 172.16.3.128:80
3389 = 172.16.165.11:3389

I’ve added the last line to this file to map the RDP service into the VLAN’ed VM.  So, any RDP requests coming into my host machine will be redirected into one of my VM’s.

Once this change is made, you can reset the network interface and load these changes as follows:

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start

The only problem now?  This file is overwritten when restarting VMware, so I’ve backup up the configuration, and have a script that I quick rerun prior to starting the VM’s (copy over file, stop, then start the interface).  Clunky, but workable.  If you know a way around this, let me know….

Another way, BTW, to see this “overwrite” process is to simply run the configure command:

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --configure

This will blow away your nat.conf changes, which you’ll need to reset.

Working with Static IP’s, Virtual Networks, and Shared Internet Access in VMWare Fusion 5

VMWare Fusion 5.0 and Static IP’s for Windows AD and Client Machines

Here’s the problem. You have a two Windows VM’w (one of them an AD, another a server that uses the first as its Active Directory). You want these two VM’s to remain in synch, and they both must see each other on the local, virtual network, but you also want them both to be able to reach the shared internet connection used by your Mac). What now? You main challenge is ensuring that the Windows Server that isn’t the Active Directory (AD) won’t have name resolution issues.

Core Question: How can two servers on a private network both share the host internet access AND always see each other, particularly when one of those client machines is both an Active Directory (AD) as well as DNS server for the private network???

Step 1

Check the file dhcpd.conf in Library/Preferences/VMware Fusion/vmnet8. Find the following information:

subnet 172.16.165.0 netmask 255.255.255.0 {
range 172.16.165.128 172.16.165.254;
option broadcast-address 172.16.165.255;
option domain-name-servers 172.16.165.2;
option domain-name localdomain;
default-lease-time 1800; # default is 30 minutes
max-lease-time 7200; # default is 2 hours
option netbios-name-servers 172.16.165.2;
option routers 172.16.165.2;
}

Note that this VMware 5 instance is using 172.16.165.X as the private VLAN for VM’s.

This means that any address where X is between 3 and 127 can be used as static addresses for one or many VM’s. Meanwhile, your gateway should be 172.16.165.2, as this is the routing address.

NOTE: Your VM may use a different range of address, in which case replace 172.16.165 with your own address.

Step 2

Take VM #1 (your AD server), set the VMware Network Adapter to “Share with My Mac” (which is NAT, essentially). Configure the network settings as so.

IP:172.16.165.10
Mask: 255.255.255.0
Gateway:172.16.165.2
DNS Server: 127.0.0.1

Step 3 – Take VM#2 (your server that will access the AD server), set the VMware Network Adapter to “Share with My Mac” (which is NAT, essentially). Configure the network settings as so.

IP:172.16.165.11
Mask: 255.255.255.0
Gateway:172.16.165.2
DNS Server: 172.16.165.10 (note that we use the AD server as the DNS server).

This allows VM#2 to use the AD server for authentication and any DNS within your private network. This allows VM#1 to act as both DNS and AD locally, but passes through any other requests to the host system.

So, since you are now using static IP’s, when you VM’s startup, they can always find each other…. good news!