Tuesday, 25 May 2010

The Path to DirectAccess – Part 2: Thinking About IPv6

Given the discussions in Part 1 of this series, all further articles assume that we are using (or talking about) UAG DirectAccess and not native DirectAccess.

One of the first decisions when beginning a DirectAccess (DA) design, or deployment, is to consider the intranet IPv6 connectivity model as discussed here. This decision is often greatly biased by the existing network configuration and infrastructure in use. However, it is likely that the DirectAccess implementation is the first project that may have raised the question of intranet IPv6 addressing. This is probably something you have been aware of with the introduction of the IPv6 protocol stack in modern Windows client/server operating systems, but often it becomes “…something else to learn about when I have more time…”

Intranet IPv6 Addressing Strategy

Given the choices available, it is likely that ISATAP-based IPv6 connectivity will be the optimum solution; or only viable option available for environments running IPv4-only networks. This is especially true for environments that cannot support the native IPv6 needs at the networking hardware and/or routing layers. 

However, as good as ISATAP is, it is not a pure or final solution and is designed as a transitional step in an overall IPv6 deployment plan.

From what I have read, an alternative approach for an IPv6 deployment is to use Dual Stacks as opposed to Tunnelling technology (like ISATAP) where hosts are configured with both IPv4 and IPv6 addresses at the same time. The dual stack approach is relatively easy to configure, pretty flexible and often simpler to implement than encapsulation or tunnelling technologies. This approach also seems to remove the following ISATAP limitations:

  • The client OS needs to support ISATAP, fine for Windows, but maybe not everything else.
  • For a client OS that does support ISATAP, we introduce an ISATAP device/adapter which can break or require troubleshooting.
  • Typical of all tunnelling technologies, tunnel entry and exit points need to perform additional work (encapsulation) and potentially become single points of failure for IPv6 communications.
  • The use of ISATAP is not always desirable in environments where Network Intruder Detection Systems (NIDS) are present.

Not wanting to make things too easy, I started to think about considerations for deploying IPv6 on intranet systems as a pre-cursor to our actual DA implementation. We are going to have to do this one day I thought, so why not start sooner rather than later! It would also force my ascent of the Ipv6 learning curve to begin a little earlier than I predicated :)

The end result of this planning would be to allow me to define the correct IPv6 prefixes in Prefix Configuration section of the UAG DA wizard.

Based upon Ben Bernstein’s blog entry available here there would seem to be only two real options when looking at a suitable intranet addressing strategy as part of an overall DA deployment:

  1. Option 1: Obtain Global Unicast IPv6 addresses from my ISP
  2. Option 2: Utilise the IPv6 6to4 addressing format based upon our own public IPv4 address space

After contacting our ISP, it (finally) became apparent that Option 1 was not achievable at this time for any of our Internet connections, which made the choice pretty easy ;)

So, how do we go about creating a suitable 6to4 addressing structure for our environment?  

Creating the IPv6 Address Structure

First, the complicated bit…

All 6to4 addressing begins with ‘2002:’ and this is defined within the first 16bits of the IPv6 128bit address. The next 32bits are defined based upon a hexadecimal representation of one of the IPv4 public IP addresses assigned to the UAG external interface. The next 16bits are used to represent the subnet ID. The remaining 64bits are used to represent the host address. This can be summarised as follows:

[2002]:[Public IPv4 Address in Hex]:[Subnet ID]:[Host Address]

or graphically:


So, let’s make this a bit more real (and hopefully easier) by using a specific example lab environment as shown below:


As can be seen, our first public IP address is If we separate this into specific octets we get:


If we now convert each of the numbers in square brackets into hexadecimal we get:

[0b] [96] [00] [04]

So our 6to4 address now becomes:

[2002]:[0b96]:[0004]:[Subnet ID]:[Host Address]

To make things a little easier, you can also use Excel to generate the hexadecimal version of the public IPv4 address using the following formula:

=DEC2HEX(((VALUE(LEFT(A2, FIND(".", A2)-1)))*256^3)+((VALUE(MID(A2, FIND(".", A2)+1, FIND(".", A2, FIND(".", A2)+1)-FIND(".", A2)-1)))*256^2)+((VALUE(MID(A2, FIND(".", A2, FIND(".", A2)+1)+1, FIND(".", A2, FIND(".", A2, FIND(".", A2)+1)+1)-FIND(".", A2, FIND(".", A2)+1)-1)))*256)+(VALUE(RIGHT(A2, LEN(A2)-FIND(".", A1, FIND(".", A2, FIND(".", A2)+1)+1)))),8)

where A2 is the cell containing the IPv4 address in a standard A.B.C.D format. This can be seen in Excel below:


You can also use the online hex subnet calculator provided here, or download the excellent offline Bitcricket IP Calculator from here or even use Windows calculator as discussed here.

Therefore, we now have the first 48 bits (16bit 6to4 Prefix+32bit IPv4 Address) of our 128 bit IPv6 address and now need to decide how we choose, or generate, the remaining 80 bits.

In general, we have two options:

  • Manual address configuration
  • Automatic address configuration

These are discussed below.

Manual Address Configuration

Although it is not ideal for scalability reasons, it is possible to manually configure hosts with static IPv6 address using the above 6to4 format. However, IPv6 routers do need to be manually configured for IPv6 addresses and routing behaviour. Therefore, if you plan to utilise native IPv6 intranet addressing, UAG needs to be configured with a manual IPv6 address before you begin using the UAG DA wizard. It is also necessary for UAG to be configured with an IPv6 address to ensure the DA wizard provides the option to enter IPv6 prefix information for a native IPv6 environment, as opposed to automating the ISATAP deployment and bypassing the prefix configuration step. More information on this is provided here.

Given the above formatting, we need to decide on how to define the last 80 bits of the address; which equates to:

[Subnet ID]:[Host Address]

In theory, you can choose whatever you want; or you could use the following example approach to define IPv6 addresses using a logical, repeatable process. This allows for mapping between IPv4 and IPv6 addresses on the same host, which can be handy for manually defined addresses.

Microsoft seems to favour the use of 8000 for the subnet ID in most documented examples, so I see no reason to differ:

[Subnet ID] = [8000]

[Host Address] = [Host IPv4 Address in Hex]

So, for an internal host with an IP address of this becomes:


which in full (uncompressed form) becomes the following IPv6 address:


or more simply (including the use of double colon zero compression formatting) this becomes:


With the address defined, we can now configure the actual IPv6 properties of the Windows intranet host as follows:


Please Note: Based upon the examples I have seen, it is normally recommended to configure a single UAG server with a native IPv6 address of [2002]:[Public IPv4 Address in Hex]:[Subnet ID]::1 so in our example this address would become 2002:b96:4:8000::1

Automatic Address Configuration

An IPv6 host that is not a router can be automatically configured using one of the following two methods:

  • Method 1: Stateless address auto configuration with IPv6 router discovery
  • Method 2: Stateful address auto configuration with DHCPv6

With method 1 (stateless), the IPv6 host builds its IPv6 address based on the Router Advertisement sent by the IPv6 router attached to the same network segment that the IPv6 host is connected to. This method is often enabled by default.

With method 2 (stateful), an IPv6 host can receive subnet prefixes, host addresses and other configuration parameters via DHCP. Even if not specifically assigning IPv6 host addresses, a common use of DHCPv6 for Windows-based IPv6 hosts is to automatically configure the IPv6 addresses of DNS servers, which are not configured through the Router Advertisement (method 1).

Some great information on IPv6 automatic address configuration by Joseph Davies (The Cable Guy) can be found here and here.

Please Note: Before moving onto specific examples of UAG server configuration for address auto configuration, it should be understood that these examples assume that UAG has already been configured for DirectAccess and is configured with a static IPv6 address on the UAG internal interface. Details on the actual UAG DirectAccess setup will be provided in Part 3 of this series.

Configuring UAG for Method 1

Assuming you have a pretty simple network (like our test lab) it is possible to configure the IPv6 router element of the UAG server itself to provide the necessary router advertisements needed for method 1.

Please Note: I am currently unsure as to the Microsoft supportability of this configuration on a UAG server, but I have tested it in both lab and production environments to good effect.

So, router advertisements can be achieved using the following commands on the UAG server:

netsh interface ipv6 set interface “Internal Network” advertise=enabled

netsh interface ipv6 set interface “Internal Network” managedaddress=disabled

Advanced Note: The first command configures the UAG IPv6 router to send router advertisements needed for stateless address auto configuration. The second netsh command sets the ‘M’ flag to 0 (zero) as discussed here.

In theory, any IPv6 router can be configured this way, but as this article is related to UAG DA, we can use this for our example.

The last element we need to configure is the route entry on UAG to advertise the correct prefix for stateless IPv6 host addressing for ‘on-link’ hosts (off-subnet hosts will need additional consideration). This can be achieved using the following commands on the UAG server:

netsh interface ipv6 add route 2002:b96:4:8000::/64 “Internal Network” publish=yes

or if the route is already present:

netsh interface ipv6 set route 2002:b96:4:8000::/64 “Internal Network” publish=yes

where 2002:b96:4:8000::/64 represents the prefix to be used for stateless auto configuration addresses.

This will essentially provide the first 64bits of the IPv6 host address to match the chosen IPv6 prefix. The remaining 64 bits will then be defined automatically.

So, with the above configuration applied, all IPv6 capable hosts (with auto configuration enabled) should begin receiving automatic addressing with the following format:

2002:b96:4:8000::[Randomly Generated 64 bit Hex Value]

for example, like this:


Please Note: I cannot find any specific guidance on defining 6to4 based IPv6 addresses for Domain Controllers and DNS Servers, but it would seem sensible to define these server roles with manually defined static IPv6 addresses. Alternatively, they could be assigned using DHCPv6, but leased to a reoccurring (pseudo-static) address every time with the use of DHCPv6 reservations.

Configuring UAG for Method 2

An IPv6 host performs stateless address auto configuration automatically. However, if you prefer to assign IPv6 host addresses using DHCP (method 2) you can use the following commands (instead of the above) on the UAG server:

netsh interface ipv6 set interface “Internal Network” advertise=enabled

netsh interface ipv6 set interface “Internal Network” managedaddress=enabled

netsh interface ipv6 set interface “Internal Network” otherstateful=enabled

Advanced Note: The first command configures the UAG IPv6 router to send router advertisements needed for stateless address auto configuration. The second netsh command sets the ‘M’ flag to 1 (one); and the third netsh command sets the ‘O’ flag to 1 (one) as discussed here.

Addresses will then be assigned as per the scope/options configuration of the DHCPv6 server. More information on DHCPv6 be found here.

Limitations of Using an IPv6 6to4 Addressing Format

The key downside to using a 6to4 based approach is that your intranet IPv6 addressing structure will be intrinsically linked to your public IPv4 address space. Consequently, if you change ISP and move to a new IPv4 address space, you will likely need to amend your internal IPv6 addressing accordingly. This is obviously far from ideal and this is why using Global unicast IPv6 addresses is the optimum and most future proof option when planning for a native IPv6 intranet. This assumes that your ISP supports providing an IPv6 prefix that is!

Please Note: The automatic ISATAP model deployed using Forefront UAG for IPv4-only networks is also based upon the use of a public IPv4 address dependencies. Therefore, it also suffers the same limitations defined above if the public IPv4 addresses are changed.

Finally, it should also be considered that if you begin using 6to4 or ISATAP based addressing initially, you will ultimately need to change everything once you can obtain a Global unicast IPv6 range from your ISP. That is the consequence of early adoption folks! ;)

Preparing for UAG DirectAccess with Native IPv6

Returning to our original need to define the correct IPv6 prefixes in the Prefix Configuration section of the UAG DA wizard and how to define appropriate intranet IPv6 addresses for our environment, we now have:

Intranet IPv6 Addresses:

2002:b96:4:8000::[Manual or Automatic 64 bit Hex Value]

where the definition of manual or automatic hex values is based on the chosen manual or automatic address assignment models (method 1 or method 2) discussed above.

UAG Internal Interface IPv6 Address:


Organisation Prefix:


NAT64/DNS64 prefix:


IP-HTTPS prefix:


So, hopefully this (now rather long and a bit complicated) article has helped provide some guidance on using UAG DirectAccess with native IPv6 addressing, as opposed to the more common ISATAP-based IPv6 connectivity approach. I can obviously see the benefits of using ISATAP, but I also like the approach of using this Dual Stack model for a slightly more elegant approach that moves the intranet a little close to the pure IPv6 intranet of the future.

In the next article we will begin looking at the actual UAG DirectAccess deployment, aptly titled The Path to DirectAccess - Part 3: Putting it All Together, which uses the IPv6 information derived/presented within this article.

See you soon!

[Thanks to Tom Shinder for Technical Review]

Monday, 24 May 2010

Certificate Revocation List (CRL) Information for Forefront TMG/UAG Administrators

The following wiki article has just been posted by the Windows PKI Team that contains some excellent information on CRLs when used with Forefront TMG and Forefront UAG related scenarios:

  • SSTP (which relates to both TMG and UAG)
  • IPSec (which relates to TMG)
  • UAG Reverse Proxy
  • UAG DirectAccess


Wednesday, 19 May 2010

Workgroup Deployment with Forefront TMG Enterprise Edition – Part 3: Enabling Network Load Balancing (NLB)

With the standalone array created, as discussed in Part 2, we can now provide high availability by using the NLB feature of Forefront TMG Enterprise Edition. In addition, NLB will also provide load balancing and allows for array members to operate in an Active/Active workload. More information on Forefront TMG Integrated NLB can be found here.

At a high-level, configuration of integrated NLB includes the following steps:

  • Prepare the environment for NLB
  • Enable Integrated NLB
  • Configure Forefront TMG Firewall Policy for NLB Manager (Optional) 
Please Note: Although this series is based upon the use of a workgroup deployment, the preparation and configuration of integrated NLB is exactly the same for a domain joined TMG scenario.

Prepare the Environment for NLB

Before enabling integrated NLB in TMG, you need to consider the the potential implications of NLB to the existing networking environment and choose the most appropriate NLB operating mode. An overview of NLB considerations for ISA Server 2006 Enterprise Edition is provided in one of my previous blog posts here which contains a lot of information that is still relevant for Windows Server 2008 and Forefront TMG.

If you are running Forefront TMG on a virtualisation platform, like Hyper-V or VMware ESX, there are also additional considerations as discussed next:

If you are using Hyper-V RTM as your virtualisation platform, you will need to enable Static MAC address entries on each virtual machine as discussed here. This will need to be completed for each virtual NIC that will be NLB enabled.

If you are using Hyper-V R2 as your virtualisation platform, you will need to configure a new feature in Hyper-V called Enable Spoofing of MAC addresses on each virtual machine. This will need to be completed for each virtual NIC that will be NLB enabled. This option was first added in Hyper-V R2 as discussed here and an example is provided below for completeness:

First for TMG03:





Next for TMG04:





If you are using VMware ESX as your virtualisation platform, you will need to apply the relevant VMware guidance as discussed here.

Assuming you have the environment ready for NLB, we can now finally enable integrated NLB for Forefront TMG!

Enable Integrated NLB

With all preparations complete, we can now enable integrated NLB for Forefront TMG Enterprise Edition.

For TMG03 only:





Important!: A recent TMG update was released to addresses an NLB issue as discussed here and summarised as “In an array-based TMG 2010 deployment with Integrated NLB enabled, traffic may not reach its destination”. It is therefore strongly recommended to install this update on all NLB enabled Forefront TMG servers. The update can also be downloaded from here.

Configure TMG Firewall Policy for NLB Manager (Optional)

Many people who have used NLB before will be used to using the Network Load Balancing Manager tool. However, when running this on TMG clusters you may notice that the tool is unable to connect to remote cluster nodes/hosts. This is caused by TMG blocking NLB Manager communications between cluster hosts. The default system policies included with TMG allow RPC communication between hosts, but the NLB Manager tool also uses DCOM calls as discussed here which are blocked by the Default Deny rule included with TMG.

When running TMG, it is not actually necessary to use NLB Manager as similar functionality is already provided within the TMG Management Console; hence why I have marked this step as optional.

However, for those who do want to use NLB Manager this can be achieved by adding a custom access rule which permits the necessary DCOM communications between NLB cluster nodes (array members). An example is provided below.

For TMG03 Only:





So there we have it, you should now have a fault tolerant, two-node standalone array which can be deployed to an environment without Active Directory. As discussed throughout the articles in this series, many of the elements discussed (NLB in particular) are also relevant to a domain joined TMG deployments, and can be used as standalone configuration guides for this purpose.

Finally, for those that have followed the entire series, maybe now you can see why I still choose to implement a dedicated Intra-Array Network as this makes the entire configuration easier to manage, more logical, performance optimised and ultimately more secure; hopefully you agree ;)

Hope this helps…

Tuesday, 18 May 2010

Workgroup Deployment with Forefront TMG Enterprise Edition – Part 2: Creating the Standalone Array

Now that we have prepared the environment for workgroup deployment, as discussed in Part 1 of this series, we can now create the standalone array.

This will involve the following steps:

  • Create and configure an intra-array network
  • Update the Remote Management Computers computer set
  • Edit the HOSTS file on each Forefront TMG server
  • Assign server certificate to the Array Manager
  • Join the Forefront TMG server to the standalone array

Create the Intra-Array Network

Where possible, I always use dedicated Intra-Array networks in my Enterprise Edition designs. Many people think this approach is no longer necessary, but in fact, it is still very much recommend by Microsoft as discussed here.

In the event that you do wish to create an intra-array network, you will need a dedicated network interface card (NIC) per array member to facilitate this. Assuming this is the case, as per our example lab environment, we need to configure this new network within the Forefront TMG console.

For TMG03 only:

Update the Remote Management Computers Computer Set

In order to successfully join the array when using an intra-array network, it is necessary to add the intra-array IP address of the joining server to the Remote Management Computers computer set on TMG03.

For TMG03 only:

Edit HOSTS Files

To ensure that the intra-array IP addresses are used for all communications between array members and ensure correct connectivity, it is necessary to edit the HOSTS file on each array member.

First for TMG03:


Next for TMG04:


Assign Server Certificate to Array Manager

In addition to copying the relevant server and root CA certificates to the local machine certificate store on TMG03 as covered in Part 1, we also need to use the Install Server Certificate task from the TMG Management Console to bind the certificate fully.

For TMG03 only:

Join the Standalone Array

So, we should now have everything in place to join TMG04 to the standalone array hosted by TMG03.

For TMG04 only:

For next time…

With the standalone array created, we now have a single point of administration, configuration storage and system monitoring. However, in order to provide a high availability solution, we need to add Network Load Balancing (NLB) in the form of Integrated NLB to the appropriate array networks.

Please Note: If you want to download all walkthroughs provided above in a single file you can use the Download as .zip link from here. However, be aware that this is a 12MB download!

See you next time…

Monday, 17 May 2010

Workgroup Deployment with Forefront TMG Enterprise Edition – Part 1: Preparing the Environment

Although the use of domain joined Forefront TMG servers is my preferred deployment model, I was recently involved in a Workgroup Deployment. As this is a supported deployment method, I thought it might be useful to document some of the specifics of installing and configuring in a workgroup environment, specifically when using Enterprise Edition with a standalone array.

When using a workgroup deployment, it is likely that infrastructure services are limited and an Enterprise Management Server (EMS) will not be present. Therefore a standalone array, as opposed to an EMS-managed array, will be required to provide an array of Forefront TMG servers. Therefore for the purposes of this article (and just because I think it is interesting) the example provided includes setup of a standalone array to provide a high availability Forefront TMG solution.

To improve the quality of information provided and also to reduce the amount of time it takes to produce these blog articles, I am trying out a new technology in this blog post. This technology is called the Windows Problem Steps Recorder and was originally written as a support tool. However, it also provides a really nice way of capturing a complete walkthrough process in a relatively accurate and fast way. PLEASE provide feedback on this new method of providing walkthrough information – does it work for you? I appreciate the MHT file download size is quite large, but it does allow for offline use which is quite a nice bonus!

Anyhow, back to the article. In order to prepare the environment for workgroup deployment we need to consider the following preparatory steps:

  • Configure each Forefront TMG server with a fully qualified domain name (FQDN)
  • Create user accounts
  • Import server certificates
  • Import root CA certificates

Lab Environment Overview

The example lab environment I am using consists of the following Forefront TMG Servers:

  • TMG03
  • TMG04

Both servers have been configured with three network interfaces (more on that later) and are running Forefront TMG Enterprise Edition on Windows Server 2008 R2 operating systems. The servers are actually hosted on a Windows Server 2008 R2 Hyper-V parent, not that this makes any difference to the examples.

An overview of the Forefront TMG related lab environment is shown below:


Configure FQDNs

As the Forefront TMG servers are not domain joined, they are unlikely to be configured with a DNS suffix. Hence they will have a simple hostname as opposed to a fully qualified domain name (FQDN). So, the first step is to configure each server with an appropriate DNS suffix to define the FQDN.

First for TMG03:

Next for TMG04:

Create User Accounts

The next step involves creating mirror user accounts on each Forefront TMG server.

First for TMG03:

Next for TMG04:

Import Server Certificates

Firstly we import a unique Workgroup Server Certificate into TMG03. In my lab, this certificate was created using an internal Windows CA using the Web Server certificate template. An overview of this process is provided here. However, any CA than can create a valid certificate with a Server Authentication ( key usage type (sometimes call an OID) should be fine.

For TMG03 only:

Import CA Server Certificates

To ensure that the imported server certificate is trusted by both TMG03 and TMG04, we need import the CA server certificate into the Trusted Roots Certificate Authority certificates store on both servers. For our example lab environment, this is called MSEDGE Root CA.

First for TMG03:

Next for TMG04:

For next time…

With the environment prepared, we can now think about creating the standalone array and joining workgroup array members.

Please Note: If you want to download all walkthroughs provided above in a single file you can use the Download as .zip link from here. However, be aware that this is a 14MB download!

See you next time…

Thursday, 6 May 2010

What Version of Forefront UAG Am I Running?

Now that Forefront UAG Update 1 has been released, I thought it might be useful to show the relative version numbers for both versions. By selecting Help | About from the Forefront UAG Management Console you should see the following:

For Forefront UAG RTM you should see 4.0.1101.0:


For Forefront UAG Update 1 you should see 4.0.1152.100:


Alternatively you can select Control Panel | Programs | Programs and Features and you should see the appropriate version number as shown below:


If Forefront UAG Update 1 has been installed, by selecting View installed updates you should see the specific reference to Update 1 and again version 4.0.1152.100 as shown below:


Please Note: These version numbers are relevant to the software version of Forefront UAG and may differ for appliance versions.

Hope this helps!