UAG DirectAccess: What won’t work?

Author by Shannon Fritz

UPDATE: My guide for Configuring DirectAccess with UAG Service Pack 1 has been released! Read it here.

One of the most common questions I am asked about UAG DA is "What won't work over DirectAccess?" Thankfully the list seems fairly small and easily summarized: Old client side software that is not IPv6 aware.

Because DirectAccess uses an IPv6 tunnel to communicate with the UAG server, any software that needs to traverse that tunnel must be able to use IPv6. If it can only use IPv4, or if it is hard coded to use an IPv4 address (instead of a DNS name) it will not be able to use the tunnel and therefore will not work.

How big of a problem is this?

I have not found this to be a very common problem. Most places are using software that is capable of using IPv6 without the software vendors even knowing it. And many applications are being delivered by SaaS or otherwise through a web browser which is completely capable of using IPv6. As a general rule, if your program needs to talk to a server and it uses a DNS hostname to get there, you have a very high probability of it working. Also keep in mind that with UAG doing End-to-Edge encryption, support for IPv6 on the server side of things is not required at all thanks to DNS64 and NAT64. Only the client side has the IPv6 requirement.

What if my App wont work?

If a client application simply must run IPv4, then you are left with a few options.  Usually the most daunting way to "fix" the problem is to upgrade the application to a version that supports IPv6 (if it exists) or even more challenging would be to replacing the application all together with a different product.  If neither of those options appeals to you (and generally they don't) then the only option is to run the client app on the other side of the DirectAccess tunnel.   I find using the RemoteApp component of 2008 R2 Remote Desktop Services tends to be a good fit for most cases. Using RDS you can run the application on a server that resides inside your corpnet yet seamlessly present the user interface to the client as if it were running locally for them.  Plus you can deliver a RemoteApp straight over the DirectAccess tunnel or instead publish the app through an RDS Gateway.  You could also publish it through a UAG Portal or Trunk as well, something this guide has not touched on at all. Sometimes you may come across an application that simply won't fit into a DirectAccess or RemoteApp scenario.  In those cases you'll have to hope they offer some sort of external interface that you can stand up and let the DirectAccess clients function like any other client by reaching it over the IPv4 Internet directly.

Got any examples?

For one, the Microsoft OCS client Communicator 2007 R2 does not use IPv6.  Thankfully OCS is already designed  for use outside of the corpnet through an OCS Edge server.  In the case of DirectAccess clients, if you are using Split DNS where your internal domain name is also your public Internet domain name, you just need to make a few DNS exclusions and it will work as intended! The only application I have not been able to get working over DirectAccess is an ERP system that was privately developed by a client of mine.  Publishing it through RemoteApp would do the trick. What about you? Do you have any examples of software that you could not get to work over DirectAccess?  What did you do about it?
Next Step:
Index 1. IP Addressing the UAG Server 2. Unified Access Gateway Installation & Updates 3. Firewall and DNS Considerations 4. Certificates, Groups and Client Requirements 5. Configure other Prerequisites for UAG 6. Configuration Wizard: Clients 7. Configuration Wizard: DirectAccess Server 8. Network Location Server (NLS IIS site) 9. Configuration Wizard: Infrastructure Servers 10. Configuration Wizard: Application Servers 11. Generate and Activate Policies 12. DirectAccess Connectivity Assistant 13. What won’t work over DirectAccess
Author

Shannon Fritz

Infrastructure Architect & Server Team Lead