Monday, 18 March 2013

Windows Server 2012 DirectAccess Manage Out using Native IPv6

Please Note: The approach provided within this blog post is not suitable when using an External Load Balancer (ELB), Single NIC topology or a multisite DirectAccess topology and you will need to use a more traditional native IPv6 deployment where you define your own IPv6 prefixes which are entered as part of the DirectAccess wizard configuration process.
I wrote a previous blog article titled Limiting ISATAP Services to UAG DirectAccess Manage Out Clients some time ago now which proved to be quite popular as a way to allow manage-out functionality for UAG DirectAccess solutions without effecting the entire network through the use of wide spread ISATAP enablement. That article originated as many people weren't aware that in order to manage DA clients from an intranet machine, it needed to be IPv6 capable (read native IPv6 or using a transition technology like ISATAP). Given the use of ISATAP you needed to be a little careful with how best to enable it for a subset of management clients, otherwise there was potential to impact the entire internal network and bad stuff can happen.
Given the advent of Windows Sever 2012 DirectAccess and the new Unified Remote Access role, Microsoft no longer recommends the use of ISATAP to facilitate manage out scenarios in favour of using native IPv6. This statement is discussed here and appears to be the general MS recommendation given the potential problems associated with ISATAP deployments that can, and often do, go wrong. The likely first reaction to that news is likely to be “…but I don’t understand IPv6 and our intranet doesn’t have it enabled or configured yet, so how do I do that?” or “…why can’t I just stick with ISATAP? It seems easier”. Both of these reactions are understandable, but I wanted to provide an example to show that it isn’t actually that scary and it is potentially even easier to implement than the old ISATAP method, especially for a small number of management clients. Nobody is saying that you can’t use ISATAP; in fact the ISATAP router functionality is still enabled by default on the DA server when using an IPv4 address on the internal network adapter. Although the DA Server is configured as an ISATAP router by default, it should be noted that it will not service clients until the necessary ISATAP DNS A record has been created and the entry removed from the DNS global query blocklist. However, maybe it is time to start thinking about that historic ‘ISATAP or native IPv6’ decision process and the primary reason that I am writing this blog post :)
Please Note: The obvious caveat, or limitation, here is that the communication path (read network infrastructure) between the management client and the DA server will need to support (be able to forward) native IPv6 traffic. This is likely to be very environment specific and may need to be tested, or involve discussions with your network guys to understand if this is a viable option. For example, an IPv4-only back firewall is a good example of something that may prevent the use of native IPv6 for manage out. For networks that cannot support native IPv6, some form of IPv6 encapsulation or transition technology will need to be used (using the method discussed in my previous blog post perhaps).
So, what does it mean to use native IPv6 for managing DA clients from the intranet then? Well, in it’s simplest form it means manually configuring your management clients with static IPv6 addresses from a suitable IPv6 prefix and then providing the appropriate IPv6 routing to reach DA clients by way of the DA server they are connected to. For this blog post, this is the example I am going to use to begin with and is based around the same premise as my last article; namely that the number of management clients involved is usually pretty small, or involves the use of ‘jump hosts’ that are shared by admin/support staff. Hence, the plan is to keep things simple for now and continue with the use of manual IPv6 configuration to describe the overall concept. At this juncture, it may also be useful to know that I wrote a basic overview of IPv6 addressing choices for DirectAccess in a previous blog post here which may also prove useful if you considering a more automated approach to IPv6 configuration.
When DirectAccess is installed, a 6to4-based organisation prefix is created automatically using the following IPv6 prefix format 2002:WWXX:YYZZ:3333::/64 where WWXX:YYZZ are the hexadecimal representations of the primary public IPv4 address octet pairs bound to the external network adapter of the DA server (with the IPv4 address formatted as WW.XX.YY.ZZ). So, using an example where the primary public IPv4 address is: this would result in a 6to4 prefix of: 2002:836b:2:3333::/64 as 131 in hex is 83, 107 is 6b and 2 is 2.
Please Note: If you are using your DirectAccess server behind a NAT device and consequently using private IPv4 addresses on the external network adapter, as opposed to public IPv4 addresses, the IPv6 prefix will be in the form of: FD##:####:####:7777::/96 as per RFC 6147. The DA client IPv6 prefixes for Teredo and IP-HTTPS will also follow a similar structure when using private IPv4 addresses.
Still with me? If so, let’s move on…
Given this IPv6 prefix, we can now use this to generate static IPv6 addresses for the management clients using the format 2002:836b:2:3333::# where # is a manually chosen unique number used by each management client. By default the DA server will automatically use the 2002:WWXX:YYZZ:3333::1 address, so anything above this value should be fine as long as though it is unique and not in use. Furthermore, when defining the static IPv6 address, the subnet prefix length will normally be 64.
So with the static IPv6 address defined, all we need to do now is consider how we ensure that IPv6 traffic can reach the DA clients that are connected to the DA server. This is achieved in two ways; by defining an IPv6 default gateway, or by defining specific individual IPv6 static routes. Focusing on the first option, as mentioned, for our example the DA Server will be assigned a static address of 2002:836b:2:3333::1 so we can simply define this as the IPv6 default gateway on management clients. The final result is shown below:
Making the DA server your default IPv6 gateway may not be desirable, or recommended in most cases. Therefore, as an alternative approach you may wish to be more specific and ensure that only IPv6 prefixes that are used by DirectAccess clients are routed to the DA server by way of specific IPv6 static routes. This provides much better control over IPv6 routing and allows for specific DA client management traffic to be considered without impacting on other IPv6 services. This is achieved by defining the static routes, on each management client, to cover necessary DA client IPv6 prefixes, as opposed to defining a global/single IPv6 default gateway. For our example, these include:
IP-HTTPS Clients Prefix: 2002:836b:2:1000::/64
Teredo Clients Prefix: 2001:0:836b:2::/64
Turning these IPv6 prefixes into IPv6 static routes, we get the following respective commands based upon our example above:
netsh int ipv6 add route 2002:836b:2:1000::/64 [Name of Intranet network adapter] 2002:836b:2:3333::1
netsh int ipv6 add route 2001:0:836b:2::/64 [Name of Intranet network adapter] 2002:836b:2:3333::1
Please Note: Sharp eyed readers may have noticed that I have not mentioned 6to4 clients. The reasoning behind this decision is that the 6to4 transition technology only works when the DA client has a public IPv4 address (which is a typically rare scenario nowadays) and issues often occur in networks where the DA client gets a public IPv4 address but cannot actually reach the 6to4 relay due to some form of in-path NAT. For these reasons, it is recommended practice to disable the 6to4 transition technology on DA clients and therefore it is not covered above.
At this point, those of you more familiar with IPv6 may be thinking “…is this guy mad? Why is he defining static IPv6 addresses??!!” Well, firstly, it makes things simple for the given example and in reality if you only have a small number of management clients (or ‘jump hosts’) it is actually quite feasible to use static addresses. This approach requires no additional network infrastructure, or network configuration for IPv6, and is actually pretty quick and easy to do. The obvious problem here is that this admin overhead doesn’t scale well and the IPv6 protocol was specifically designed to use a concept of automatic address selection and static addressing is therefore pretty much a thing of the past. However, as discussed, we are dealing with a very specific example, trying to keep things simple and we are not designing IPv6 for the entire intranet.
In the event that you have a larger number of management clients, or just feel that static configuration is not appropriate for your environment, it is better to use some form of IPv6 auto-configuration mechanism in order to provide management clients with addressing information and route assignment, without the need for human intervention. IPv6 auto-configuration can be performed by any capable Layer 3 network device (which includes a Windows Server) although as discussed, this is out of the scope of this blog post at this time. However, it may be interesting to note that the necessary steps for using a Windows Server to provide IPv6 auto-configuration have been covered in one of my previous blog posts here
Now we have management clients with IPv6 addressing information and the appropriate IPv6 routing table entries, we can hopefully begin managing DA clients from the intranet. At this stage you should be able to ping a remotely connected DA client from a management machine and receive an IPv6 response, assuming there is a route to the destination and ICMP echo requests are enabled in the firewall.
Important: Ping is helpful to verify that basic connectivity is working and validate you management client IPv6 configuration parameters, however, should only ping work but not any other type of connection then it’s most likely to be an IPsec-related issue. This is because ICMP is exempted from the DirectAccess IPsec tunnels and therefore provides limited value when testing connectivity from management clients to DA clients. More discussion on this topic cab be found here.
Before we can have a fully working solution it may also be necessary to consider a few additional steps, which based upon my own experience, are not totally obvious and can easily be forgotten.
If you have defined new IPv6 addresses on System Center Configuration Manager servers, it will be necessary to use the Refresh Management Servers option in the Remote Access Management console, as shown below, in order for the new IPv6 address information to be added to the DirectAccess clients GPO:
The same thing is true for Domain Controllers, but I am guessing that you will not be defining these as specific management clients. Furthermore, implementing IPv6 addressing on Domain Controllers introduces additional considerations to Active Directory functionality and operation which are key to ensure services are not impacted.
For all other management clients, it will be necessary to manually add each of them to the Management servers list which can be found in the Step 3: Infrastructure Servers section of the Remote Access Management console as shown below:
Once entries have been added, the updated configuration can be committed using the Finish… button.
The final task is to run gpupdate /force on management clients and DA clients to ensure they get updated GPOs which have been modified by the changes described above. Alternatively, you can wait for the next Group Policy refresh cycle but I’m normally kinda impatient!
Please Note: Don’t forget that it will still be necessary to define Windows Firewall with Advanced Security (WFAS) inbound rules on the DA clients to allow for the necessary permitted network access as discussed here.
All being well, you should now be able to initiate outbound management requests to DA clients from management clients on the intranet without necessarily have to resort to ISATAP and hopefully you have a little more confidence that using native IPv6 is not quite so scary after all :)
Now, go manage out with native IPv6!
P.S. Special thanks to Philipp Kuhn for the article inspiration and technical review assistance!


  1. Way more information than on Microsoft's TechNet pages

  2. I take it that's a good thing! ;)

  3. Excellent article Jason, Thank you. There is definitely a shortage of quality material in this area.

  4. Question, your article states that ISATAP wont work as described in your previous tasks only if its a global change on the server 2012 DA service? Its seems like during my testing it was working on server 2012 until I placed two servers into a cluster and setup the NLB for them.

    I had DNS settings for the VIP and both DA servers

    client in the manage out security group gets an ISATAP address
    client in management servers doesnt (customisatap shows disconnected)

    is this related?

    1. Hi Hunter,

      Not quite sure I understand the's not about ISATAP not working, but more about native IPv6 being the recommended approach by MS now.


    2. I guess i mean will ISATAP still work in the same scoped fashion as your previous article. or on server 2012 will it only work with the global ISATAP DNS change as you stated in this article.

  5. Hi Hunter,

    Yes the old limited ISATAP article is still applicable to WS2012 and works the same to my knowledge.

    With WS2012 the recommendation is native IP6, hence this article to supersede the older one...



  6. Dear Jason Jones,

    Thanks a lot for wonderful blog.

    Is there any PowerShell 3.0 equivalent Cmdlets for netsh command? I am sure 100% it may be there, since Microsoft is pushing Windows Server administration towards PowerShell 3.0.

    But in all the tutorials and explanations, we are seeing only netsh command for ISATAP config.

    Please help.

    Thanks and regards


    1. Yes have a look here: I am slowly moving onto PowerShell, but the old Network Shell commands still stick with me! :)

  7. Dear Jason,

    I just working on native IPv6 configuration for my management out clients. My DA server is behind a NAT device so I have FDxx: addresses:

    DA Server:
    - physical interface: fd78:9f7e:c716:3333::1/64
    - httpstunnel interface: fd78:9f7e:c716:1000::1

    Management station:
    - physical interface: fd78:9f7e:c716:3333::a02:100a/64

    I can ping from management both IPv6 addresses of the DA server. But I cannot ping or reach any DA client with addresses fd78:9f7e:c716:1000::/64.

    I have added firewall rules on DA clients to accept incoming traffic on all profiles from remote location fd78:9f7e:c716::/48

    Do I need to activate IPv6 routing on RRAS service on DA server to get native IPv6 routing activated?


    1. Hi Marc,

      Nope, the changes defined in the blog post should be everything you need...

      Have you added an IPv6 default gateway or IPv6 static routes on the management clients?



    2. Hi Jason, I am having exactly the same problem as Marc Aigner and the management clients use the DA server as the defaut gateway.

      In fact, the DA server (single interface NAT) never passes on an IPv6 packet from a DA client as far as I can tell - it only ever passes on an IPv4 packet (seen by the DA client as an :7777:xxxx:xxxx address) - I confirmed this with Wireshark. What has this to do with manage out? It seem a reasonable guess that this is exactly why manage out is not working: the NAT DA server expects inbound packets to be IPv4 only so it effectively is just dropping the IPv6 packets from the manage out client.

      I wonder if NAT DA + no-ISATAP (e.g. when using multisite) is simply not possible without a full IPv6 infrastructure? I have trawled the Internet and everyone except you says "use ISATAP with limited scope".

    3. I got exactly the same problem as you Marc and Mossywell. Did you find a solution?

    4. I have exactly the same problem as Marc and Mossywell, did anyone find a solution?

    5. From memory.... yes, the 3333::1 interface doesn't route. (Well, I never got it to!) So, add in a new separate IPv6 address onto the DA server, make that, not the 3333:11 address, the default gateway for the manage out clients. Then it worked. For me!

    6. Great mossywell :) I entered an secondary ipv6 address on the same interface on the DA server. I just used another address in the same address space: fd78:9f7e:c716:3333::138. Is this correct?

      But it still wont work, but at least now tracert to the DA client from an internal server shows the fd78:9f7e:c716:3333::1 address as first hop. I have engaged MS support to look at the issue.

    7. @Andre - can you please describe your setup/topology? Are you using a single NIC topology by any chance?

    8. FYI - I'm planning on doing a follow up blog post that shows how to use a small-scale native IPv6 configuration to allow for just manage-out. This will then provide a solution for scenarios like ELB/MultiSite that are not covered in the 3333:1 approach covered in this blog article. I'm pretty sure the above setup also deosn't work for single NIC topologies, but I don't tend to recommend that toplogy myself.

    9. Hi Jason

      Yes, I am using a single Nic setup :(

      Then it looks like my only option is limited ISATAP deployment...

    10. Looking forward to your new post :)

    11. IIRC there is a WFP filter called "Forwarding block filter in single NIC" that only exists with a single NIC topology that breaks native IPv6 manage-out scenarios...I should probably add single NIC to the list of unsupported scenarios for this blog article...

    12. ... but it does still work without ISATAP (limited or otherwise). :) I have it set up as a single NIC, natted, using NLB (yup), with manage out working and no limited ISATAP. Having done it, I can see why it might not be a supported scenario!

      @Andre, no, use of the 3333:: range doesn't work. The new IP address needs to be part of your InternalIPv6Prefix and you'll also need to design it so that you can route traffic from the manage out client to the address you set. Something like aaaa:aaaa:aaaa:1::aob:c0d. At the end of the day, there's no mystery about the DA server - you can think of it as an IPv6 router in many ways: throw IPv6 traffic at it and it'll route it accordingly. That said, NLB adds a few twists... :-o

    13. aha, then I used the wrong IPv6 address space. But like Jason said, I will go for the limited ISATAP approach for now. And stick to double NIC for the next deployment.

    14. Hello mossywell. I don't know if you are still hanging around here, but I could use some help with the configuration that you get working. I have added an ipv6 address to the single nic on the DA server and have that address set up as default gateway for my manage out client on the same ipv6 prefix. As mentioned these are not the 3333:: range.

      Traffic from manage out client reaches the DA server and then drops. As far as I can tell nothing is being routed to the DA client. Any further advice?

  8. Jason,

    That you for writing such an excellent blog article. I have been searching for weeks for ideas on how to manage DirectAccess clients in an IPv4-only environment and this so far is the best information I have seen.

    I was wondering if you could give some advice on a slight variation of this. Our management clients will be on different subnets than our DirectAccess server, so I don't think just setting up a static route will not be enough. Is there something I'm missing.

    If I am correct, what are your thoughts about using IPsec tunneling (not via VPN) or enabling VPN and opening that access to our management clients, and then somehow routing the IPv6 over those tunnels? In theory, it seemed that both would be good choice, but it seems that I can't do IPv6 on the VPN in our IPv4-only configuration and I can't seem to get any IPsec rules to do anything.


    1. The easiest answer to that is to put a jump host (RDS sessions host) in the same subnet as the DA servers and then use that server to initiate manage-out connections from...other than that you would need to look at a native IPv6 deployment and integrate DA with that rather than leveraging the DNS64 prefix used by DirectAccess as described in the blog post.