Original

That's a good question. But before we go there, we have to think about connectivity between the DirectAccess server and the DirectAccess client. The DirectAccess client always communicates with the DirectAccess server using IPv6. There is no IPv4 application traffic moving between the DirectAccess client and DirectAccess server. This means that the client side applications running on the DirectAccess client must be IPv6 aware.

On the server side it doesn't matter - you can run IPv4 only server applications on an IPv6 capable operating system, or you can run IPv6 aware server applications on an IPv4 only operating system. IPv4 isn't an issue when using UAG DirectAccess, because we have the DNS64/NAT64 feature to support IPv4 communications between the DirectAccess server and the destination server on the intranet.

Options for Client-side Application that are not IPv6 Aware

This means that if your client side applications don't support IPv6, you're going to have to think about a solution. Some things to consider include:

• Check with the vendor to see if they have an updated client side application that is IPv6 aware
• Check with the vendor to see if the application can be made IPv6 aware by editing a configuration file or setting a Registry entry. In some cases the client side applications might appear to not work with DirectAccess, but if you make a configuration change, they suddenly start working
• If the vendor doesn't have an IPv6 capable application and there are no client side tweaks that you can use to make it IPv6 capable, investigate alternate vendors of the same solution and see if they have products that are IPv6 aware. Let your current vendor know that you are thinking about switching vendors due to lack of IPv6 compliance - this might provide the vendor motivation to update the client, in which case you won't have to incur the costs involved with deploying a new application
• If there is no client side fix that works for you, you might then check to see if there is some external Internet facing proxy or relay you can use for your application. When you use an external proxy or relay, the connections to the service will not be through the DirectAccess tunnels. Instead, they will go out through the Internet to the application gateway you configure them to use
• If there is no proxy, relay or application gateway option available to you, then you can use an SSTP VPN connection to connect to the UAG server. You can co-locate the DirectAccess and SSTP roles, so if the user needs to use an application that isn't IPv6 aware, the user can start an SSTP connection, complete the work that needs to be done with that application, and then close the SSTP connection if they want, or wait for the SSTP connection to time out after they're done with the application that required the network level VPN link. When SSTP starts, the DirectAccess configuration will turn itself off, and when the SSTP drops, the DirectAccess configuration will be automatically enabled again. Not an ideal solution, but hopefully this scenario will be rare as application vendors realize that they're in the 21st century.
• If your clients don't support SSTP (SSTP is supported only with Vista SP1 and above), then you can fall back to publishing applications using the SSL VPN components of the UAG server. While not as transparent as the DirectAccess solution, and limited to only web applications (with some support for file share access over the SSL VPN and port/socket forwarding for other client/server applications), it does provide access for antiquated Windows operating systems and non-Windows operating system through the UAG server, as well as modern Windows operating systems that are not domain joined, and thus not candidates for DirectAccess.
• If you want clients to connect over PPTP or L2TP/IPsec network level VPNs, then UAG will not be the VPN server of choice. In this scenario, your best remote access VPN solution is the Forefront Threat Management Gateway.

The Force Tunneling Issue

There is one important issue that you should be aware of, and this relates to those organizations that plan on using Force Tunneling. By default, UAG DirectAccess (as well as the Windows DirectAccess) enables a form of split tunneling, by virtue of the fact that requests for non-intranet resources are sent directly to the Internet server, and not tunneled through the DirectAccess links to the DirectAccess server and out through the corporate firewall or proxy.

Some IT groups are hesitant to support split tunneling based on assumptions made during the 1990s regarding VPN client behavior and the nature and capabilities of malware at that time in history. The networking and threat management landscape is very different now and issues that we're important in a split tunneling configuration 15 years ago are no longer extant. However, not all IT groups have caught up with this or have their hands forced by other decision makers, and therefore may choose to disable the split tunneling configuration by enabling Force Tunneling.

If you do enable Force Tunneling, be aware that all communications will be sent through the DA tunnels. This means you will not have the option to use a Internet gateway for your non-IPv6 compliant client applications and you will not be able to fall back to using an SSTP VPN, PPTP VPN, L2TP/IPsec VPN, or even an SSL VPN.

The decision to use Force Tunneling should be made with the knowledge that all your client side applications all must be IPv6 aware - as they will not be able to use any fall back mechanism that requires them to connect to the Internet.

HTH,

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder