Network Interface Configuration for Multihomed Windows Server 2012 DirectAccess Servers

When preparing a Windows Server 2012 DirectAccess server with two network interfaces, proper configuration of the network interfaces is vital to the operation and security of the remote access solution, especially in edge-facing scenarios. Preparing a server with two network interfaces might seem trivial, but there are some important and often overlooked settings that may lead to trouble. In this post I’d like to outline the proper network interface configuration for a Windows Server 2012 DirectAccess server in an edge-facing deployment scenario. It is important to note that you should configure your network interfaces prior to installing and configuring DirectAccess.

The first step is to rename the network interfaces with intuitive names that identify their role. Typically I use Internal and External. This will make DirectAccess configuration much easier, as you will see when you are configuring DirectAccess using the deployment wizards. To rename the network interfaces, open the Networking and Sharing Center from the Control Panel and choose the option to Change adapter settings. Optionally you can simply highlight the network interface you wish to rename and hit F2. Assign new names to the network interfaces as appropriate.

direct_access_multihome_01

Next, right-click the Internal network interface and choose Properties. Enter an IPv4 address, subnet mask, and DNS servers as required. Notice that I have not entered a default gateway here. This is absolutely critical and one of the most common mistakes made when configuring a multihomed DirectAccess server. On a server with multilple network interfaces there can be only one default gateway, and the gateway must reside on the External network interface.

direct_access_multihome_02

In the absence of a default gateway on the Internal network interface, static routes will be required to reach any remote internal subnets. To add a static route, open an elevated PowerShell command prompt and add any necessary routes using the following syntax:

New-NetRoute -InterfaceAlias <Interface_Name> -DestinationPrefix <SubnetID/Mask> -NextHop <Gateway_Address>

For example, my lab network has a remote subnet of 172.16.2.0/24 that is reachable through a router interface of 172.16.1.254.

New-NetRoute -InterfaceAlias Internal -DestinationPrefix 172.16.2.0/24 -NextHop 172.16.1.254

It’s also a good idea to unbind any protocols that are not required. For example, in my implementation I will not be leveraging QoS or NIC teaming, nor will I require the Link-Layer Topology Discovery services so I’ve unchecked those boxes accordingly.

direct_access_multihome_03

Perform this same exercise for the External network interface. Enter an IPv4 address and subnet mask, and this time be sure to include the default gateway for the External network. Notice that I have not entered any DNS servers here. Resist the urge to enter the DNS servers provided by your ISP. They are not required here.

direct_access_multihome_04

Since this DirectAccess server will be edge-facing and connected directly to the public Internet, it is a good idea to unbind all protocols from the network interface with the exception of IPv4 and IPv6.

direct_access_multihome_05

In addition, uncheck the option to Enable LMHOSTS lookup and also chooseDisable NetBIOS over TCP/IP.

direct_access_multihome_08

One last change that needs to be made, and perhaps the most critical and often overlooked setting, is the network interface binding order. This change can be made by pressing the Alt key on the keyboard to display the drop-down menu and choosing Advanced Settings.

Important Note:  Beginning with Windows Server 2016, making changes to the network interface binding order is no longer required, and this option has been removed from the UI.

direct_access_multihome_06

Make certain that the Internal network interface is listed first in the list of connections.

direct_access_multihome_07

So that’s it! You can now proceed with installing and configuring DirectAccess in full confidence that your network interfaces are configured properly!

Additional Resources

Always On VPN and the Future of DirectAccess

5 Things DirectAccess Administrators Should Know about Always On VPN

3 Important Advantages of Always On VPN over DirectAccess

Always On VPN Hands-On Training Classes

The Drawbacks of Supporting Windows 7 Clients with Windows Server 2012 DirectAccess

Windows Server 2012 DirectAccess includes many new features to enhance scalability and performance. To take full advantage of many of these capabilities you must use Windows 8 Enterprise edition for your DirectAccess clients. Windows 7 Enterprise and Ultimate clients are supported, but there are a few important features that can’t be leveraged. Here are some examples:

IP-HTTPS Improvements – Windows Server 2012 supports NULL encryption for the IP-HTTPS IPv6 transition protocol. This eliminates the performance penalty and negative scalability caused by needlessly redundant encryption of DirectAccess client communication (IPsec encrypted traffic encrypted again with SSL/TLS). Windows 8 clients only request these NULL encryption cipher suites when establishing DirectAccess connectivity. However, Windows 7 clients do not support NULL encryption and will instead request an encrypted cipher suite when performing SSL/TLS negotiations.

Automatic Site Selection for Multi-Site – With Windows Server 2012 the administrator can configure multiple DirectAccess gateways to provide geographic redundancy for DirectAccess clients. Windows 8 clients are configured to intelligently select the nearest entry point and automatically reconnect to another gateway if the connection to the originally selected entry point fails. In contrast, Windows 7 clients can be configured for only a single entry point. The Windows 7 client is unaware of any other entry points and if the original connection becomes unavailable for any reason it will not have corporate network access until that entry point is back online.

Public Key Infrastructure (PKI) – The removal of the requirement to have an internal PKI to support DirectAccess clients is a popular feature for many organizations wanting to deploy DirectAccess (I don’t necessarily agree with this, but that’s the subject of another post!). Although Windows Server 2012 DirectAccess can be configured to use self-signed certificates, this deployment model is only supported for Windows 8 clients. If you plan to provide support for Windows 7 clients you will need a working internal PKI.

DirectAccess Connectivity Assistant – The Windows 8 client includes native functionality to indicate the status of DirectAccess connectivity and also includes a facility with which to quickly gather detailed log data for troubleshooting. Windows 8 clients can also establish DirectAccess connectivity when they are located behind an authenticating web proxy. For Windows 7 clients, the DirectAccess Connectivity Assistant (DCA) provides some of this functionality, but it is an optional component that must be deployed separately. Even with the DCA installed, Windows 7 clients cannot establish DirectAccess connections when a web proxy server requires authentication.

Although Windows 7 Enterprise and Ultimate editions are supported for DirectAccess when connecting to a Windows Server 2012 DirectAccess server, Windows 8 Enterprise clients should be deployed whenever possible to ensure the best and most complete experience.

Hotfix for Windows 7 DirectAccess Clients

This month Microsoft released an important hotfix to address a DirectAccess connectivity issue for Windows 7 clients connecting to a Windows Server 2012 DirectAccess Server. The hotfix specifically resolves an issue where Windows 7 clients face a very long delay reestablishing a DirectAccess session using the IP-HTTPS IPv6 transition protocol after recently disconnecting from a VPN session. In this scenario, Windows 7 DirectAccess clients may take as long as 15 minutes to automatically reestablish a DirectAccess session using IP-HTTPS. During this time the IP-HTTPS adapter state is displayed as disconnected. Refer to Microsoft KB 2796313 more information and to download the hotfix.