DirectAccess vs. VPN

Introduction

DirectAccess vs. VPNMany IT professionals mistakenly believe that DirectAccess is just another VPN solution. While there are some similarities between these technologies, both in terms of the underlying technology and function, there are some significant differences between the two. If you’re comparing DirectAccess to VPN, here are some essential points to consider.

VPN

Virtual Private Networking (VPN) has been around for ages. VPN is a mature, well understood technology that has been widely deployed, and today remains the de facto standard for providing secure remote access. VPN has broad client support, on both traditional computing platforms and mobile operating systems. VPNs today include support for modern protocols and integrate with numerous multifactor authentication platforms.

VPN Challenges

There are some serious drawbacks to implementing traditional client-based VPN. VPN connections are user initiated and therefore optional. It is up to the user to decide if and when they connect to the corporate network. Many VPNs require additional software to work, which must be deployed and maintained. Establishing connections is potentially problematic too, as some VPN protocols aren’t firewall friendly and don’t work in many locations.

DirectAccess vs. VPNFrom a security perspective, because anyone can attempt a connection to the VPN from any client, strong authentication becomes an essential requirement. Integrating multifactor authentication makes the implementation more complex and difficult to support. It often requires additional hardware, licensing, and support costs.

VPNs can be costly to implement and support. They typically require expensive proprietary hardware and dedicated management skill sets. Many VPN solutions also have additional licensing costs associated with them. Scaling a VPN solution requires additional investments in hardware devices, adding to the overall cost of the solution.

DirectAccess

DirectAccess is a relative newcomer to the world of secure remote access. First introduced with Windows Server 2008 R2, DirectAccess differs fundamentally from VPN by virtue of its seamless and transparent, always-on connection. DirectAccess connections are established by the machine, not the user. They are secure and authenticated, and are established automatically whenever the DirectAccess client has an active Internet connection. DirectAccess connections are also bidirectional, which is an important distinction. The ability to “manage out” to remote connected DirectAccess clients enables compelling new uses cases for IT administrators.

Addressing VPN Pain Points with DirectAccess

DirectAccess vs. VPNDirectAccess connections are inherently more secure than VPN. Unlike VPN, DirectAccess clients must be joined to the domain and, in most configurations, they must also have a certificate issued by the organization’s private, internal Public Key Infrastructure (PKI). This essentially serves as a type of multifactor authentication for the connecting device, resulting in a much higher level of assurance for remote connections. DirectAccess can also support integration with many existing multifactor authentication providers to provide strong authentication for the user, if desired.

DirectAccess is very firewall friendly and works anywhere the user has an active Internet connection. It requires no additional software to be installed, and the seamless and transparent nature of DirectAccess makes it much easier to use than VPN. All of this improves end user productivity and reduces associated management overhead for the solution.

DirectAccess is a more cost-effective alternative to VPN. DirectAccess can be deployed on existing infrastructure (physical or virtual) and does not require proprietary hardware. This makes it much easier and far less expensive to add additional capacity, if required. DirectAccess can also be managed using existing systems management tools and Windows administration skills and does not have any per-user licensing requirements, which results in additional cost savings over VPN.

DirectAccess Limitations and Drawbacks

DirectAccess is not a comprehensive remote access solution. It is designed for managed (domain-joined) Windows clients only. In addition, DirectAccess clients must be provisioned with the Enterprise edition SKU. Also, there are a few cases in which applications may not be compatible with DirectAccess. In addition, there is no support for DirectAccess on non-managed Windows machines, non-Enterprise SKUs, or any devices using non-Windows operating systems, so a VPN might still be required.

DirectAccess vs. VPN

DirectAccess or VPN?

You might be asking yourself, “DirectAccess or VPN?” Why not both? After all, DirectAccess and VPN aren’t mutually exclusive. They are, in fact, quite complimentary. DirectAccess can be used to provide secure remote access and enhanced management for Windows laptops managed by IT, while VPN can be deployed for non-managed devices. While you may not be able to entirely eliminate VPN with DirectAccess, it will certainly allow you to decrease the number of existing VPN licenses and reduce your investment in proprietary hardware, management tools, and dedicated administrators, all of which translates in to reduced capital investment and operational costs.

Summary

DirectAccess is not simply another VPN solution. While it does provide secure remote corporate network connectivity, it does so more securely and more cost effectively than traditional VPN does. DirectAccess is unrivaled in its security and ease of use, dramatically improving end user productivity and reducing associated infrastructure and support costs. DirectAccess can be deployed on current physical and virtual infrastructure, and can be managed using existing Windows systems management tools and skill sets.

DirectAccess Consulting ServicesIf you’d like to learn more about how DirectAccess can benefit your organization, or you would like some assistance with a DirectAccess proof of concept implementation, consider a DirectAccess consulting engagement today. I’m here to help plan, design, implement, and support DirectAccess and ensure the best chance of success for your deployment.

Additional Information

Have a question about DirectAccess? Fill out the form below and I’ll get in touch with you.

Leave a comment

