If you would like to read the other parts in this article series please go to:
- Using the TMG Firewall in Azure Infrastructure Services (Part 2)
- Using the TMG Firewall in Azure Infrastructure Services (Part 3)
- Using the TMG Firewall in Azure Infrastructure Services (Part 4)
- Using the TMG Firewall in Azure Infrastructure Services (Part 5)
Introduction
Over the years we’ve mostly talked about ISA and TMG being used as a firewall and web proxy on the corporate network. That made sense since that was the common deployment scenario. But now we’re seeing the winds of change blowing and realizing that the cloud is going to be in the future for most of the companies that run TMG firewalls. The question then comes “is there a place of the TMG firewall in a cloudy world?”
The answer is yes, of course there is a place for the TMG firewall in a cloudy world. If you think about private cloud, you still need a TMG firewall at the edge of the network. In addition, you can use TMG firewalls in your private cloud network itself, behind the edge firewall. You can install a TMG firewall as a virtual machine and control traffic between various security zones in your private cloud, much in the same way we did it with a pre-cloud, highly virtualized environment.
But what about public cloud? Is there a way you can leverage the TMG firewall’s capabilities in the public cloud? And specifically, what about Windows Azure? If you’re a fan of our WindowsNetworking.com site, you may have seen my recent articles there on Azure Infrastructure Services, Microsoft’s cloud OS. And you might be wondering whether it’s possible to use the TMG firewall within Windows Azure. The short answer (as you might have guessed from the title of this article series) is “yes.” In this series of articles, we’ll go into detail about just how you can do that.
TMG/Azure scenarios
Just in case you didn’t see the WindowsNetworking articles, Windows Azure is Microsoft’s infrastructure as a service (IaaS) offering that enables you to put virtual machines up in the Azure public cloud. You can either use virtual machine images that Azure makes available to you or you can upload your own VHDs and create virtual machines out of those. Azure even allows you to create a site to site VPN between your own network and the Azure Virtual Network that contains the virtual machines that you’re running in Windows Azure.
The first thing that you can do with a TMG firewall in relation to Microsoft’s IaaS is use it as the on-premises firewall that acts as the on-premises VPN gateway that connects the corporate network to the Azure Virtual Network. Now there’s an important caveat: Microsoft is clear that TMG is not supported in this scenario; however, many who have done it can attest that it does work. The problem with this approach is that if you call Microsoft Customer Support Services about a problem with your site to site VPN based on TMG, the first thing they are going to tell you is that you need to take down the TMG VPN gateway and use an approved VPN device. So you might want to think twice about using TMG in this capacity.
A more likely scenario is for you to put the TMG firewall on the Azure Virtual Network and allow machines to connect to it. The primary issue that you are going to need to deal with in this scenario is that Azure Virtual Networks only allow the virtual machines you place in them to have a single NIC. That means that any scenario that requires multiple NICs will not be available to you when you put the TMG firewall into an Azure Virtual Network. Unfortunately, that includes some popular scenarios.
However, there are also a number of single NIC scenarios for the TMG firewall that you can deploy. These include:
- Forward proxy for HTTP, HTTPS and FTP
- Web caching
- Web publishing for FTP and HTTP servers
- OWA, ActiveSync and RPC over HTTP publishing
- Remote access VPN
Let’s look a bit more closely at each of these scenarios.
Forward Proxy
Forward proxy for HTTP and FTP requests allows clients to connect to the TMG web proxy service and have the TMG forward those requests on behalf of the client system. The Web proxy is also the heart of the web filtering and web anti-malware features that are included with the TMG firewall. You could configure your external users to connect to the TMG firewall in the Azure Virtual Network and that would enforce the same web access policies that you have for your users when they are on the network. You could do this by configuring a split DNS and configuring the public DNS servers with the same autodiscovery URL that the internal users use. That autodiscovery URL would then automatically configure your external users to forward their web requests to the TMG firewall that is located on the Azure Virtual Network. When the users move back onto the corporate network, the autodiscovery URL would point them to the TMG firewall that is on the corporate network.
Pretty nice, eh? When you configure the TMG firewall as a Web proxy server on the Azure Virtual Network, you need to make sure that you create a port forwarding rule in Azure that allows inbound connections for TCP port 80, TCP port 443 and TCP port 21 to the IP address assigned to the TMG firewall by Windows Azure. Remember that Azure assigns IP addresses to the virtual machines on the Azure Virtual Networks, and you have to use the IP address assigned to the virtual machine. However, once the IP address is assigned to the virtual machine, that virtual machine “owns” that address for the lifetime of that virtual machine.
Another thing to remember when you put the TMG firewall on the Azure Virtual Network is that it will need to be configured to use an external DNS server. Again, you can’t configure the DNS server directly on the TMG firewall, so you will need to configure the external DNS address in the configuration of the Azure Virtual Network. You can mirror the settings that are assigned by the Azure Virtual Network on the actual NIC of the TMG firewall, but if for any reason Azure decides to change the IP address of that virtual machine, you won’t be able to access that virtual machine over RDP anymore. That will require you to delete the current virtual machine on which TMG is installed. After you delete the virtual machine, you can recreate it using the VHD file that the old virtual machine used. This process isn’t too onerous and it’s unlikely that this will ever happen.
I like this option because it’s better in certain ways than configuring external users to use the TMG firewall on the corporate network, since it’s not taking up bandwidth on your corporate connection. This makes more bandwidth available to internal users while external users still have all the security advantages of using a TMG firewall to protect them.
You can also use the forward proxy in the Azure virtual network to proxy web requests that are destined for the internal network. In this scenario, there might be a site to site VPN that connects the corporate network to the Azure Virtual Network. In this case, when external users make a request for internal resources, they first hit the TMG firewall on the Azure Virtual Network. If the request is allowed, it is forwarded over the site to site VPN to the server on the internal network. The advantage of this approach is that it can be more cost effective to run TMG in a virtual machine in Windows Azure than it might be on the corporate network, because you don’t have to pay for the hardware and power and physical space and server maintenance that it costs to run on premises.
The disadvantage to this approach is that it will consume bandwidth on the site to site VPN. At the present time of this writing, the speed of the site to site VPN between Azure Virtual Network and the on-premises network is pretty much capped at around 80Mbps due to limitations on receive side scaling on virtual machines. The good news is that when Azure is upgraded so that the hosting machines run Windows Server 2012 R2, virtual receive side scaling will be available and that should significantly increase the speed of the site to site VPN.
Note that in this forward proxy scenario, the TMG firewall isn’t publishing the web sites to the external users; instead, it’s forwarding the requests in the role of web proxy. That means that the external users will need to be able to resolve the internal names of the servers using an external DNS server. Again, this is going to require that you have a split DNS. Some companies might not be comfortable with this, and if that is the case, you will need to publish the resources. Of course, the DNS names for the services don’t need to be the same names as the servers themselves, thus this is really less of an issue than it might seem.
A similar scenario doesn’t need the requests to be forwarded over a site to site VPN. Instead, you can have a TMG firewall on premises that is publishing the web or FTP resources that you want external users to access. The external users will connect to the TMG firewall in Azure and then the TMG firewall in Azure will forward proxy the requests to the TMG firewall on premises, which in turn will forward the requests to the published Web or FTP server. You could then configure the TMG firewall on the company premises to only accept incoming requests from the public IP address used by the TMG firewall on the Azure Virtual Network. This prevents the entire Internet from being able to connect to the on-premises TMG firewall. They get stopped at the TMG firewall that is located on the Azure Virtual Network.
Summary
In this article, we introduced the possibility of putting the TMG firewall on an Azure Virtual Network. We then discussed the various single NIC scenarios that would be supported by a TMG firewall that is located on an Azure Virtual Network, given the fact that Azure Infrastructure Services only allows one NIC on each virtual machine running on a Azure Virtual Network. Then we finished up by discussing in detail one of those scenarios, the forward proxy scenario, and how that would work on Azure Infrastructure Services. In the next article, we’ll continue this discussion of the different scenarios.
If you would like to read the other parts in this article series please go to:
