Introduction
In the past, we’ve discussed the advantages and disadvantages of TMG vs. UAG. Now that Microsoft has formally announced end-of-life for the former (but not the latter), some folks are asking whether it makes sense to view UAG as a replacement for TMG. After all, it includes TMG, along with other functionalities. In this article, we’ll do a comparison of TMG and UAG and the key differences between the two, with that question in mind. We will also cover some best practices for designing a network topology that takes full advantage of both UAG and TMG.
A brief history
Microsoft acquired Whale Communication in 2006. This was a big deal at the time, because ISA Server was a hot product and we all knew that Whale had an SSL VPN gateway implementation that ran on top of the ISA firewall. Since Microsoft didn’t have an SSL VPN gateway of its own at the time, it made total sense for them to acquire an SSL VPN gateway that was already designed to work with the ISA firewall so that the gateway could be put on the edge of the network.
If you’ve been in this business for a while, you’ll recall that SSL VPN gateways were all the rage in the early 2000’s. There was a ton of hype about what an “SSL VPN” was all about. One of the biggest “hypethetical” components was related to SSL VPNs being “clientless”. Of course, that turned out to be just marketing stuff, because in order to get all the features that you really wanted, you had to install some client software on the machines that would connect to the SSL VPN gateway. Sure, they could install the software “on the fly” – but calling them clientless was a little misleading.
After Microsoft acquired Whale, they first released something called the “Intelligent Application Gateway 2007” or IAG 2007. A few years later, that morphed into the “Unified Access Gateway 2010,” which has more features and includes some amazing improvements for DirectAccess. And that’s where we stand today.
Since the release of UAG 2010 and TMG 2010, many IT pros have wondered which product might be best for their organizations. At least from a distance, they seem to be very similar products, and the fact that UAG runs on top of TMG lends to the confusion.
The case for the SSL VPN
The typical method of allowing users outside the corporate network to access internal resources over the Internet is to use network layer VPNs. However, network layer VPN technology typically works by using one of the main two tunneling protocols (PPTP or L2TP). These protocols enable secure layer 3 tunnels to be established, either between a client and server or between two network layer VPN gateways (also known as VPN routers or site to site VPNs).
The problem is that sometimes the client is going to be behind an edge firewall or web proxy server that only allows outbound HTTP and HTTPS traffic. This creates a problem for the users because they cannot establish PPTP or L2TP/IPsec connections to the corporate VPN server. It’s inaccurate to call a VPN server an “anywhere access enabler” when there are so many ways that access can be blocked for legitimate users.
SSL VPN technology does not suffer from the connectivity issues that we see with network layer VPN connections. A client using a traditional VPN protocol (such as PPTP) to connect to the VPN Server can be blocked by the firewall if that firewall doesn’t allow outbound GRE and have a PPTP NAT filter or allow outbound protocols for L2TP and IPsec. When clients use an SSL VPN gateway, they can use HTTPS to connect to the VPN gateway. Almost all firewalls and web proxies allow outbound access for HTTPS. SSL VPNs make it possible for remote clients to connect to the HTTPS portal. After they connect to the portal, they can connect to the internal network assets (such as servers and workstations) from remote locations without having to worry about connectivity issues.
SSL VPNs are no longer a fad; they’re considered standard network gear. With Windows Server 2008, Microsoft introduced the ability to configure RRAS as an SSL VPN server using the SSTP VPN protocol. This is an example of a layer 3 network level SSL VPN. But here’s the question: If we have an SSL VPN that comes with the operating system, what are we going to use UAG for? Why deal with the added complications of another product when we have SSL VPN capability right out of the box with our OS?
Well, it’s not quite as simple as that. In fact, there are several reasons that you might still want to consider UAG.
UAG vs. Windows Server SSL VPN
While the operating system can give us a basic network layer SSL VPN, UAG gives us a lot more. UAG takes the old Whale software to the next level and includes some major enhancements in management, administration and integration with TMG.
UAG sits on top of TMG (in the same way IAG sat on top of ISA Server). When you install UAG, TMG is installed. That means that UAG takes advantage of the key security advances that came with TMG. In addition, UAG runs on top of Windows Server 2008 and Windows Server 2008 R2, which makes it more secure and stable than software that ran on previous versions of Windows.
The best way to get started understanding the key differences between TMG and UAG is to take a brief look at a few remote access features and how they differ (or don’t):
- Application Intelligence and Publishing (UAG is better than TMG in most areas)
- End Point Security (UAG is better than TMG in most areas)
- SSL Tunneling (UAG is better than TMG in most areas)
- Information Leakage Prevention (UAG is better than TMG in most areas)
- Robust Authentication Support (KCD, ADFS, OTP) (UAG is more flexible)
- Windows Server 2008, Native 64-Bit (same for both)
- Product Certification (Common Criteria) (same for both)
- NAP Integration (same for both)
- Terminal Services Gateway Integration (easier to set up with UAG)
- Web Farm Load Balancing (easier to set up with TMG)
- Array Management (TMG more robust)
- Enhanced Management and Monitoring (MOM Pack) (same for both)
- Enhanced Mobile Solutions (UAG is better in most scenarios)
New and Customizable User Portal (N/A for TMG)
Wizard Driven Configuration (same for both)
UAG and CIA
When you create a security policy for your organization, you always need to consider issues that are defined by the common concept of CIA: Confidentiality, Integrity and Availability. These CIA components are included when you create a UAG portal. Some of the ways that UAG can help you with CIA considerations include:
Endpoint policies provided by UAG allow you to specify a security configuration for computers that connect to the portal, which must be met before access is granted. You can configure the policies to support coarse grained access (allow or deny connections) or fine grained access (allow access to the portal but create selective application experiences based on the nature of the client configuration and location). These policies help prevent data compromise, which could damage confidentiality.
A key feature of UAG is that it allows you to create a custom end-user experience on a per application basis, so that based on the user, the operating system, and the security status of the connecting client, the user experience for the application will be different. UAG uses authentication and authorization separately from the Windows authentication provided by the core operating system, which makes authentication and authorization more flexible.
UAG supports NLB arrays, which helps make it a highly available solution.
UAG network topologies
One question that comes up a lot is: Where do you put the UAG machine and which network topologies are recommended for UAG? To answer that question, let’s think about what UAG is designed to do:
Provide anywhere access to your applications from the Internet
Enable support for a single sign-on (SSO) experience
Create application awareness and allow for control over application behavior based on client system characteristics
Enable you to user a wide range of authentication repositories
Take advantage of the SSL protocol to provide remote access for any client system that is behind a device that allows outbound SSL
One thing you should keep in mind is that UAG was designed and was tested to confirm that it can and should operate as the Internet-facing gateway. While you could place another firewall in front of the UAG solution, doing so would incur an additional cost and from a security perspective, would introduce an additional complication that could actually reduce the overall security posture of the solution. And of course, the reason we don’t need a firewall in front of the UAG server is because UAG uses TMG‘s firewall functionality. Since the TMG firewall is a battle tested network firewall that has been on the edge of the network for years, there is no real reason to put a firewall either in front of or behind the UAG solution.
The TMG solution
Now let’s back up a bit and look at TMG. When and why did we choose to deploy TMG? To answer that question, let’s think about what TMG is supposed to be about:
The TMG is an inbound and outbound access firewall, so if you need to allow for outbound access, you need TMG, since UAG is about inbound access only.
Server publishing is a lot easier with TMG. If you want to publish services such as SMTP, POP3, IMAP4, RDP and similar server protocols, then TMG is going to be a better and easier to manage solution.
TMG has a multi-network model that allows you to create policies for multiple networks. In this way, you can have a DMZ network, and Internal Network, a Servers Network, a Management network and any other number of networks. You can then configure firewall policy that controls the traffic between those networks. With UAG you get a single external network and internal network; you don’t have the multi-network capabilities that you have with TMG.
If you are interested in layer 3 VPN connections, then TMG is the way to go. TMG supports remote access client VPN connections using PPTP, L2TP/IPsec and SSTP. While UAG allows you to configure some remote access VPN connections, the configuration is a bit more complex and more fragile. In addition, UAG does not support site-to-site VPN connectivity.
Functional differences
The more deeply you dive into the product characteristics, the more you realize that TMG and UAG are not as much alike as you might have thought. They’re designed for different purposes, and thus they have different functionalities. In summary, here are the functionalities that you get with UAG but not with TMG:
- Comprehensive Single Sign-on (SSO)
- SSL VPN (but you do get that with Windows Server 2008 and up)
- Endpoint security
- Deep application awareness
- Broader authentication options
And here are functionalities TMG provides, that you don’t get with UAG:
- Outbound proxy
- Windows EBS deployment
- Email publishing (SMTP, POP3, IMAP4)
- Integrated email filtering
- Malware inspection
- Intrusion detection
The TMG firewall is designed out of the box to be used in a number of network scenarios. These scenarios include:
Edge firewall
Tri-homed DMZ
Back-end firewall
Unihomed (hork-mode) web proxy
Each of these network topologies is associated with a TMG firewall Network Template. A Network Template is a wizard that automatically configures the TMG firewall to use the deployment model programmed into the template.
When you configure the TMG firewall as an edge firewall, its main job is to act like a layer 3 network firewall for inbound and outbound access and protection.
Another option is the tri-homed DMZ configuration, which used the 3-leg perimeter template. It’s called tri-homed because this configuration has three NICs connected to three different networks. One network would be the default internal network, another would be the external network, and the third would be a DMZ network. You can use firewall rules to control traffic to and from each of these networks.
One thing of which you should be aware is that unlike ISA 2006, where it was assumed that you would use a NAT relationship between the default Internal Network and the tri-homed DMZ segment, the TMG tri-homed DMZ network template does not make assumptions regarding the routing relationship between the networks. The Network Setup Wizard offers you the choice to define the routing relationships
The back-end firewall network template is similar to the edge firewall template. The difference is that the TMG firewall’s external interface is connected to a DMZ segment. The DMZ is defined by the “external” interface of the TMG firewall and the “internal” interface of whatever is front of the TMG firewall. In fact, the network template is almost exactly the same, as it gives you the choice of whether you want a NAT or Route relationship between the internal network and the DMZ network (which is considered external to users on the Internal network).
The final topology to consider for the TMG firewall is the unihomed (hork-mode) web proxy. This is a stripped down version of the TMG firewall because the only duties that the firewall can provide are web proxy (forward and reverse) and remote access VPN server.
Summary
In this article, we took a look at the key differences between TMG and UAG from a new perspective: determining whether UAG might serve as a feasible (if expensive) replacement for TMG in the event that Microsoft continues support for it after TMG is considered dead.
I think it becomes clear, as we look at the design purposes for the two products, that UAG was never intended to be used in that way. There may be some cases where you need particular functionalities offered by UAG and it might make sense to deploy it where you had a TMG Server before. However, the TMG that is installed with UAG was intended to protect only the UAG Server – not to fill the role of primary edge server for your network.
Although some folks think of UAG as “TMG on steroids,” that’s not really accurate. While it offers functionalities that TMG doesn’t, it also lacks some of TMG’s important functionalities, such as outbound proxy services and email publishing and filtering. It’s also a good deal more expensive than TMG, and finally, we have no guarantees that Microsoft has long-term plans to keep developing and supporting UAG. It could go the way of TMG in the future.
For all these reasons, if you’re looking at what to use to replace your TMG firewalls, I’d recommend that you look beyond UAG.
