DirectAccess and NAT

One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.

Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.

Windows Server 2012 DirectAccess Network Topology

Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.

So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.

Leave a comment

20 Comments

  1. Dejan

     /  March 19, 2013

    What about being on “edge” but with two NICs teamed? Something like (with single network adapter) but without NAT.

    We have public addresses on most of our computers but I would hate to use four NICs just to get failover, just because W2012 makes a difference between “outside” and “inside” of the organization.

    Reply
    • An edge deployment would, out of necessity, require two network adapters. You can still enable NIC teaming on the external network interfaces for redundancy, of course. It would still only require a single public IPv4 address assigned to the teamed virtual NIC.

      Reply
  2. Gerrie

     /  March 25, 2013

    Great articles about DirectAccess!!!
    We are in the middle of a pilot ourselves, and were wondering what you consider as a large deployment? More than 10 simultaneous connections, or more than 100, or even greater maybe?

    So far we didn’t encounter any problems with CPU or network, but we only have had max 4 simultaneous connections. We expect this for our organization to maximize at 30 external users at the same time.

    Reply
    • I don’t expect you’ll see any performance issues with just a few users. Personally, I would consider an enterprise deployment supporting more than 1000 users, although you could encounter issues with less users depending on concurrency and traffic profiles too. If you’re diligent about monitoring your DirectAccess server’s performance you should be fine.

      Reply
  3. Anthony

     /  April 4, 2013

    How would web filtering work when using direct access. Are you accessing the internet from home or through work?

    Reply
    • In the default configuration, the client can access the Internet directly. Only traffic destined for the corporate network’s namespace is sent over the DirectAccess tunnels. You can override this behavior by enabling “force tunneling” which sends all client traffic over the DirectAccess tunnels, but this has some negative side effects including reduced client performance and increased resource demand on the DirectAccess servers.

      Reply
      • Anthony

         /  April 9, 2013

        If I do this and don’t like the performance results is it easy to just turn it off?

  4. Kevin

     /  May 16, 2013

    Richard, If I want to offload SSL (using a F5 LTM or equivalent device) what changes would I have to make on the Direct Access 2012 server (and how?). Looking forward to your talk at TechEd this year. Thanks!

    Reply
  5. abdelhadi anir

     /  September 29, 2013

    Hi,
    thank you for the article.

    I want to implement the DirectAccess and i have 2 questions:
    1) In the tutorials I saw, we used many servers (EGDE, DA, DC, CA…). Me I have one physical server, so can I depoly directaccessin a “monoserver” mode?
    2) I don’t have a public IP. Can I deploy DA without it. (Im testing, and I can’t buy a public IP before being sure that DA works).
    Thank you

    Reply
    • With Windows Server 2012/R2 you can deploy DirectAccess using a single server, but only for the remote access function. You can’t collocate the remote access services with infrastructure services like AD, DNS, CA, etc. My suggestion is to install Hyper-V server on your single physical machine and create two virtual machines – one serving as the DC/DNS/DHCP,CA and the other as the DirectAccess server.

      Reply
  6. Mr. Hicks, What about in the case of using a Web Application Proxy?
    I have the WAP in the DMZ handling all the 443 requests to my network.
    I added the URL http://DA.domainname.com / to the WAP but I am not having any luck with it connecting from the outside, internal it works properly.

    Reply
    • I’m not aware of anyone using WAP to publish DirectAccess, but in theory it would work as long as you aren’t terminating SSL on the WAP server or trying to authenticate the traffic somehow. There are much better alternatives to using WAP to protect DirectAccess, but again, I think it would work.

      Reply
  7. Currently I have the Web Application Proxy in my DMZ handling 443 requests to my network from the Internet. Would it be possible to use the WAP for Direct Access or would I need to assign one of my public IPs instead>

    Reply
  8. Rahim Kipingu

     /  June 21, 2017

    Greeting Mr. Hicks.
    I do have a question. Is it possible to use a different port other than 443 for DirectAccess? I currently use port 443 for Exchange OWA and ActiveSync. I have NAT’ed 443 in my router to point to Exchange server. I am not sure whether it is possible to NAT the same port to two different servers (DirectAccess and Exchange servers).If it is possible, where do I change within DirectAccess settings?
    Regards.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: