I must confess, during the past couple of years I have highlighted the VPN-solution Direct Access (DA) from Microsoft as a killer application for IPv6. I still have hope for this solution, but as I now have had the chance to study the UAG/DA-solution more closely and in practical implementation, I must also highlight some issues for Microsoft to handle.

My conclusion is that using DA today brings difficulties when it comes to an organization that already has, or wants to, deploy native IPv6 internally.

In this post I won’t discuss any pros or cons regarding security issues and if DA is secure enough. This will only focus on implementing with IPv6. I do find DA to be great VPN solution that use IPv6 to automatically transport the client to the office, creating a high “I’m at the office feeling”, almost from wherever you are and have an Internet access. It is easy to use and the client doesn’t need to activate it. It uses the “Network Location Server” to see if you are trying to connect on the internal office network or not. If you’re not, it will activate the VPN.

The IPv6 transport can be a native IPv6, a tunnelled transport via 6to4 or Teredo and the last choice a iphttps (which is https over IPv4). An DA client can therefore often get a VPN-connection to the office since the famous https-port, 443, is most often open in the firewalls.

Microsoft DA can be installed as a feature in Windows 2008 R2 server or as a part of Microsoft Unified Access Gateway, UAG. UAG gives the possibility to use NAT64/DNS64 through which IPv4-only hosts can connect through IPv6. For more details regarding this, please read Microsoft’s document.

Ok, so far so good, but didn’t you mentioned some problems? I sure did, and here is what Microsoft needs to target:

1. If you install DA as a feature, the built-in firewall in Windows Server 2008 R2 have support for IPv6, but you can only build in- or outbound rules. You can’t get any IPv6 traffic to pass the server.
2. If you install UAG, the built in firewall disables and instead the Microsoft Forefront Trust Management Gateway installs. But the TMG however doesn’t support IPv6 at all.?(Here there are some Powershell-script that can set some IPv6-firewall rules. But come on Microsoft, it is 2011 today, not 1991.)
3. Many, many organizations use other firewalls then TMG to protect their infrastructure. The DA/UAG design is mainly for organizations who have a “Microsoft only design”

Below there are two pictures on how to deploy a DA/UAG server. The information is taken from Microsofts “UAG DirectAccess Server Deployment Scenarios”, which in turn can be found on this page:

The pictures explain more about the points 1 to 3 above.

UAG DA server in parallel with your existing firewalls

In this case you have to place your default IPv6 route to the UAG DA server and the Native IPv6 is broken.

UAG DA server placed between two firewalls

In this case the TMG/DA breaks the native IPv6 support since the TMG doesn’t support IPv6. Even if the TMG should support IPv6 there is in hand to point out that this means one more single point of failure in the Internet connection.

So how do we deploy native IPv6 with UAG/DA?

Of course there are other ways to do this but I have found a solution that works fine even if you already have native IPv6 in your organization. [Which by now you of course have done :) ].

DA/UAG demands two network interfaces, one external and one internal interface. The external interface must have two consecutive IPv4 PA/PI for Teredo and 6to4 connectivity, this goes even if you have native IPv6 already.

First: ?Disable Teredo and 6to4 Interface in the VPN-clients so only native IPv6 IPSEC and iphttps is enabled. I don’t recommend disabling native IPv6 on the client, perhaps this goes without saying but this is of course since we now are very close to the first RIR IPv4 depletion and native IPv6 therefore must be deployed in many places.

Second: ?Place the UAG/DA server like the two pictures below. On the first you can filter everything except IPv4 https and you also have only one firewall to manage with rules. In the last example you have two firewalls to manage, which brings a different discussion of pros and cons.

Most important with the above is that none of the setups disturbs the other native IPv6 in the organization.

Place the UAG/DA on two ‘DMZ’

In this solution you have a total control of the traffic to/from the UAG/DA server and only one firewall to manage the in- and outbound traffic. There are some IPv4 and IPv6 routing to take care of and it also demands a DMZ. The DMZ needs to have a PA/PI IPv4 space and, as everyone knows by now, the IPv4 space is soon to be totally depleted. The internal interface in the UAG/DA can also be placed in a L3 IPv6/IPv4 switch where the iphttps-IPv6-prefix is routed. However, You can’t then control the IPv6-traffic to the internal network.

One DMZ for the UAG/DMZ

In this case a DMZ with PA/PI IPv4 space is not needed but you have to manage two firewalls, again with the pros and cons of that.

Conclusion

I think Microsoft DA/UAG is a good VPN solution. But Microsoft need to make some changes urgently since the IPv4 is soon to be depleted and to the fact that the boom in IPv6 deployment is already here. I would strongly recommend and welcome a solution from Microsoft where a new native IPv6-interface, like iphttps but with the use of NAT66/DNS66 to solve the “native IPv6 and other firewalls than Microsoft-problem”. Before that is realized I recommend to use Microsoft UAG/DA with caution according to above, so you don’t break the real Ipv6-world.