DirectAccess employs a split tunneling network model by default. In this configuration, only network traffic destined for the internal network (as defined by the administrator) is tunneled over the DirectAccess connection. All other network traffic is routed directly over the Internet.
Force Tunneling Use Cases
For a variety of reasons, administrators may want to configure DirectAccess to use force tunneling, requiring all client traffic be routed over the DirectAccess connection, including public Internet traffic. Commonly this is done to ensure that all traffic is logged and, importantly, screened and filtered to enforce acceptable use policy and to prevent malware infection and potential loss of data.
DirectAccess and Force Tunneling
Enabling force tunneling for DirectAccess is not trivial, as it requires an on-premises proxy server to ensure proper functionality when accessing resources on the public Internet. You can find detailed guidance for configuring DirectAccess to use force tunneling here.
NetMotion Mobility and Force Tunneling
With NetMotion Mobility, force tunneling is enabled by default. So, if split tunneling is desired, it must be explicitly configured. Follow the steps below to create a split tunneling policy.
Create a Rule Set
- Open the NetMotion Mobility management console and click Policy > Policy Management.
- Click New.
- Enter a descriptive name for the new rule set.
- Click Ok.
Create a Rule
- Click New.
- Enter a descriptive name for the new rule.
- Click Ok.
Define an Action
- Click on the Actions tab.
- In the Addresses section check the box next to Allow network traffic for address(es)/port(s).
- In the Base section select Pass through all network traffic.
Define the Internal Network
- In the Policy rule definition section click the address(es)/port(s) link.
- Click Add.
- In the Remote Address column select Network Address.
- Enter the network prefix and prefix length that corresponds to the internal network.
- Click Ok.
- Repeat the steps above to add any additional internal subnets, as required.
- Click Ok.
- Click Save.
- Click Save.
Assign the Policy
- Click on the Subscribers tab.
- Choose a group to assign the policy to. This can be users, groups, devices, etc.
- Click Subscribe.
- Select the Split Tunneling policy.
- Click Ok.
Validation Testing
With split tunneling enabled the NetMotion Mobility client will be able to securely access internal network resources over the Mobility connection, but all other traffic will be routed over the public Internet. To confirm this, first very that internal resources are reachable. Next, open your favor Internet search engine and enter “IP”. The IP address you see should be the IP address of the client, not the on-premises gateway.
Summary
I’ve never been a big fan of force tunneling with DirectAccess. Not only is it difficult to implement (and requires additional infrastructure!) the user experience is generally poor. There are usability issues especially with captive portals for Wi-Fi, and performance often suffers. In addition, enabling force tunneling precludes the use of strong user authentication with one-time passwords.
With NetMotion Mobility, force tunneling is on by default, so no configuration changes are required. The user experience is improved as NetMotion Mobility intelligently recognizes captive portals. Performance is much better too. In addition, NetMotion Mobility is more flexible, allowing for the use of OTP authentication with force tunneling. Also, with NetMotion Mobility force tunneling is not a global setting. You can selectively apply force tunneling to users and/or groups as necessary.
Additional Information
NetMotion Mobility as an Alternative for Microsoft DirectAccess
NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection
Enabling Secure Remote Administration for the NetMotion Mobility Console
NetMotion Mobility Device Tunnel Configuration
DirectAccess has been around for many years, and with Microsoft now moving in the direction of Always On VPN, I’m often asked “What’s the difference between DirectAccess and Always On VPN?” Fundamentally they both provide seamless and transparent, always on remote access. However, Always On VPN has a number of advantages over DirectAccess in terms of security, authentication and management, performance, and supportability.
Microsoft first introduced support for null cipher suites for the IP-HTTPS IPv6 transition technology in Windows Server 2012, and it is supported for DirectAccess in Windows 8.x and Windows 10 clients. Using null cipher suites for IP-HTTPS eliminates the needless double encryption that occurs when using encrypted cipher suites. DirectAccess is a unique workload where SSL/TLS encryption isn’t really required because the payload being transported in HTTPS is already encrypted.
