Monday, January 23, 2012

Using TMG 2010 with Hyper-V to support multiple Virtual DMZ hosts

EDIT: This post is receiving a surprising amount of hits, and is being debated amongst colleagues in forums, events and gatherings, in my attempt to reach some sort of consensus. So far it appears the community is (unevenly) divided, but through the discussion process I have been offered one alternative other than my own that meets my standards. More on this towards the end of this post. I've also made edits in Italics throughout the post, to illustrate the debate process and my reaction to it.


I've always wanted to do this and I am so happy I finally got down to it... turned out to be easier than I thought, too!

It all started with a need for a Lync Edge server for my Lab... I was already running a TMG server as a firewall/proxy with collocated Exchange 2010 Edge and thought I'd spare myself the expense of buying an extra server to use as a Hyper-V host and see if it was feasible to run Hyper-V on my existing TMG server and use it to host DMZ VMs. Is it something I would recommend for a production environment? It wouldn't be my first option, but I wouldn't discard the idea either.

(EDIT) Some people say that I should. It's a non-standard way of doing things, it's not an MS recommended topology (still haven't found any official indication that it's unsupported), and should be avoided at all costs. I say an engineer's job is to find solutions, and sometimes compromises need to be made. As long as the customer is aware of the dangers, and as long as I've exhausted all other options, if it's a working solution then I'll go for it.

If you look online there are tons of articles of how to use TMG 2010 with Hyper-V in a DMZ, but in a funky kind of way IMHO: You're supposed to have a Hyper-V host server with multiple DMZ VMs, TMG being one of them... which is fine if you're just using TMG just for Internet Proxying and Publishing internal sites.

What if you wanted to use your TMG as your firewall? You would have to weave an intricate web of VLANs on the Hyper-V host, assign them on the DMZ VMs, route traffic from these VLANs to virtual NICs on the TMG VM... if I was to graphically illustrate this, it would look something like:

It just looks wrong! And that's just for 4 VLANs, imagine what it would be like having more! There is apparently some disagreement with this (see but I beg to differ.

Physical separation is the basis of any DMZ design worth its money, and VLANing is no substitute. In fact a quick Google search will reveal tons of info on how VLANs can been compromised in intrusion attempts. And for good reason: a VLAN is a means of segmenting networks, not a security counter-measure. Here's a great article by SANS: More on this at the end of this article.

(EDIT) Overwhelming feedback on this matter attests to some Systems Engineers' lack of security awareness. This brings up a whole new issue, that of lack of role transcendence (something I've been meaning to blog about for a long time but never got down to it); IT Pros become overly entangled in their role and become dangerously close to perceive matters in a monolithic way. The distinction between Systems Engineers, Network Engineers, Security Engineers, etc, is OK as it serves the need for specialisation and expertise, but an awareness of all fields is paramount when designing an end-to-end solution. What is the point of having a DMZ if you're going to enforce network separation by using VLANs? It sounds like building a castle wall out of hay.

So here's my thought:

Couldn't we build a Windows 2008 R2 server with 4 physical NICs, install TMG 2010 and add the Hyper-V role on it, physically connect 2 NICs to the Internet and our LAN and assign the other 2 to be managed by Hyper-V Virtual Network Manager, then use TMG to route DMZ traffic to and from the Virtual NICs created by Hyper-V's VNM ??? It would look something like this:

The answer is we could, I have and it works beautifully!! Is it on a par with physical separation? No! Is it better than that other funky VLAN solution? A lot, because network separation and control happens at the hypervisor level which works at OSI layer 2 (just as VLANing is), BUT you also get the added benefit of OSI layer 3 to 7 vulnerability scanning BEFORE malicious attacks or malformed packets physically reach your internal network. Check the end of this article for a bit more info on this.

(EDIT) Apparently (and this comes from testing as I could not find any info online), the Forefront TMG Packet Filter takes precedence over the Virtual Network Switch Protocol. This ensures packets are grabbed and scanned by TMG before being handed over to Hyper-V.

So, let's begin!
I'm assuming you've already set up a Windows 2008 R2 box, installed TMG 2010 on it and set up basic routing and firewall rules. There are plenty of great articles on the subject out there. Make sure that routing and Internet connectivity works before you proceed.

Set up physical NICs on the TMG server as:
  • INTERNAL, connected to the LAN
  • EXTERNAL, connected to the Internet-facing router
  • DMZ External, NOT physically connected anywhere
  • DMZ Internal, NOT physically connected anywhere
Remember that only the EXTERNAL interface gets to have a gateway.

Your Network Connections should look like this:

Now add the Hyper-V role, open Hyper-V Manager and on the Actions column (right-hand side), click on Virtual Network Manager.

Click on "New Virtual Network" (left-hand side), choose "External" as type and then click on "Add"

Under "Name", type: "HYPER-V DMZ Internal"
Under "Connection Type" choose the NIC that corresponds with the "DMZ Internal" connection seen on the previous image. In this instance it's "Realtek PCIe GBE Family Controller #2"

Make sure the "Allow management operating system to share this network adapter" box is checked!

It should look like this:

Now do the same for the external DMZ:

Now click on OK.

After Hyper-V has done its thing, your Network Connections should look like this:

Note that while the physical DMZ adapters are disconnected, the Virtual NICs created by Hyper-V's Virtual Network Manager, appear connected. Had we used Internal or Private connection types in the Virtual Network Manager that do not require a physical adapter, routing outside the Hyper-V/TMG server would be impossible. Since we're not planning on using physical DMZ connections, this is how we achieve network separation on the hypervisor level (OSI Layer 2) without VLANs. Now we can use the Virtual NICs with both Hyper-V and TMG, and here's how:

First of all, create a VM with whatever attributes suits you (CPUs, RAM, disk type/size) but add only ONE virtual adapter to it at this time and assign it to the "HYPER-V DMZ External" Network.

Now start the VM and install Windows. Once Windows is installed, rename the Local Area Connection to "External", so you'll know which Virtual NIC it corresponds to. Now shut down the VM and open settings again.

Notice that although MAC ADDRESS is still on Dynamic, an actual MAC address has been assigned to the Network adapter. Now click on "Static" so the Settings window will look like so:

Click "Apply" and repeat for the "HYPER-V DMZ Internal" Network.

What have we achieved by this? Well, we've let Hyper-V choose an appropriate MAC address for our 2 VM adapters, so we are 100% sure there is absolutely no chance of a MAC address conflict. We also statically bound these MAC addresses to our VM so we're 100% sure they will never change. If they did it might trigger a spoof attack event on TMG and our VM would be blocked.

Now that we have our Hyper-V bit sorted, let's have a look at TMG.

TMG should already have seen your new NICs and set up Network Adapters like so:

Remember, we don't care about the disconnected Physical NICs, we're not using these at all.

Now, under "Networks" we need to declare both our DMZ NICs IP Ranges, and give them a name. That's how they'll appear in Firewall Policy rules.

Last but not least, we'll need to define the Network rules. Rule of thumb is: NAT anything that goes to the Internet, Route everything else:

And that's it, mission accomplished! Now it's just a matter of putting the appropriate Firewall Policy rules in place.

(EDIT) An increasing amount of people point out the fact that adding so many services to one Windows installation runs the inherent risk of a single point for multiple failures, i.e. if one service goes down the whole DMZ will likely go offline. I know this is true, but are we missing the point here? Our starting goal is not to build a rock-solid fail-proof solution, our starting goal is to make the best out of too little to begin with. Why go in the trouble of building a DMZ if your foremost goal is availability and not security? It truly beats the point!


There is a lot to be said regarding security in a DMZ which falls outside the scope of this article. For our purpose, I will stress the following security-related facts.
To understand security we need a basic knowledge of the OSI model. Here's a picture taken from (

