In a future blog entry I plan to walk through many of the steps needed to setup a virtualized test environment running on a single, uni-homed host.  Throughout the process I’ve used a combination of online articles and blogs with input from colleagues to try and find the simplest hardware configuration which would allow me to deploy many different Microsoft products in an environment which closely mimics a typical enterprise.

While I’m still working on that documentation, one specific hurdle that is worth calling out separately is related to Internet Security & Acceleration Server 2006 which is the core networking component used in my lab.  Without getting into too much detail, I have ISA Server 2006 deployed within a Windows Server 2003 virtual guest machine which is multi-homed across three networks: two virtual networks controlled by VMware Server and a third virtual NIC bound to the physical host’s single NIC.

Because I’m running my test lab at home behind a broadband connection I’m limited to a single dynamic public IP address, so the individual networks are all using private IP address ranges, with natural-mask Class C addresses used on my physical Ethernet network as well as the virtual Internal Network.  An unnatural-mask Class B address range was configured for the Perimeter Network, as seen in this diagram:

Once I had ISA Server 2006 installed and deployed in the first virtual machine, I promptly used the 3-Leg Perimeter template to define the network configuration within ISA.  As it turns out this template is designed to be used in a specific scenario and caused major problems with IP routing when I used it with my network configuration.  After some research I discovered that the template is really meant to be used with a Perimeter Network that is configured with a public IP address range, NOT a private range.

The default behavior can be seen in the Network Relationship settings for the Perimeter Configuration and Perimeter Access network rules:

Traffic between the Internal Network and Perimeter Network is set to NAT (Network Address Translation) and traffic between the Perimeter Network and External Network is configured as Route.  This behavior assumes that a Private IP address range is used in the Internal Network and a Public IP address range is used in the Perimeter Network.

Because I was using Private IP address ranges in both of these networks I needed to flip the configuration of both network rules:

This configuration now allows the ISA Server to route all traffic between the Internal and Perimeter Networks without performing any unneeded Network Address Translation, while correctly translating the traffic between non-routable Private IP addresses in the Perimeter Network and the hosts in the External Network.  (Keep in mind that Firewall Policy rules will still be required to successfully route traffic between these networks, but the important first-step of connecting the separate networks is completed.)

It’s a simple configuration change that if over-looked will cause all sorts of problems when attempting to publish services to the Internet on hosts in the internal networks.