Choose a DirectAccess and VPN Coexistence Design

Applies To: Windows 7, Windows Server 2008 R2

Because the migration of remote access virtual private network (VPN) solution to DirectAccess will take time, both of these solutions for remote access connectivity to intranet resources can be used simultaneously 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 DirectAccess.

If a computer running Windows 7 is both a DirectAccess client and a remote access VPN client, ensure the following:

• 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 VPN-based network access status (restricted or full access).

• 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 it has its access restricted as a remote access VPN client.

• The fully qualified domain name (FQDN) of the VPN server on the Internet either does not match the intranet namespace or there is a corresponding exemption rule for the FQDN in the Name Resolution Policy Table (NRPT).

The same computer acting as a DirectAccess server and a remote access VPN server with Routing and Remote Access is not a supported configuration, except when used with Microsoft Forefront Unified Access Gateway (UAG). For more information, see Overview of Forefront UAG (https://go.microsoft.com/fwlink/?LinkId=160322).

DirectAccess and third-party VPN clients

When deploying 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 condition 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 having 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) . You can confirm this behavior by establishing a successful VPN connection to your intranet and using the Ipconfig.exe tool at command prompt to display the Default Gateway setting for the VPN connection. 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.

For more information about third-party VPN clients that provide their own implementations of Internet Protocol security (IPsec), see Recommendations for Virtual Private Network Client Coexistence with the Internet Protocol Security Implementation in Microsoft Windows (https://go.microsoft.com/fwlink/?LinkId=163776).