Using the TMG Firewall in Azure Infrastructure Services (Part 2)

If you would like to read the other parts in this article series please go to:

Introduction

In the first part of this series on how to use the TMG firewall in Windows Azure, we talked about how you might deploy a TMG firewall as a forward proxy server in an Azure Virtual Network. The primary advantage of that scenario was that you could provide forward proxy and web filtering and anti-malware services to external users and not use up any bandwidth on your corporate Internet connection.

In that article, I mentioned a few other scenarios, but didn’t go into detail. These include:

  • Web caching
  • Web publishing for FTP and HTTP servers
  • OWA, ActiveSync and RPC/HTTPS publishing (Outlook Anywhere)
  • Remote Access VPN

Let’s take a look at some more of these in more detail now.

Web Caching

As you probably already know, the TMG firewall can provide web caching support for both inbound and outbound connections through the TMG firewall. For example, if you put a TMG firewall on the Azure Virtual Network and allow it to perform forward proxy services, you can configure it to act as a caching web proxy. In fact, this is the default configuration.

When you configure the TMG firewall as a caching forward web proxy, information that the web proxy clients request will be cached on the TMG firewall, either in the firewall’s memory or on disk. In a similar manner, if you configure the TMG firewall to act as a reverse proxy, it will also cache the information for the inbound requests. The cached material for both the forward and reverse proxy scenarios is then returned to subsequent users to ask for the same information much more quickly, since the TMG firewall doesn’t have to make another request to the destination web server for that information.

As I mentioned earlier, the cached information is stored either in the TMG firewall’s memory or on disk. By default, only 10% of the firewall’s memory will be used to store cached information. This means that the overwhelming majority of cached information will be stored on disk. Therefore, you are going to have to make the best decision on what type of disk you want to place the cached information on as well as the size of the disk.

Choosing a disk type

Windows Azure supports three disk types:

  • Temporary (caching) disk
  • Operating system disk
  • Data disk

While it might seem that the best place to put the TMG firewall’s web cache would be on a caching disk, that turns out not to be the case. The reason for this is that the information on the Windows Azure caching/temporary disk is non-persistent between reboots of the Azure based virtual machine.

Azure virtual machines use the caching/temporary disk to speed up boot time – and that’s all. The reason why you shouldn’t put the cache drive on the temporary disk is that you want that information to persist between reboots, because many pages have time outs for a relatively long period of time, and you never know when the virtual machine might reboot. In addition, if for some reason the Windows Azure fabric controller needs to move the virtual machine to another physical host in the Windows Azure datacenter, you’ll lose the information on the temporary disk because the temporary disk is located on the physical server on which the virtual machine is running.

That leaves us with two remaining choices in regard to where to put the TMG firewall’s web caching drive: We can put it on the operating system disk or on the data disk. You can actually put the cache drive on either one of these disks. However, there are some space limits on the operating system disk that might not make the operating system disk the best choice, depending on how large you want to make the cache drive on your TMG firewall.

By default, the disk-caching behavior (this is the disk caching feature of the drive, not the web caching feature of the TMG firewall) is to use a write-cache for that disk, which makes it more performant. This might be a good reason to put the web cache drive on the operating system disk, since some of the information will be read from memory instead of disk. The downside of this is that if the virtual machine crashes or is moved for some reason, you will lose any information in the disk cache that hasn’t been written to the disk. On the other hand, in most cases this is going to consist of very little information and the information can be placed in disk cache later when the next user makes a request for the same information.

The last disk type option you have for where to put the web cache is on a data disk. The default disk caching behavior for a data disk is to not cache and write the information directly to disk. This has the potential to reduce the performance of the web cache a bit, since the data will be written to disk immediately. On the other hand, if you have a lot of information that you want to always be in cache and you don’t want to lose that data (such as information that you might pre-load into the web cache for remote users), then the data disk might be the best way to go.

In general, it’s best to put the cache drive on any drive other than the operating system drive. For that reason, I’d recommend that you put the web cache drive on a data disk. If you want to enable write-caching on the data disk, you can do that by running a PowerShell command. For more information on Azure disk types and how to enable write-caching on a data disk, please see this link.

Disk size depends on VM size

Something you should keep in mind is that the size of the disk(s) you can acquire to put the caching drive on will depend on the size of the virtual machine you choose to deploy on the Azure Virtual Network. In other words, the maximum size of the data disk depends on the size of the virtual machine you deploy. Of course, there’s a catch: The larger the virtual machine, the more it’s going to cost. For example, if you use a small virtual machine size in Windows Azure, you will get 1 CPU and up to 2 1TB data disks. If you want to have a TMG firewall web cache larger than 2 TB, then you’ll need to get a larger virtual machine, such as the medium sized virtual machine. The medium sized virtual machine supports 2 CPUs and up to 4 1TB data disks. Of course, this is going to cost you more.

Another factor that you should consider when choosing which virtual machine size to use is the amount of cached information you want to be delivered from the TMG firewall’s memory. In-memory cached information is going to be returned to the user considerably more quickly than information that has been written to the disk-based web cache. Therefore, if you want to max out the web proxy caching performance of the TMG firewall, you’ll want to increase the memory (based on what you’re willing to spend) on the virtual machine on which you’ll deploy the TMG firewall.

The small virtual machine size only supports 1.75 GB of memory, which is the below the recommended minimum memory of 4 GB for the TMG firewall software. Therefore, you’re going to need to consider either a medium sized virtual machine (3.5 GB of memory) or a large virtual machine (7 GB memory). While you can get the TMG firewall to run with 3.5 GB of memory, performance won’t be nearly as good as it will be if it has more than 4 GB. Thus the bad news is that you’ll need to pay more for the large sized virtual machine if you want decent in-memory caching performance.

Another reason to consider starting with a large virtual machine for the TMG firewall that will be performing the web caching function is that you also get more processors. In the case of the large virtual machine, you can use up to four virtual processors for the virtual machine, which coincidentally is pretty much the sweet spot for the TMG firewall.

Of course, if you want to run a really beefy array of TMG web caching firewalls, you can choose the A6 or the A7 sizes (I have no idea why they went from “Small” and “Large” etc. to A6 and A7). These even larger sized VM give you 28 GB and 56 GB of memory, respectively. Again, though, you’re going to pay a lot more to run these “extra large” VMs, so you’ll need to assess those costs and compare them with what you would have to pay to run the same service on premises.

Summary

In this second article of the series, we took a look at another scenario where you can place the TMG firewall on an Azure Virtual Network: placing the TMG firewall on an Azure Virtual Network so that it could act as a caching web server for forward and/or reverse proxy deployments. We went over some of the things you need to think about when choosing on which type of Azure disk to put the caching drive of the TMG firewall, and then we talked about things that you need to think about when acquiring the Azure virtual machine itself, in terms of the size of the virtual machine and how that affects disk size for the caching drive. We’ll continue this discussion with the other deployment scenarios in the next article in this series. Thanks! –Deb.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top