Both VLANs and the Hypervisor operate at Layer 2 (the Data Link layer), hence in respect to separation they can never match physical separation which occurs at Layer 1. However, network separation is not everything. As we deploy security measures, the more OSI Levels we cover/inspect the better our overall security will be. And TMG is aware of OSI levels 3 to 7.

I will present some examples of security vulnerabilities per OSI layer to better illustrate my point:
  • Layer 3: IP Spoofing, RIP attacks, ICMP DoS attacks, Ping Flood, Ping of Death, Teardrop, Packet Sniffing
  • Layer 4: TCP SYN Flooding, Man-in-the-Middle attacks, Land attack, UDP Flood attack, Port Scanning, Fingerprinting
  • Layer 5: Session Hijacking, Brute-Force attacks on Session Credentials
  • Layer 6: Fake Certificate attacks, Man-in-the-Middle attacks
  • Layer 7: Application-Specific attacks
Now, having TMG operate as a firewall inside a Virtual Machine sitting on a Hyper-V host together with a number of other VMs with nothing separating it from internal servers but VLANs, means at the very least, that you allow potentially illegitimate traffic through your internal switches, disguised as tagged packets... Let's have a look at the diagram again:

Let's say that a request comes from the Internet for your Web Server; it travels through your router, gets tagged as VLAN4, travels through your LAN switches, reaches the Hyper-V server, gets sent to the TMG VM virtual NIC, gets processed and if all is right, gets flagged as VLAN2 or 3 and sent through Hyper-V's VNM to the Web Server's virtual NIC. What if that connection request originated from a spoofed IP address? You've got that packet travelling your entire LAN before TMG drops it. Best case scenario is you're adding unneeded complexity to your system, worst case is you're opening a can of worms in your internal network.

Isn't it much better if the first point of contact for incoming traffic is TMG? Now play that previous scenario on this diagram:

What you get is OSI level 3 to 7 security scanning BEFORE anything reaches your DMZs, let alone your LAN.

Given you have only ONE physical server for a firewall and DMZ VM host, this is clearly a winning solution!


(EDIT) Another solution was presented to me that meets almost all the standards I had in mind when I started this post. I'll give a short description here and promise to expand on it on a new post as soon as I get the chance.

You start off by having a Windows 2008 R2 CORE installation with the Hyper-V Role, then install TMG, and your DMZ hosts as VMs. Then, instead of using VLANs to route packets, you use Hyper-V's own Virtual Network Manager to create one Virtual Network for every physical NIC on your Hyper-V host. Then get this:

You DISABLE all NICs on the Hyper-V host, except the one you'll use for managing it!!! So in theory your CORE machine is impervious to attacks from the Internet AND the DMZ, because the host itself cannot physically connect to these networks since the corresponding NICs are disabled.

BUT, Hyper-V's VNM still routes traffic where it should and everything works beautifully, on the VM side. MS by-the-book goers are happy and I am kinda happy because I'm not relying on VLANs. Then again, I'm still having potentially malicious packets running around my Virtual Networks before TMG stops them, but regardless, it's a solid proposition and merit goes to Hyper-Vaggelis, Greece's resident Hyper-V MVP.

I promise I'll do a proper how-to on this as soon as I get the chance.



the ITGuy.


  1. Very nice article, thank you for sharing it!

    On my single physical host (w/a single physical I/F), I did an even simpler setup: I created multiple VLAN IDs (by using the I/F's Driver), then I attached the Guest VMs to their own specific VLANs.
    I too thought about "testing" TMG and I too came at your same conclusion (but still didn't find time to experiment with!).

  2. All the contents you mentioned in post is too good and can be very useful. I will keep it in mind, thanks for sharing the information keep updating, looking forward for more posts.Thanks top 10 vpn reviews

  3. I admit, I have not been on this web page in a long time... however it was another joy to see It is such an important topic and ignored by so many, even professionals. professionals. I thank you to help making people more aware of possible issues. vpn services


Total Pageviews


Search This Blog

Popular Posts