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

23 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
    • As long as you aren’t terminating SSL or performing authentication for DirectAccess connections on WAP I think it should work. 🙂

      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
  9. Shane

     /  August 3, 2018

    Public IP change question. We are setup to use a public DNS name behind an edge device in our current DA setup. We need to change our public IP. When we do this and update the external DNS with the new IP will our clients still connect ? Not sure if old IP information and ranges get setup in the GPO when going through the setup? Any information would be greatly appreciated. Thanks!

    Reply
    • Shouldn’t be a problem. 🙂 Just change the IP address and then update DNS and your clients will connect as soon as they resolve the DNS name to the correct IP address. I’d suggest reducing the TTL on the DNS record as much as possible prior to making the change just to ensure clients can reconnect quickly after you make the change.

      Reply
  10. Shane

     /  August 9, 2018

    Thank you for the information!

    Reply

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading