DirectAccess Network Deployment Scenarios

When DirectAccess was first introduced in Windows Server 2008 R2, and continuing with Forefront Unified Access Gateway (UAG) 2010 DirectAccess, there was a hard requirement for the DirectAccess server to be configured with two network interfaces; one internal, and one external. The external network interface also required two consecutive public IPv4 addresses and did not support placement behind a Network Address Translation (NAT) device.

Connecting a domain-joined Windows server directly to the Internet was often a tough sell, but in the case of Forefront UAG 2010 DirectAccess, essential edge protection was provided by the venerable Forefront Threat Management Gateway (TMG) 2010, which is a very robust, enterprise-class firewall that was included along with Forefront UAG. Things changed a bit beginning with Windows Server 2012, as the DirectAccess role is now supported behind NAT with a single, private IPv4 address and can be configured with a single network interface. However, in the absence of Forefront TMG 2010, the DirectAccess server is left with the Windows Firewall with Advanced Security (WFAS) as its only protection from the Internet.

For a variety of reasons, I personally recommend that the DirectAccess server be deployed behind an edge firewall. This will provide the highest level of protection for the DirectAccess server, in addition to ensuring the most available DirectAccess connectivity, as the majority of firewalls allowing access to the public Internet will have TCP port 443 (HTTPS) open. You can use an existing Forefront TMG 2010 firewall to protect the DirectAccess server (be sure to use a server publishing rule, not a web publishing rule!) or another firewall like Cisco, Checkpoint, Juniper, Fortinet, etc. by creating an access and NAT rule to allow inbound TCP port 443 to the DirectAccess server. As the only IPv6 transition protocol that can be leveraged is IP-HTTPS when the DirectAccess server is behind a NAT device, be sure to disable unused transition protocols as outlined here.

When configured behind a NAT device, you can configure the DirectAccess server with either a single network interface or two. I prefer the two network interface deployment model, with the external interface residing in a perimeter network behind the edge firewall or NAT device and the internal network interface residing in the corporate LAN. I have had a number of conversations with security administrators and network architects who have expressed a desire to place the DirectAccess server between two firewalls (firewall sandwich) in order to explicitly control access from the DirectAccess server to the internal corporate network. While at first this may sound like a sensible solution, it is often quite problematic and, in my opinion, does little to improve the overall security of the solution. Restricting network access from the DirectAccess server to the internal LAN requires so many ports to be opened on the inside firewall that the benefit of having the firewall is greatly diminished. Placing the DirectAccess server’s internal network interface on the LAN unrestricted is the best configuration in terms of supportability and provides the best user experience.

If you have a specific use case which requires that your DirectAccess clients not have access to the entire corporate network, consider using the selected-server access model by extending IPsec authentication to the servers you wish to grant access to. Additionally you can restrict access to only these specific servers by select the option to Allow access only to servers included in the security groups. Be advised that extending authentication to selected application servers requires that IPv6 be deployed in the target application servers.

As you can see, Windows Server 2012 DirectAccess network placement is much more flexible than in previous releases. If you trust the native Windows firewall for edge protection, you can certainly deploy the appliance directly on the public Internet. For additional protection and peace of mind, I suggest deploying it behind an existing edge security device. Ultimately the choice is up to you as to how you wish to deploy DirectAccess in your environment, and both configurations are fully supported.