Win2012 Dedicated Server - One Nic - Multiple VMs - Multiple WAN IP's?


I was wonder whether someone could sense check this for me. I have a friends business who has acquired an internet facing dedicated server. He has asked me to set it up in a IaaS type solution for a directory server, mail server, web server etc.

As it is completely internet facing which no dedicated hardware firewall in front of it. I have decided to virtualize the setup, which should also offer some increased security.

The hypervisor itself has a windows firewall enabled and fully closed for incoming connections currently. It has a single public IP currently assigned to it's nic directly, but we have 3 more IPs available.

Firstly, is the setup I have briefly synopsis-ed on the attached diagram possible with only one NIC in the server?

Other questions I need answering.

How do I get the other public IPs through to the VM's? Does the there need to be NAT setup somewhere, and if so where? On the 2012 box or the debian firewall vm?

Are my usage of vSwitch's correct and their function right? (Internal, External etc)

Would it be best to give the VM's local private addresses and NAT through or give them WAN ip's and setup some routing?

Any help would be much appreciated on this.

Who is Participating?
Then Probably you can setup physical windows box other than Hyper-V and configure NAT there (TMG can be considered)
But personally, I never recommend to use server based NAT, rather than some sort of network device which can provide NAT functionality is highly recommended.

1st of there is no explicit NAT support for Hyper-V
In Microsoft virtual PC it does direct support for NAT
Also do you really require all VMs to have public IP addresses ?
Then you need to install RRAS on hyper-V server to enable NAT functionality
If you have 3rd party firewall device (Debian), then its more easy than setting up NAT through RRAS.
Then you can have internal IP addresses on all physical adapters and all virtual adapters as well and bind them with public IPs through firewall (NAT).
All you need to do is to setup external VSwitch for all virtual machines pointing to physical network adapters.

Check below article for more info.

Hope that helps

SimonBrookAuthor Commented:
Thanks for your response. I think you may be misunderstanding the setup? Did you look at the attachment?

Many Thanks
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

Cliff GaliherCommented:
First, your diagram has an inherent (but common) flaw that understandably makes trying to plan your architecture unnecessarily complicated. So I'll go ahead and try to explain that.

As far as fixing the flaw though. Well, there are several topologies you could employ. Each would have pros and cons. So delving into all the possibilities would really go well beyond the scope of what is possible in a forum like EE. The best I can do is tell you what is wrong with your existing diagram and you can probably use that to help generate a few ideas of your own. If that doesn't work, you'd be better served pulling in a paid contractor who specializes in such things.

Speaking of flaws, it is also worth pointing out that this statement is simply factually wrong:

"As it is completely internet facing which no dedicated hardware firewall in front of it. I have decided to virtualize the setup, which should also offer some increased security."

Virtualization itself provides *no* additional security over running a bunch of physical servers or a single front-facing server with all the software installed without virtualizing. So you should consider that when architecting your plan as well.

Now, on to the diagram:

You have your "physical" datacenter installation listed outside of the "hyper-v" box and a single connection going to the physical switch. This is a common representation, but is not accurate, and therefore makes your diagram incorrect in a meaningful way in figuring out network traffic.

When you install the Hyper-V role, the hypervisor is installed very near the hardware. The existing OS is, for all intents and purposes, a VM just like the others. While this VM does have a few unique qualities, it is still a VM. So in your diagram, that shouldn't be outside the Hyper-V box, but inside of it.

When you create an "external" virtual switch and assign a NIC to it, that NIC is a port on the virtual switch, pure and simple. From a diagramming point of view, this is no different than if you had (because of company growth or whatever) two physical switches connected together with a cross-over cable or by connecting to ports that support built-in cross-over.

So in your diagram, you have a virtual switch that happens to have one physical port. The connection on that virtual switch goes out, not to the physical OS, but directly to whatever equipment it is connected to (cable modem, DSL, another switch, etc) and operates at the layer 2 of the OSI model.

The "management" VM, as well as any other VMs, are plugged into virtual ports on the same virtual switch. So when you assign an IP to the management VM, you aren't assigning it to the physical NIC of the computer. You are assigning it to the virtual NIC of the management VM.

Again, from a diagramming perspective, this greatly simplifies the visualization and makes it fundamentally no different than if you were running physical servers. If you plugged your DSL modem into a switch (some DSL modems have switches built in) and configured it so it wasn't doing NAT, you could connect physical machines to the same switch and give them each a unique public IP. As long as the modem is aware it needs to route traffic for those IPs, and the ISP is also configured for the same, this all just works. No NAT involved.

In Hyper-V, this is no different. Plug the modem into a switch (even a virtual switch via the physical port) and then assign a public IP to each VM. The vSwitch operates at layer 2, so this all just works. There is no special routing or NAT happening on the (formerly physical) "management" OS. Remember, that OS is a VM as well, and is actually plugged into the vSwitch just like the others.

Now, if you have more VMs than you do IPs, or if you want to set up a VM to provide some added security, sure, there are architectures that support that. And setting up multiple vSwitches can certainly provide a way to separate the traffic from one VM or set of VMs from others. But fundamentally, you still have to move that management OS from the outside and understand that it doesn't inherently control the flow of traffic as you currently have it represented.

Because of that, and because it will sit on whatever vSwitch you decide to configure it to, I would never personally put the management OS directly on the public internet. I'd at least be designing an architecture that protects all the management interfaces of the equipment in play, whether that be the management VM, or whether that is the management interfaces for smart switches (smart switches are pretty much a requirement for monitoring IaaS setups), and routers, as well as any other equipment that may be used to provide the services being offered.

Looking at major IaaS providers, you can see a similar architecture. Azure, Joyent, Rackspace, etc, may all offer VMs or similar services with public IPs, but you never see the underlying hardware. All of that is highly protected and *no* customers get direct access. You don't know if the slice you rent is running on server A, B, or C, and there is no good way to find out. Nor do you get to see how much load the physical server is running under. They completely segment the physical/management portion for their private control and use.

Since you metioned virtualizing as a security measure, I felt it supremely important to revisit that several times throughout my explanation as well as highlight things to consider to *actually* improve your security design. Especially in the era of "cloud," even a small security event can have dire consequences to a business and liability claims can skyrocket. your initial design is not something to take on lightly and is not something easily revisited and redone later. You really need to take the time and do so up front and with great care.

Good luck.

Yes, thanks.
I miss out schematic
But still I think my comment is OK
You can have 3rd party firewall out side Hyper-V server with private IP assigned to all Hyper-V physical networks and virtual machines as well and do NAT on firewall for exchange and web server with public IPs
Domain controller do not require Natted IP
in other words, terminate your public IPs on hardware firewall depending upon no of interface available on firewall.

SimonBrookAuthor Commented:
There is no hardware firewall. That being the point. Routing would have to be done on the dedicated server itself.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.