Choosing a Forefront UAG DirectAccess and VPN coexistence design
Published: January 11, 2010
Updated: February 1, 2010
Applies To: Unified Access Gateway
This topic describes how Forefront UAG DirectAccess can coexist with a remote access virtual private network (VPN) solution.
Because the migration of a remote access VPN solution to Forefront UAG DirectAccess solution will take time, both of these solutions can be used simultaneously to provide remote access connectivity to intranet resources for different sets of clients. For example, intranet client computers running Windows Vista or Windows XP can continue to use your remote access VPN solution, and computers running Windows 7 can begin to use Forefront UAG DirectAccess.
If a computer running Windows 7 is both a DirectAccess client and a remote access VPN client, ensure that the remote access VPN server is not blocking access to the network location server on the intranet, even when the network access of VPN clients is restricted. When the remote access VPN connection is active, the DirectAccess client should successfully detect that it is located on the intranet, regardless of its network access status (restricted or full access). Similarly, firewall or connection security rules of the DirectAccess client should not block access to locations needed to remediate the system health of the computer, when its access is restricted as a remote access VPN client.
The same computer, acting as a Forefront UAG DirectAccess server and a remote access VPN server with routing and remote access, is only a supported configuration when used with Forefront UAG. For more information, see Overview of Forefront UAG DirectAccess.
Forefront UAG DirectAccess and third-party VPN clients
When deploying Forefront UAG DirectAccess with third-party VPN clients, it may be necessary to set the following registry values to enable the seamless coexistence of the two remote access solutions:
Some third-party VPN clients do not create connections in the Network Connections folder. This can cause DirectAccess to determine it has no intranet connectivity when the VPN connection is established and connectivity to the intranet exists. This occurs when third-party VPN clients register their interfaces by defining them as Network Device Interface Specification (NDIS) ENDPOINT types. You can enable coexistence with these types of VPN clients by setting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NlaSvc\Parameters\ShowDomainEndpointInterfaces (REG_DWORD) registry value to 1 on DirectAccess clients.
Some third-party VPN clients use a split-tunneling configuration, which allows the VPN client computer to access the Internet directly, without the need to send the traffic through the VPN connection to the intranet. Split-tunnel configurations typically leave the Default Gateway setting on the VPN client as either not configured or as all zeros (0.0.0.0), which you can confirm by establishing a successful VPN connection to your intranet and using the Ipconfig.exe tool at command prompt to view the resulting configuration. If the VPN connection lists its Default Gateway as either empty or all zeros (0.0.0.0), your VPN client fits this case. By default, the DirectAccess client does not identify these types of configurations. To configure DirectAccess clients to detect these types of VPN client configurations and coexist with them, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NlaSvc\Parameters\Internet\ EnableNoGatewayLocationDetection (REG_DWORD) registry value to 1.