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 4)
Introduction
In the first part of this series on how you can use the TMG firewall in Windows Azure, you might recall that 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 was that you could provide forward proxy, web filtering and anti-malware services to external users while not having to 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 it is placed on an Azure Virtual Network. In the third part of the series, we talked about how you can use the TMG firewall to publish web sites and FTP sites. In the fourth part of the series, I delved into some of the design considerations you’re going to have to address when you put Exchange Web services into an Azure Virtual Network. That brings us to Part 5, where we wrap up the series.
As a reminder, here are the scenarios I promised to address in the introduction to the article series:
- Web caching
- Web publishing for FTP and HTTP servers
- OWA, ActiveSync and RPC/HTTPS publishing (Outlook Anywhere) and autodiscovery
- Remote Access VPN
We’ve covered everything except the last item, so in this article, we’ll take a look at the VPN scenario, whereby the TMG firewall acts as a remote access VPN server that users can use to connect to corporate resources or to resources that are contained within the Azure Virtual Network.
TMG as a Remote Access VPN Server in Windows Azure
The first thing that you might ask yourself in this scenario is: why you would want to put a VPN server into an Azure Virtual Network in the first place? Why not just put it in the corporate DMZ? Here are af few reasons that you might consider putting your corporate VPN server into an Azure Virtual Network:
- You can reduce the amount of bandwidth that will be used on the corporate Internet access connection by having your users connect to a TMG firewall based VPN server on an Azure Virtual Network.
- You can reduce the attack surface of your network by decreasing the number of direct, incoming connections to your network.
- You can have users connect to the VPN server on the Azure Virtual Network so that they can access resources that are hosted on the Azure Virtual Network.
- You can allow users to connect to the resources on the corporate network by first connecting to the VPN on the Azure Virtual Network and then connecting to the on premises resources through the site to site VPN tunnel.
The first thing that you should think about is how much bandwidth you will be able to save if you put the VPN server on the Azure Virtual Network, in comparison to putting it on the corporate DMZ. The amount of bandwidth that you’ll be able to save will be related to which resources the VPN users are going to access. If all the resources are going to be on premises, then you probably won’t be saving very much bandwidth, because the users will need to use your site to site VPN connection that connects your network to the Azure Virtual Network. In that case, you’ve just moved the bandwidth from your primary inbound Internet connection to the site to site VPN connection.
In order to see any significant decreases in the amount of bandwidth used, you’ll have to think about moving some of the resources that are currently running on premises to the Azure Virtual Network. For example, let’s suppose that there is a file server that is currently on premises, to which many of your users need to create VPN connections to access when they’re out of the office. What you could do in this scenario is put a file server on the Azure Virtual Network and then replicate the contents of the on premises file server to the file server that you put on the Azure Virtual Network. This will then reduce the amount of bandwidth that is required on your Internet connection because the users will not need to connect to the corporate network in order to access the files. All they’ll need to do is create the VPN connection to the TMG firewall on the Azure Virtual Network, and then they can directly connect to the file server on the Azure Virtual Network.
Of course, there are going to be one-time and then periodic bandwidth requirements involved in replicating the files, but in the long run, you should see that the replication traffic is much less than what the traffic is for the users who are accessing those files, because the files are probably going to be accessed multiple times and the replication traffic occurs only with the initial replication and when the files are changed.
You can put other servers in the Azure Virtual Network, too. Key line of business web based applications are good candidates to be placed onto the Azure Virtual Network. And of course, any on premises SharePoint sites will easily fit there too. Alternatively, you could put SharePoint and other web services on the Azure Virtual Network and then just publish those web sites; however, requiring a VPN connection first before a user can access the web services is a much more secure approach, since the users will need to authenticate with the VPN server before authenticating with the web servers.
Security is an important factor in making these design decisions. When you put the VPN server on the Azure Virtual Network, you potentially reduce the overall attack surface on your network. Any inbound connections from the Internet at large are going to increase your attack surface, so why not reduce that attack surface a bit by putting the VPN server on the Azure Virtual Network?
Of course, if you have a site to site VPN connection between your on premises network and the Azure Virtual Network, an intruder could reach the on premises network if you allow VPN users to have that level of access. However, if you design your Azure Virtual Network and on premises network access controls correctly, you can significantly reduce the risk. For example, when a user connects to a VPN server on premises, that user typically will be allowed unfettered access to all of the local resources. If you put the VPN server on the Azure Virtual Network, it’s much more likely that you’ll put together more comprehensive access controls over which addresses on the Azure Virtual Network will be allowed to reach the on premises network. Thus, technically the security situation from a technology perspective doesn’t change, but the mindset behind the security controls may very well change.
You might be wondering what kind of infrastructure decisions you need to make when putting a VPN server on an Azure Virtual Network. Some of the things to consider include:
- DNS requirements
- IP addressing requirements
- Authentication requirements
- Bandwidth requirements
The primary DNS issue that you’ll need to consider is name resolution for access to resources on the Azure Virtual Network and the on premises network. Remember that the built in DNS server that comes with the Azure Virtual Network will only resolve names for resources on that network. However, VPN clients should be able to use broadcast based name resolution for resources on the Azure Virtual Network. In general, it’s a better idea to assign the VPN clients a DNS server that can resolve names for resources on the Azure Virtual Network and on premises (assuming that you’re going to allow them to have access to on premises resources).
I think the best approach is to put a domain controller on the Azure Virtual Network and use Active Directory integrated DNS for this. The VPN users can then be assigned the DNS server of the Active Directory integrated DNS server that is located on the Azure Virtual Network. This will allow users to authenticate, even if the site to site VPN connection is down, and it will also allow them to resolve names on the Azure Virtual Network.
IP addressing is an important consideration. Remember that for the virtual machines that are located on the Azure Virtual Network, you cannot manually assign IP addressing information. Windows Azure must assign the addresses to the virtual machines. In contrast, when a remote access VPN client connects to the VPN server, Windows Azure will not be responsible for assigning IP addressing information to the VPN clients; instead, the VPN server is responsible for that. What you’ll want to do, then, is configure the VPN with an address pool that contains addresses that are valid on the Azure Virtual Network that you created. Client computers must also be configured with a gateway address so that they can connect to resources on the on premises network. This address is the address of the site to site VPN gateway that is located on your Azure Virtual Network.
While you could mirror your users on a standalone VPN server, that’s a pretty high overhead approach, and it is definitely not an enterprise grade solution. Instead, you’ll probably want to make the TMG firewall a domain member and use your Active Directory accounts to authenticate and authorize your users. Of course, there are other approaches, too, such as using a RADIUS server.
Finally, think about what kind of bandwidth you’re going to need to support the solution. In general, you will max out your pipe to the Azure Virtual Network at around 80Mbps (of course, this could change in the future). So you should determine whether that’s going to be enough. If not, you might need to create multiple Azure Virtual Networks and mirror the configuration of the servers on each one.
Finally, keep in mind that virtual machines on an Azure Virtual Network can have only a single NIC, which means that your TMG firewall VPN server will be a single NIC VPN server.
Summary
In this article, we finished up our series on putting a TMG firewall on an Azure Virtual Network. As you can see, many of the same options are available to you as when the TMG firewall is located on premises. There are a few issues that are specific to Windows Azure that you need to consider before deploying the TMG on an Azure Virtual Network. I hope you learned a useful thing or two in this series and as always, please let me know if you have any questions or suggestions! For more information about Windows Azure, please be sure to check out our new cloud computing web site that’s coming soon. See you there! –Deb.
If you would like to read the other parts in this article series please go to:
