- Data Center
- Cloud
- Storage
- Big Data
- Security
- Partners
- Support
- Company
UAG & DirectAccess: Some of my applications don’t work on DirectAccess, what should I do?
This is a very common situation which people might face when deploying Microsoft DirectAccess technology. Before going into how to work around this we need to know why the applications which work in internal network would fail to work on DirectAccess connectivity.
Let’s go through few types of applications and the reasons why they might fail to connect
Client/Server Applications
Some client applications are written to connect to their servers with a hardcoded IPv4 addresses either at the time of running the client setup or while configuring after the initial setup is done. These applications will work internally without an issue because they can easily work on IPv4 and can locate the server. As we all know that Microsoft DirectAccess is build around IPv6 and not IPv4, due to this reason any client side application which tries to communicate with its server side application over IPv4 will fail to connect.
Ok, so we have seen why applications with hardcoded IPv4 addresses will fail, but what if the applications are not configured to use IPv4 addresses but instead use FQDN of the server? Why do they fail to connect? It’s a valid question and there are applications which are configured to connect to FQDN will also fail. This is due to applications weakness to understand the IPv6 address returned during the name resolution process. In DirectAccess connectivity when a DirectAccess client tries to communicate to the server side application, it sends a Quad A (AAAA) DNS query to the DirectAccess Server and in return gets an IPv6 address. Now, the client side application was expecting an IPv4 address but instead received an IPv6 address. This will break the communication if the application does not know how to read that IP address.
Server Applications
In DirectAccess solution wherein internal networks are made to run on IPv6 without using the IPv4 to IPv6 conversion technologies provided by translation technologies such as Microsoft UAG or something similar, the applications might fail to connect if the application does not understand IPv6 traffic. Even if the operating system understands the IPv6 traffic, the application installed on that OS should also understand the IPv6 traffic to completely work with DirectAccess technology.
So far we have seen that what kind of applications might fail and why. Let’s now see what are the ways we can resolve these connectivity issues; I will be using the above mentioned application types to identify how to resolve the connectivity issues for each.
Client/Server Applications
The issues as described above for client/server applications can be resolved by using Microsoft Unified Access Gateway 2010. Microsoft UAG provides two main functions;
- SSL VPN solution with portal based access to the internal applications
- DirectAccess capability with NAT64 and DNS64 technologies
Microsoft UAG provides SSTP connections through its portal. The SSTP and DirectAccess within UAG can both be used at the same time but only one of them will stay connected to the internal network at any give time. For applications which are unable to connect or cannot understand IPv6, you may login to portal and then create a SSTP tunnel which is nothing but VPN over SSL. When SSTP is connected the DirectAccess connectivity is disconnected because that makes the client machine to resolve the Network Location Server’s address. This will allow your applications to connect to the internal network without going over IPv6. When you disconnect the SSTP, you will be connected to the DirectAccess connectivity again automatically.
However, the recommended method is to contact the application vender to see if they have an IPv6 compatible client side application. This would be a long term fix.
Server Applications
If you don’t have an immediate need to move your internal network to IPv6 and most of your applications are not compatible with IPv6 then the best solution again is to deploy Microsoft UAG 2010. It uses NAT64 technology to convert the IPv6 traffic to IPv4 and vice verse. Also, it uses DNS64 technology to convert the Quad A DNS query to Host A query. This gives you the ability to keep your internal network on IPv4 and still enjoy the complete access through Microsoft DirectAccess.
As you can see that Microsoft UAG provides a lot of benefits and when you buy Microsoft UAG as an appliance from nAppliance Networks Inc. its provides other features as well. Check the available features at http://www.nappliance.com/products/NetGateway-nUAG.asp
For pricing and professional services contact us at support [at] nappliance.com
Cheers,
Inderjeet
- Category:
- Tag:
- Working,
- VPN,
- UP1,
- Unified Gateway,
- Unified,
- Unable,
- UAG Server,
- UAG,
- TMG,
- SSTP,
- SharePoint,
- Published,
- publish,
- portal authentication,
- Portal,
- nUAG,
- not working,
- network,
- nAppliance,
- ISA Server,
- ISA,
- IP address,
- IAG Server,
- IAG,
- Gateway,
- event ID,
- event,
- Error,
- DirectAccess,
- connector,
- Citrix,
- authentication,
- Appliance,
- address,
- Access
Copyright © 2024 Iron Networks, Inc. All Rights Reserved.