I’ve been working with Microsoft Azure a lot over the past few years, and recently I’ve been testing various Windows Server workloads to see how they work in Microsoft’s public cloud. As a thought experiment, I decided to test Forefront Threat Management Gateway (TMG) 2010 running on a virtual machine in Azure. Since Azure virtual machines are limited to only a single network interface, TMG can only provide limited services. However, it can still function capably as an explicit forward web proxy, reverse web proxy, and client-based VPN server. Unfortunately you’ll lose support for transparent forward proxy, non-web protocol forward or reverse proxy, site-to-site VPN, and the Firewall Client. In addition, network load balanced clusters are not supported in Azure. So why would you want to host TMG in Azure? Well, I can think of a few reasons! Perhaps you’ve built a test lab in Azure and you want to provide secure web access for hosts in your lab? Or maybe there’s an application you have hosted in Azure that you’d prefer to publish using TMG to take advantage of pre-authentication options or application traffic inspection that TMG provides. There are probably many other reasons to deploy TMG in Azure, but these common use cases prompted me to test and document the process here.
This article assumes that you are familiar with how to configure virtual networks and machines in Azure. It also builds upon the Azure test lab that I described in a recent article on CloudComputingAdmin.com entitled Configure a Windows Server 2012 R2 Test Lab in Microsoft Azure, so you should already have an existing virtual network and lab environment configured in Azure before following the guidance in this article.
Create an Azure Virtual Machine
In the Azure management portal, select the Virtual Machines node in the navigation tree and then click New at the bottom of the window. Select Virtual Machine and then From Gallery, and then select Windows Server 2008 R2 SP1 from the list of available virtual machine images.
Provide a name for the new virtual machine, select a tier that meets your requirements, choose the size (processor cores and memory) you’d like the virtual machine to be, and provide a new user name and password for the VM.
Choose the cloud service to deploy the virtual machine to and be sure to select the appropriate virtual network subnet to place the VM.
Finally, select optional configuration settings as needed. Although security extensions are available that will install antivirus software on the virtual machine, these are not recommended for the TMG workload. If you do choose to install antivirus software on the TMG virtual machine, be sure to closely follow the guidance set forth by Microsoft for using antivirus software on TMG, which can be found here.
Prepare the Azure VM for Forefront TMG 2010
Once the Azure virtual machine has been provisioned, it’s a good idea to assign it a static IP address. This can only be accomplished using PowerShell, however. To find instructions for installing PowerShell for Microsoft Azure, click here. To assign a static IP address to the VM, execute the following PowerShell command:
Get-AzureVM -ServiceName <servicename> -Name <hostname> | Set-AzureStaticVNetIP -IPAddress <ip_address> | Update-AzureVM
Joining the TMG firewall to the domain is optional, but recommended to take full advantage of its integrated user and group based authentication. Connect to the VM using RDP by selecting the VM in the management portal and clicking Connect at the bottom of the screen. Once connected via RDP, join the TMG virtual machine to the domain.
Install and Configure Forefront TMG 2010
After you’ve joined the TMG firewall to the domain, it will be necessary to provide the installation source for installing TMG. Unlike local virtual environments where we might simply mount an ISO file as a virtual DVD drive, that option is not available to us in Azure. There are a number of ways to work around this, however. It is possible to place the TMG installation files on a VHD file and upload that to Azure. Also, you could elect to use Azure Files, which makes files available via SMB to virtual machines in the same cloud service. The quickest and simplest way that I’ve discovered is to use the local drive mapping feature of the remote desktop client to transfer files to the virtual machine. Before we connect we’ll need to gather some information. First we’ll need the DNS name of the cloud service that the virtual machine belongs to. You can find the name of your cloud service by visiting the Dashboard for the virtual machine and looking at the Quick Glance settings under DNS Name.
We’ll also need to determine the public port assigned for RDP access to the VM. To find the public port assigned for RDP, select the Endpoints tab.
Now launch the remote desktop client and choose Show Options. Enter the name of your cloud service followed by the public port assigned by Azure for RDP.
Select the Local Resources tab, expand Drives and select the disk drive where the Forefront TMG 2010 installation files are located and click Connect.
Once connected via RDP, copy the TMG installation files from the local machine to the virtual machine in Azure. After the file transfer completes it is important that you disconnect from this RDP session and reconnect from another host on the same Azure virtual network as the TMG firewall will reside. This is extremely important because if you attempt to install TMG via the previous RDP session originating from outside Azure, TMG will add the incorrect IP address to the TMG remote management computers group and you will be permanently cut off from the server and you’ll be forced to delete the server and recreate it.
After you’ve connected to the TMG VM from a host on the same Azure subnet you can proceed with installing Forefront TMG. During the installation process, be sure to select Add Adapter when defining the internal network definition. As this is a single NIC deployment, the entire IPv4 address space (with the exception of the 127.0.0.0/8 loopback address range) will be added to the internal network definition.
Once the installation is complete, the only supported deployment scenario will be the single network adapter model.
When selecting the network adapter connected to the LAN, leave the default option Obtain an IP address automatically selected. Azure static IP address assignments are effectively dynamically assigned addresses that are reserved and will not change, so there’s no need to assign an IP address here.
After you’ve finished the configuration and defined your web access policy, simply configure any of the clients in your Azure network to use the TMG firewall as their web proxy server. You can do this manually or use automatic configuration with WPAD.
Publishing web applications in Azure using TMG is similar to doing it on premises. In single-NIC mode, be sure to select the Internal network when creating and assigning the web listener.
In addition, an Azure endpoint must be configured to allow the traffic to the TMG web proxy. In the Azure management portal select the TMG VM and then click Endpoints. At the bottom of the screen click Add and then choose Add a standalone endpoint. Select the appropriate ports for your application. In this example I’m publishing an SSL web site so I’ve chosen TCP port 443 as the public and private port.
Finally, update public DNS with the hostname for your application so that it resolves to the public virtual IP address for the VM. You can find this information on the Dashboard page for the VM under the Quick Glance settings.
As I stated at the outset, configuring TMG in Azure started as what I termed a “thought experiment”. I set out initially just to prove that it could be done. However, deploying TMG in Azure is not without serious limitations. First, there is no console access in Azure, so if you configure networking or firewall policy incorrectly and it prevents RDP access, you’re done. Your only option may be to delete the VM and recreate it. Not exactly what I would call an ideal situation. It happened to me more than once during the research for this article. Also, much to my disappointment, I was not able to get client-based VPN using SSTP to work in Azure. This would be an excellent use case for TMG, as the native VPN client access option for Azure leaves quite a bit to be desired. Perhaps I’ll explore that more in the future. TMG in Azure provides access to a very limited subset of features of TMG, but if you have a requirement to provide secure web access for hosts in an Azure virtual network, or publish an application using TMG’s pre-authentication and traffic inspection features, then perhaps this will work for you. Proceed at your own caution though!