29 Comments

  1. Philip B.

     /  February 12, 2016

    Hi Richard, your blogs have been incredibly helpful in getting DirectAccess up and running for us. I understand that it is much more secure than VPN in many ways, but I think it really needs another level of user authentication like you mention with multifactor. My problem is that I’ve been having a difficult time finding a good multifactor authentication provider that has small upfront costs and works with DirectAccess. We recently started using Duo as a multifactor authentication provider for our Cisco AnyConnect users, and that works great, but they don’t support DirectAccess. Can you possibly recommend some multifactor authentication providers that work well with DirectAccess?

    Thanks

    Reply
    • I don’t necessarily agree that additional user authentication is essential. Strong user authentication is critically important with traditional client-based VPN because a VPN connection can be made from any device. DirectAccess clients actually serve as a type of two-factor authentication. Because the device is trusted (has a certificate and AD computer account) it essentially serves as the “something you have” part of the multifactor authentication, making the additional strong user authentication requirement much less important.

      That said, there’s certainly nothing wrong with requiring additional user authentication. However, it does break the seamless and transparent nature of DirectAccess, which are key advantages over traditional client-based VPN.

      As for multifactor authentication providers that work with DirectAccess, both the Entrust and Gemalto solutions are popular and work well. Any OTP solution that serves as a RADIUS server should work though, really. The only limiting factor is that DirectAccess does not support challenge/response authentication solutions like Azure Mulitfactor Authentication.

      Reply
  2. Hi Richard i need your help to answer my Q , i have DA server implemented in DMZ network with one Single adapter and he need to publish the DA server on Microsoft WAP
    is that supported to publish on WAP

    Reply
  3. Dave

     /  March 9, 2016

    Requiring Enterprise SKU kills this for 75% of your customers. Unfortunate.

    Reply
    • Agreed. Microsoft has done a great job of making DirectAccess more accessible by creating the simplified deployment model, but by not supporting Windows 8 or Windows 10 Professional it really doesn’t help. :/

      Reply
  4. Bjoern Voss

     /  April 21, 2016

    Only problem I see with Direct Access (DA) vs. VPN is that sometime after clients have been Windows Patched they loses their Direct Access Icon. (Restart does not help)

    Most customers also have VPN and just connect and get their Group policies updated.
    But some users only have DA as primary remote connection. If DA does not work, then they will have to bring their PC to corporate network to get their GPO settings refreshed.

    I have not seen any fixes/workaround on this. (Script or other)

    Reply
    • That’s definitely unusual, and not something I’ve ever seen so I suspect there’s some other underlying issue that is causing this. DirectAccess is great, but for many organizations some form of client-based VPN will still be required. When DirectAccess doesn’t want to cooperate, it can sure come in handy. 🙂

      Reply
  5. Sundeep Kesavadas

     /  May 11, 2016

    What factors are critical for making applications compatible with DirectAccess?

    Reply
    • Any application will work as long as it doesn’t make calls directly to IP addresses. As long as the application uses hostnames, single label or fully-qualified, it should work fine. Also, the application should not use protocols that embed IPv4 addresses in them, such as FTP and SIP.

      Reply
  6. Lesego Fortune

     /  June 9, 2016

    Hi Richard
    What do you have to consider when you want to do a transition from VPN to DirectAccess??

    Reply
  7. I like the idea of DA and a traditional VPN working side by side. Trouble is DA seems to hijack all DNS requests while it’s trying to connect, so the traditional VPN fails.

    Reply
    • That can happen if the DirectAccess connection is trying, but failing, to connect. You can resolve this conflict by adding the public name of your VPN server to the NRPT as an exclusion. Let me know if you need assistance doing that. Happy to help. 🙂

      Reply
  8. Prasanna

     /  October 29, 2016

    I can connect my corporate servers only through FQDN, not through IP address, How to make it work with IP address

    Reply
  9. Prasanna

     /  October 29, 2016

    How to prevent DA automatically getting connected? I want to be connected only when i’m required like traditional VPN

    Reply
  10. John

     /  December 21, 2016

    Does DirectAccess behave like split VPN or will all of the traffic (including web browsing and video) from branch offices have to funnel through the main office’s internet connection?

    Reply
    • In its default configuration, DirectAccess uses split tunneling. Only traffic destined for the internal corporate network will be sent over the DirectAccess connection. All other traffic (for example web browsing Internet traffic) will be sent directly to the Internet. You can, however, enable force tunneling. It isn’t generally recommended because the user experience is so poor, but it is supported. 🙂

      Reply
  11. Sir, you say that the client machine must be a member of our domain. but i can acess a shared folder from the domain remotely while the client machine is unmembered to the domain, even though i can acess if the client machine is also a member of the domain. what is the reason for that. please answer me.

    Reply
  12. Paul

     /  February 9, 2017

    Hi Richard, I am looking at implementing DirectAccess but have a concern about how it works from a networking point of view.
    I have part of my network that I only allow certain users to access. This is controlled by a firewall ACL’s with the IP address of the users device.
    It is my understanding that when users connect over DirectAccess all users source address will be the same from the firewalls view (i.e. the IP of the DA server) as DA doesn’t provide them with unique internal IPs.
    Is this correct? Is there a way use DHCP to provide them with an individual internal address?

    Reply
    • That’s correct, assuming you are using IPv4 exclusively on your internal network. In this scenario, all traffic from remote connected DirectAccess clients will appear to come from the internal IPv4 address of the DirectAccess server. Any ACLs enforced between the DirectAccess server and the internal network will apply to all connected users. DirectAccess uses IPv6 and SLAAC. It is not possible to use IPv4 or IPv6 with DHCP.

      Reply
  13. kalaivanan

     /  October 9, 2017

    Hello Richard,
    May i know the workflow of RAS and why its faster than the Direct access server.While pinging from RAS server, its result are faster that the DA server.

    Reply
    • The connection overhead for RAS is much lower than it is for DirectAccess. The addition of IPv6 in IPv4 encapsulation required for DirectAccess is the culprit. All things being equal, VPN performance will always be better than DirectAccess.

      Reply
  14. kalaivanan

     /  October 12, 2017

    Hi Richard,

    While accessing particular application Through RAS, its accessing fast than the DA connection, may i know what is the major difference between RAS and DA?Why the connection for DA is slower than RAS?

    Reply
  1. Always On VPN and the Future of Microsoft DirectAccess | Richard M. Hicks Consulting, Inc.

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: