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 1)
- 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 5)
In the first part of this series on how to use the TMG firewall in Windows Azure, I 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 is 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 the second part of the article I wrote about how you can use the TMG firewall as a web caching server when placed on an Azure Virtual Network. In Part 3, we talked about how you can use the TMG firewall to publish web sites and FTP sites. That article was a prelude to today’s discussion, which is all about how you can use the TMG firewall to publish key web services related to Microsoft Exchange.
As a reminder, here are the scenarios that I promised you we would cover over the course of the series:
- Web caching
- Web publishing for FTP and HTTP servers
- OWA, ActiveSync and RPC/HTTPS publishing (Outlook Anywhere) and autodiscovery
- Remote Access VPN
In this article, we will be taking a look at Exchange Server publishing options for putting the TMG firewall into an Azure Virtual Network.
Publishing Exchange Web Services
You already know that the TMG firewall allows you to publish any number of web services using either web publishing or server publishing rules. For the majority of scenarios, you’ll want to publish web services using the web publishing feature, because the web publishing feature exposes the connections to the web proxy service, and it’s in the web proxy service that you get the authentication, authorization and application layer inspection capabilities for security. You are definitely going to want to use this feature when you publish Exchange Web Services.
What are the Exchange Web Service that you might want to publish through the TMG firewall? These include:
- Outlook Web Access (or as it’s called now, “Outlook Web App”)
- RPC/HTTPS (or as it’s called now, “Outlook Anywhere”)
- Exchange ActiveSync (which is used by many mobile devices, including Windows and Android phones)
- Exchange Autodiscovery (which is used to enable devices to configure themselves to use the correct settings when connecting to the Exchange Server)
The good news here is that the TMG firewall is built to support publishing each of these services right out of the box. That means you don’t have to figure out the details of publishing each of these services or protocols because the TMG firewall includes an Exchange Server publishing wizard. You can use the Exchange Server Publishing Wizard to publish each of these services without having to delve into the intricacies and encounter poorly or undocumented requirements for making the publishing rules work. The Wizard takes care of all of these requirements transparently.
Single NIC connection
Once you’ve decided what you want to do, the question then becomes this: how do you put the TMG firewall into an Azure Virtual Network to publish these services? In the typical Exchange Server Publishing scenario, you would put the TMG firewall in the corporate DMZ network or on the edge of the network. If you’re putting it at the edge of the network, the TMG firewall would have two networking interfaces, one that’s on the default External Network and one that’s on the default Internal Network. If the TMG firewall is inside a DMZ segment, you could use one or two interfaces, but in most cases it’s simpler and just as effective to use a single NIC TMG firewall to accept the incoming connections to the Exchange Server.
Putting the TMG firewall in an Azure Virtual Network does limit our options, but there is an upside to that: you don’t have as a complex of a decision making process when you sit down to come up with the design. The reason for this is that Azure Virtual Networks at this time does not support multi-homed virtual machines. This means that even if you wanted to deploy a dual homed TMG firewall in the Azure Virtual Network, you won’t be able to do so. So the bottom line is that if you want to publish your Exchange Web Services using a TMG firewall on an Azure Virtual Network, you’re going to have to use a single NIC connection.
With the issue of the number of NICs that are required on the virtual machine dealt with, we can move on to some other infrastructure requirements. One of the issues that you will need to deal with is that in order to provide the level of security you want from the TMG firewall Exchange Web Services publishing solution, the TMG firewall needs to be a domain member. Domain membership is required so that the TMG firewall can authenticate and then authorize the connections inbound to the Exchange Servers. This means that the TMG firewall is going to need to be able to communicate with a domain controller whose Active Directory database contains the user accounts of the users who are going to connect to the Exchange Server.
There are a number of ways you can approach this situation. First, you can mirror your on-premises accounts to a domain controller that is located in the Azure Virtual Network on which the TMG firewall sits. The bad news is that there is a great deal of administrative overhead involved in that solution, so it’s something I would only consider for the smallest of organizations.
Another option is that you can create a site to site VPN connection between your on-premises network and the Azure Virtual Network and then, when authentication requests come into the TMG firewall, the TMG firewall will forward the authentication requests to the on-premises domain controllers. Unfortunately, there is a problem with this configuration. What happens to authentication when the site to site VPN connection fails?
The prospect of failure of the site to site VPN connection influences more than just authentication communications between the TMG firewall and the on-premises domain controllers, too. Even if we put a domain controller on the Azure Virtual Network so that authentication can continue to take place, the TMG firewall will not be able to communicate with the on-premises Exchange Servers! This then brings up a design decision that is related to where you place your Exchange Servers and the reason for putting the TMG firewall in an Azure Virtual Network in the first place.
Let’s go back to that last issue. Why would you want to put a TMG firewall in an Azure Virtual Network?
- The primary reason for this is so that the inbound traffic to the TMG firewall would not take up bandwidth on your Internet connection.
- A secondary reason would be that the connections to the Azure Virtual Network are going to be more reliable than those to your corporate on-premises Internet connection.
- A third reason might be that it could be considered more secure to allow inbound connections from the Internet into an Azure Virtual Network versus allowing them into a corporate DMZ.
Let’s analyze this scenario a bit further. Who will connect to the TMG firewall on the Azure Virtual Network? You can configure things so that only external users connect to the TMG firewall to access the Exchange Server, or you can configure things so that both internal and external users connect to the TMG firewall in the Azure Virtual Network. The decision to have internal users connect to the TMG firewall first would be so that you can provide added security for the internal user connections. However, if you have a design that you already like and are comfortable with, you can continue to allow internal users to directly access the on-premises Exchange Servers.
There is no “one size fits all” answer to the problem of lost connectivity in the event of a failed site to site VPN connection. In most cases, if there is a failure, that failure is going to be a transient one if it’s related to a problem on the side of the Azure Virtual Network. If the failure is related to a problem at the on-premises network, then it doesn’t matter whether the TMG firewall is on an Azure Virtual Network or not; the same downtime would be experienced if the TMG firewall were on-premises since the problem is with the on-premises network.
My general recommendation is that you put the single NIC TMG firewall or TMG firewall array in the Azure Virtual Network and put a read/write domain controller that is part of the corporate domain on the Azure Virtual Network. This will speed up the authentication component of the connection. After the connection is authenticated and authorized, the connections will then be forwarded to the on-premises Exchange Servers over the site to site VPN connection.
You will have to deal with DNS issues for both internal and external users. External users will need to resolve the name of the Exchange Server to the IP address that is used for allowing inbound HTTPS connections to the TMG firewall on the Azure Virtual Network. They will also need to be able to resolve the autodiscovery name to the same IP address so that mobile devices can automatically configure themselves. These DNS entries should be configured on a publicly accessible DNS server.
As for on-premises users, they will be connecting to the Exchange Server directly, so the IP address and names that you will use to support those connections will be contained in DNS records housed in your internal DNS server systems. As you can see, what we’re setting up here is a classic split DNS infrastructure.
For more information on how to set up a hybrid IT infrastructure, which is what I’ve described here, please see Hybrid IT Infrastructure Solution for Enterprise IT.
In this article, Part 4 of our series on using the TMG firewall in Azure Infrastructure Services, we went over some of the decisions you need to make when putting together a hybrid IT infrastructure that includes putting the TMG firewall in an Azure Virtual Network when publishing Exchange Web Services, and some factors that you’ll have to take into consideration in completing your design. We talked about networking, authentication, authorization, and name resolution issues, as well as some of the connectivity issues that are related to accessing on-premises resources from the Azure Virtual Network. In the next (and last) installment in this series, we’re going to talk about how you can put a TMG firewall in an Azure Virtual Network and use it as a remote access VPN server, as well as what types of scenarios this kind of configuration might support. See you then! –Deb.
If you would like to read the other parts in this article series please go to: