(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)
A question that I see frequently regarding UAG DirectAccess is “what topology options are available to me? Where’s the best place to put the UAG DA server?”. As with all questions of this type, the answer depends on what your requirements are and what you existing infrastructure looks like.
While there’s probably an unlimited number of options available for placement of the UAG DA server, I think there are three general scenarios on which you can build out a deployment plan. These three scenarios are:
- Placing the UAG DA server between a front-end and back-end firewall
- Place the UAG DA server in parallel with your front-end firewall
- Place the UAG DA server behind a front-end firewall, with no back-end firewall
Figure1 show a high level overview of what the UAG between a front-end and back-end firewall configuration would look like. Of course, the nature of the DMZ between the firewalls might be more complex than this. In the figure, I describe only a single segment in front of the UAG DA server and a single segment behind the UAG DA server. Typical enterprise networks will have multiple segments on their DMZs.
In this configuration the front-end firewall must be configured to:
- Allow TCP destination port 443 inbound to and TCP source port 443 outbound from the external interface of the UAG DA server (this is required to support the IP-HTTPS IPv6 transition protocol that enables IPv6 messages to be tunneled over the IPv4 Internet)
- Allow destination port 3544 inbound to and UDP source 3544 outbound from the UAG DA server’s external interface (this is required to support the Teredo protocol, which is another IPv6 transition technology that allows you to tunnel IPv6 messages over an IPv4 Internet)
- Allow IP protocol 41 inbound to and outbound from the UAG DA server’s external interface (this is required to support the 6to4, which is yet another IPv6 transition technology that enables IPv6 messages to be sent over an IPv4 Internet).
The back-end firewall must be configured to:
- Allow IP protocol 41 inbound to and outbound from the UAG DA server’s internal interface (this is to allow ISATAP messages to be communicated between the UAG DA server and machines on the corpnet)
- Allow all IPv4 and IPv6 traffic inbound to and outbound from the UAG DA server’s internal interface (this should be thought of a starting place, because most organizations aren’t aware of their traffic profile, and limiting the protocols could cause service disruptions)
We assume that this is going to be the most common deployment model for the UAG DA server, and that’s why you’ll see it as the only one described on TechNet. Something that should be made clear at this point is that just because this is the only deployment model described on TechNet doesn’t mean that it’s the only supported configuration. The following two configurations to be discussed are also viable options and are supported.
Figure 1: UAG DA server placed between two firewalls
Figure 2 describes a deployment model where the UAG DA server is placed in parallel with the front-end firewall. This is a secure option because the UAG DA server and the network behind it are protected by the TMG firewall that is also installed on the UAG DA server. It’s important to note that while the TMG firewall is installed on the UAG DA server, it is not to be used outside of its ability to protect the UAG DA server and the network behind the UAG DA server. No outbound traffic is supported through the UAG DA server, and no DMZ NICs are supported on the UAG DA server (by DMZ, I refer to the fact that TMG supports an unlimited number of network interfaces; the UAG DA server will always have only two interfaces).
In this configuration, the UAG DA server does not require any packet filters on a front-end firewall, since there is no front-end firewall in front of the UAG DA Server. The UAG DA server sits in parallel with the current firewall. In addition, there is no back-end firewall, so no filters need to be configured on a back-end firewall.
One could argue that just because you have the UAG DA server sitting in parallel with the current front-end firewall, then way not put a back-end firewall “just in case”. There’s no reason why you can’t do that. However, noting the packet filters used on the back-end firewall in the first scenario, there’s really no point in placing another point of failure between the UAG DA server and the resources behind it – since the back-end firewall is essentially allowing all traffic between its internal interface and the corpnet behind it.
Figure 2: UAG server placed in parallel with front-end firewall
Figure 3 represents the third general deployment option. In this scenario, the UAG DA server sits behind a front-end firewall with no back-end firewall behind it. In this configuration, the packet filters for the front-end firewall as the same as those applied in the first scenario. And the back-end packet filters don’t apply, since there is no back-end firewall. This might be considered the preferred solution by many organizations, since the packet filters required on the back-end firewall (at least at the beginning of the deployment) essentially allow all traffic between the internal interface of the UAG DA server and the corpnet. I suspect that this will be a persistent configuration in most organizations, so why not simplify the configuration and delete a point of failure by eliminating the back-end firewall entirely?
Figure 3: UAG server placed behind front-end firewall with no back-end firewall
It’s important to note that all of these are supported deployment scenarios and none is necessarily superior to the other. However, there may be performance advantages to putting the UAG DA server behind a front-end firewall, since this will reduce that packet processing overhead on the UAG DA server and end up improving the overall performance of the UAG DA solution. A similar argument can be made for the back-end firewall, but that can only be said if you have worked up your traffic profiles and know what traffic is going to be required between the UAG DA server and all the servers and other networked devices the UAG DA clients are going to connect to on the corpnet.
Finally, be aware that these are simplified diagrams that only include the salient components of the deployment model. There are going to be other network devices that you need to take into account, like bandwidth shapers, Network IDS devices, layer 3 switches that might do more than layer 3, and other devices. While you’ll need to take those into account in your overall design, they don’t impact the basic designs discussed in this article.
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: https://twitter.com/tshinder