UAG DirectAccess Server Deployment Scenarios

(Discuss UAG DirectAccess issues on the TechNet Forums over at

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.



Tom Shinder
Microsoft ISDiX/SCDiX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time):
Follow me on Twitter:

Bookmark and Share

Comments (13)
  1. Anonymous says:

    Hi James,

    Segment C could be on-link or on a remote subnet.

    The UAG DA needs to be the gateway for IPv6 communications (if you want to support 6to4), but does not need to be the gateway for IPv4 communcations, so you can use an alternate gateway to the IPv4 Internet.



  2. Anonymous says:

    Hi Paul,

    No way to disable the TMG firewall component of the UAG DirectAccess solution. TMG includes several technologies that we depend on.



  3. Anonymous says:

    Hi James,

    UAG should never be the default gateway for intranet client, since it doesn't enable any outbound access. For OWA publishing, the published Exchange Server just needs a route to the internal IPv4 address on the UAG server. For SSTP, the hosts on the internal network that need to respond to requrest from SSTP VPN clients just need a route to the IPv4 network ID assigned to the VPN clients (how that's handled depends on whether you use a on-subnet or off-subnet network ID for VPN clients).



  4. Anonymous says:

    Hi Fred,

    You could do that, but be aware that you need a public address DMZ, since you can't NAT to the UAG DirectAccess server.



  5. Anonymous says:

    Hi John,

    You can use the private IP addresses in your DMZ as long as you don't put the DirectAccess server in the DMZ 🙂

    The UAG DirectAccess server requires to consecutive public IP addresses on the external interface. You won't be able to complete the UAG DirectAccess wizard without them.

    Using public IP addresses on the intranet will introduce some issues. The best workaround is to disable 6to4 on all computers (including the DirectAccess clients).



  6. John Rolstead says:

    Good write up Tom,

    I have a question around pubic v private IP addresses.  Our DMZ segment is private IP address range  DirectAccess docs state that we can't use private IP range.  Our Intranet is using public IP range.  Can we use private IP range in DMZ segment?


  7. paul says:

    Is there a way to disable TMG part of UAG?  we have it between two firewalls and we just want it for directaccess and allow traffic like pings, Remote desktop and SCCM.


  8. James Hamilton-Adams says:

    Tom, thanks for the diagrams, thats the first place (after looking through most of the technet documentation that I have actually seen these drawn out!

    However, what about some sample IP address ranges? For example, in Fig. 3, how do the servers on the right of the diagram (segment C) connect to the internet? Do they need another router between them and Segment A, as I am assuming these will be different subnets?


  9. Fred Berestoff says:


    What about existing DMZ networks that are currently protected with a three legged ISA 2006 server?  Where would you recommend placing a UAG that can both provide direct access for mobile users, and also be used for sharepoint application publishing?  (which resides in the DMZ)



  10. James Hamilton-Adams says:

    Hi Tom,

    In an example where DA is not required (at least for now), but we are using UAG to publish Exchange OWA and SSTP for example, (and using IPv4) I assume that the UAG box is not the default gateway for internal clients (like TMG would be) – is this correct? Or can UAG be the default gateway as well as the reverse proxy?

    Many thanks

  11. James Hamilton-Adams says:

    Hi Tom,

    So from an IP Addressing perspective, I assume that the two different interfaces for UAG must be on different subnets? If that is the case I assume you would either need to use logical subnetting or have another device performing NAT or routing sitting "in parallel" with the UAG Server so that internal hosts can still route to the internet as normal?

    Thanks for the clarifications!

  12. Andrej says:

    Hi Tom,

    Is it possible to separate roles of UAG. I would like one server with the role of Direct Access to be placed in DMZ, with one interface on Internet and one in DMZ. Another server would have a role of Portal Server and have one interface in DMZ and another in private LAN.

    with kind regards

  13. Resonate says:

    We are doing a deployment of Direct Access and were receiving significant challenges from the firewall team to our request for an ANY-ANY internal firewall rule from the DA servers to the internal network.

    All of the documentation I can find on this states the firewall should be configured in this way and as a result I am facing delays in deployment.

    Can anyone advise of any official documentation that relates to this configuration or offer up any advise how I can address their concerns?


Comments are closed.

Skip to main content