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: 131.107.0.2 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
6to4 Clients Prefix: 2002:836b:2::/64
Turning the first and second of 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: Although I have provided the 6to4 client prefix, I have not defined an IPv6 static route. 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 there is little value in defining a respective static route for the 6to4 client IPv6 prefix. If the static route is required however, the above examples provide the necessary structure and will only require minor modification to add the appropriate route.
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 post 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!