Direct Access on Windows 2012 R2: Manage Out with a Hardware Load Balancer

A lot has been written regarding Manage Out for Direct Access (DA), but for those who may not be familiar with it, it is the mechanism within Direct Access that allows corporate endpoints to initiate network communication with remote clients that are connected via Direct Access.

Let me give you an example – Many companies have regulatory or compliance systems inside their datacenter that are designed to proactively reach out to client machines to check for certain things such as software updates, updated virus scanner databases, firewalls, etc. These systems will initiate the connection to each client to perform these checks, and when the client is actually a remote client that has an established session with the Direct Access Server, Manage Out is the functionality on the DA server allowing that connection to reach the remote client.

There is an important consideration that needs to be taken into account when deploying a scaled out DA environment that leverages Hardware Load Balancing (HLB).  Since the Manage Out connection that is headed out to the client needs to traverse the pre-established client DA Server connection (in red in the graphic below), we need to make sure that the Manage Out connection gets sent to the right DA server. If the Manage Out connection is forwarded to the wrong DA server, the Manage Out connection will fail.

Assuming your environment is capable of supporting Manage Out (IPv6, or ISATAP, internally), lets quickly discuss client protocol connection support.

1. Teredo – I have previously written iRules to support Manage Out for Teredo clients on UAG, however through later deployment history and an open dialogue with Microsoft, I can say at this point “Do not configure/advertise DA Teredo services if you require Manage Out to work in an HLB deployment”. Simply put, there is no easy way to match the Manage Out & pre-established DA connections. The original iRules that were created for UAG attempted to do this, but it didn’t result in a very efficient solution. At some point this may be revisited, but I haven’t worked with any customers up to this point that had a problem with disabling Teredo.

2. IP-HTTPS – Works! and works well! If you require Manage Out and you are using HLBs, you will want to configure DA/DA clients to use IP-HTTPs and then configure your BIG-IP appropriately.

Now that we have out of the way (sorry Teredo fans (are there any??)), let me talk at a high level about how we enable Manage Out to work by matching up Manage Out connections with the appropriate Direct Access Server.

Unlike with Teredo, each DA server has its own unique pool of IPv6 addresses, identified by a range or prefix, that it uses for IP-HTTPS based clients that need to communicate on the corporate network. Once we identify the IPv6 prefix assigned to each DA server, we can use this to configure the internal BIG-IP to route the Manage Out connection to the right DA server. It’s actually fairly straight forward.

Step 1. Identify the IP-HTTPS IPv6 prefix for each DA server.

On each DA server, open a PowerShell session and issue a “Get-DAServer | ft ClientIPv6Prefix”. This will return the prefix we need. In the graphic below, my first DA server returned 2131:0:0:1000::/59 as its unique prefix.

Be sure to note the prefixes for each DA server, as well as the IPv6 address bound to its corporate network facing interface. In my case it was….

Direct Access Server

Corporate IPv6 address

IP-HTTPS IPv6 Prefix

Direct Access Server 1



Direct Access Server 2



Step2. Using these prefixes, configure the internal BIG-IP to route Manage Out connections to the appropriate DA server.

As every seasoned BIG-IP administrator knows, there are always several ways to configure the BIG-IP to handle traffic in a specific fashion. For this portion of the configuration, I chose to use Forwarding Network Virtual Servers (VIPs). I like the granularity it gives me with respect to control & statistics reporting, but the downside is that you end up creating a VIP for each DA server.

- It’s a Forwarding VIP because we want the BIG-IP to simply forward the traffic to right DA server, not direct the traffic at it.

- It’s a Network based VIP, because we want the BIG-IP to handle the traffic for the range of the IPv6 prefix space, not a single IP.

So for each DA server, create a forwarding, network based, Virtual Server that uses the IPv6 prefix for the destination address, and the corporate network facing (aka internal) IPv6 address as the pool member. If you are using an external and internal BIG-IP for this deployment (like the architecture above), these VIPs/Pools are create on the internal BIG-IPs. Nothing extra needs to be configured on the external BIG-IPs to support Manage Out.

1. Create the pool (Do this once for each DA server in your farm), with the pool member being the corporate IPv6 address of your DA server.

2. Create the Forwarding Network Virtual Server (VIP) (Do this once for each DA server in your farm), and point it to the appropriate pool

Once you have the VIPs/Pools created, Direct Access Manage Out should work to all IP-HTTPs clients. No iRules are necessary!

Please send me any feedback on this solution. I am hoping that it makes into a formal deployment guide at some point. Thanks!

Published Jun 06, 2014
Version 1.0

Was this article helpful?


  • Using this Manage Out method you don't have a fault tolerant solution for Windows 7 DA Clients. "Step 1. Identify the IP-HTTPS IPv6 prefix for each DA server." DA Servers will only have a unique IP-HTTPS (or Teredo) prefix if they are in separate DA Entry Points. If they are in separate DA Entry Points Windows 7 DA Clients won't failover between them.
  • Great article... but when I run the Get-DAServer command above on each of my DA servers, I get the same IPv6 address.
  • This has the potential of being a great article. I'm just missing the 2 lower screenshots to completely understand what you have done. I would greatly appreciate if you fixed them. As of right now they look just like the 3rd image.