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 clients use the Network Location Server (NLS) for trusted network detection. If the NLS can be reached, the client will assume it is on the internal network and the DirectAccess connection will not be made. If the NLS cannot be reached, the client will assume it is outside the network and it will then attempt to establish a connection to the DirectAccess server.
One of the first places administrators look for information about the DirectAccess client connection is the Network Connectivity Assistant (NCA). The NCA is used to view current connection status and to gather detailed information that is helpful for troubleshooting failed DirectAccess connections. The NCA was first integrated with the client operating system beginning with Windows 8. Similar functionality can be extended to Windows 7 clients by installing and configuring the 
An SSL certificate is required to support the IP-HTTPS IPv6 transition technology when configuring DirectAccess. Implementation best practices dictate using a public SSL certificate signed by a trusted third-party vendor such as Entrust, Verisign, DigiCert, and others. SSL certificates issued by a private PKI are acceptable if the client trusts the issuing CA. Self-signed certificates are supported in some deployment scenarios, but their use is generally discouraged. For more detailed information regarding SSL certificate considerations for DirectAccess IP-HTTPS click 
Performance issues with DirectAccess are not uncommon. In fact, there are numerous 
To enhance 
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.
The Name Resolution Policy Table (NRPT) in Windows provides policy-based name resolution request routing for DNS queries. DirectAccess uses the NRPT to ensure that only requests for resources in the internal namespace, as defined by the DirectAccess administrator, are sent over the DirectAccess connection. DNS queries for all other namespaces are sent to the DNS servers defined on the client’s network interface.
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.
