Introduction
If you’ve ever been an expert at anything (and almost everyone is an expert at something), you might have found that when you try to explain something about that subject to someone who isn’t an expert, it can be a lot harder than you would think. This phenomenon is sometimes called “the curse of knowledge.” Because you understand both the intricacies and the “big picture,” you’re likely to take for granted that many things are obvious facts when in fact they aren’t obvious at all to anyone who is not an expert. Of course, even among experts, there’s often disagreement. Because we all approach an issue from different perspectives, not everyone thinks the same way about those facts. Even if others are aware of those facts, they don’t see them in the same way you do because they don’t have the same level of hands-on experience with the subject matter. This is something that we all need to be aware of – that you can’t expect people to “read your mind.” This is a common problem for technical writers.
Why do I bring this up? Because over the last few months I’ve been getting more than a few questions about whether you should use TMG and UAG at the same time. There are many people who would like to use both UAG and TMG, but they’re not sure what the network topology should look like in that scenario. When I tell them that the best configuration might be a back-to-back or parallel configuration (depending on what it is that you want to do with UAG), I expect that they know exactly what I’m talking about. That’s a failure on my part, because not everyone has been working with the TMG/ISA firewall for a decade and UAG for over 6 years. So, in this article, I’m not going to make assumptions. Let’s take some time to think about how you might deploy such a configuration.
Scenario 1: Back-to-back configuration
First, we’ll consider this common scenario: You want to use the TMG firewall for both inbound and outbound access control. This means that for outbound access control, you’ll probably use the web proxy service for web proxy clients and the firewall service together with the Firewall client on the client systems. You’ll also probably want to take advantage of the Network Inspection Service (NIS) to protect your systems from zero day threats.
In contrast, UAG can’t perform any outbound protection, since it’s designed to be mostly an SSL reverse proxy that also has some DirectAccess capabilities. However, in the back-to-back scenario where the TMG firewall is in front of UAG, you won’t be using it for DirectAccess, since the UAG DirectAccess server requires that you have dedicated public IP addresses assigned to the external interface of the UAG server. For DirectAccess, you’re probably going to want to use Windows Server 2012 anyway, since that supports putting the DirectAccess server behind a NAT device. In this case, the NAT device would be the TMG firewall that is sitting in front of the Windows Server 2012 DirectAccess server.
You might also consider the remote access capabilities of the TMG firewall in this scenario, especially the VPN capabilities. While the UAG server supports VPN to a certain extent, its VPN capability is essentially limited to SSTP. While SSTP is a fine VPN protocol, support for it is limited to modern Windows clients (Vista and above). So, if you want to allow VPN for non-Windows operating systems or for Windows XP system, as well as mobile operating systems, you’ll need to use the TMG firewall for your VPN server.
Scenario 2: Parallel configuration
Although I said that a back-to-back configuration would be the best one, it’s certainly not the only topology that you can use. For example, most organizations have an existing firewall. In that case, you can put the TMG firewall in parallel with the existing firewall. That way, you have the TMG firewall at the edge of the network, the location for which it was designed. Then you would assign the external interface of the TMG firewall to IP addresses that are on the same network ID as those that are used by the external interface of the existing firewall. This allows the TMG firewall to accept the inbound VPN connections from remote access VPN clients.
The internal interface of the TMG firewall will accept the outbound connections from the web proxy and firewall clients, as well as connections from SecureNAT clients on the internal network. Of course, you could also put the UAG server in parallel with the existing firewall and the TMG firewall, but it’s typically a best practice to put the UAG server behind the firewalls because this will reduce the load on the UAG server, and if you’re not going to use the UAG server as a DirectAccess server, this is the preferred deployment model.
If you use this configuration, the setup of the front-end TMG firewall is fairly easy. Because the UAG server is designed to be, and is, an SSL VPN server, all you need to do is allow inbound TCP port 443 to the UAG server. You can use either a web publishing rule or a server publishing rule to do this. I prefer to use a server publishing rule for this, mostly because it’s easier and you don’t need the added security of the web publishing rule to publish the UAG server. Also, you probably don’t want your users to have to authenticate twice (once with the TMG firewall and then again with the UAG server). This avoids that.
UAG considerations
Regarding the public IP address requirement for the UAG server, keep in mind that this is not a hard and fast rule. That’s because even though the UAG server requires public IP addresses to act as a DirectAccess server, that does not mean that you absolutely cannot put it behind a firewall. Remember that a firewall and a NAT device aren’t the same thing. A firewall can have the same level of security by acting as a secure filtering router. That means that you can have public IP addresses assigned to hosts that are behind the firewall. All modern firewalls, including the TMG firewall, will support this kind of configuration. So, if you really want the UAG server behind a firewall, and if you really want to use the UAG server as a DirectAccess server, you can do that. It’s just not done very often.
Now some of you might be thinking “Hey, the UAG server has the TMG firewall on it, so why not put it in parallel with the firewalls?” That’s a very valid question. Yes, it’s true that the UAG server sits on top of the TMG firewall, although the TMG firewall is designed to protect the UAG server itself in this scenario, and does not support any kind of outbound access control. In addition to protecting the UAG sever itself, it protects the corporate network from Internet attacks since the TMG firewall component on the UAG server will stop intruders from getting past the UAG server.
The UAG server is edge-ready, and the product team that created the UAG server has always recommended that you put it at the edge of network, especially in scenarios where you’re going to deploy it as a DirectAccess server. The primary reason for putting it behind the firewalls is to reduce the processing requirements on the UAG server. Controlling the processing requirements on the UAG server is important because it’s responsible for performing a ton of processing already. Remember that as an SSL VPN gateway, the UAG server needs to handle all of the SSL encryption tasks for the connections that are made to the UAG server. In addition to the voluminous SSL encryption tasks it has to handle, it also has to deal with the large amount of IPsec processing for the two IPsec tunnels that are created when you use DirectAccess to connect to the UAG server. And if you’re using IP-HTTPS, there’s the additional SSL processing on top of the IPsec tunnels.
In addition, you might want to put the UAG server behind your existing firewall instead of the TMG firewall. Now, you might be saying to yourself “Why would I want to do that? The TMG firewall is likely to be much more secure than my existing firewall, so why wouldn’t I want to put the UAG server behind the more secure firewall?” That’s another good question.
The reason you might want to do this is because the TMG firewall itself already has a lot of processing that it has to handle. If you configure the TMG firewall as a remote access VPN server or a site to site VPN gateway, you’re going to have the PPTP or the IPsec traffic encryption that’s going to create encryption processing cycles. If you’re using the Network Inspection Services, that’s going to add more encryption processing cycles. If you use the TMG firewall to publish secure web services, that’s even more SSL encryption processing. And if you use the TMG firewall for outbound SSL inspection, that’s even more SSL processing. As you can see, the TMG firewall can potentially be up to its neck in encryption processing. Why add more to it if you don’t have to?
Summary
These are a just a few ideas on example topologies you might want to consider when using the TMG firewall and the UAG server together. There are many more. If you have a favorite TMG plus UAG topology, let me know and I’ll share it with others in a future article or in the ISAserver.org newsletter. Thanks! –Deb.
