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.
Critical Infrastructure
DirectAccess NLS availability and reachability is crucial to ensuring uninterrupted operation for DirectAccess clients on the internal network. If the NLS is offline or unreachable for any reason, DirectAccess clients on the internal network will be unable to access internal resources by name until the NLS is once again available. To ensure reliable NLS operation and to avoid potential disruption, the NLS should be highly available and geographically redundant. Close attention must be paid to NLS SSL certificate expiration dates too.
NetMotion Mobility
NetMotion Mobility does not require additional infrastructure for inside/outside detection as DirectAccess does. Instead, Mobility clients determine their network location by the IP address of the Mobility server they are connected to.
Unlike DirectAccess, NetMotion Mobility clients will connect to the Mobility server whenever it is reachable, even if they are on the internal network. There are some advantages to this, but if this behavior isn’t desired, a policy can be created that effectively replicates DirectAccess client behavior by bypassing the Mobility client when the client is on the internal network.
Configuring Trusted Network Detection
Follow the steps below to create a policy to enable trusted network detection for NetMotion Mobility clients.
Create a Rule Set
- From the drop-down menu in the NetMotion Mobility management console click Policy and then 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 a Condition
- Click on the Conditions tab.
- In the Addresses section check the box next to When the Mobility server address is address.
- In the Policy rule definition section click the equal to address(es) (v9.0) link.
- Click Add.
- Select Mobility server address.
- Select the IP address assigned to the Mobility server’s internal network interface.
- Click Ok.
- Click Ok.
Define an Action
- Click on the Actions tab.
- In the Passthrough Mode section check the box next to Enable/disable passthrough mode.
- 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 Trusted Network Detection policy.
- Click Ok.
Validation Testing
The NetMotion Mobility client will connect normally when the client is outside of the network. However, if the Mobility client detects that it is connected to the internal interface of the Mobility server, all network traffic will bypass the Mobility client.
Summary
Trusted network detection can be used to control client behavior based on their network location. Many administrators prefer that connections only be made when clients are outside the network. DirectAccess clients use the NLS to determine network location and will not establish a DirectAccess connection if the NLS is reachable.
NetMotion Mobility trusted network detection relies on detecting the IP address of the Mobility server to which the connection was made. This is more elegant and effective than the DirectAccess NLS, and more reliable too.
Additional Information
Enabling Secure Remote Administrator for the NetMotion Mobility Management Console
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.
DirectAccess connections are bidirectional, allowing administrators to remotely connect to clients and manage them when they are out of the office. DirectAccess clients use IPv6 exclusively, so any communication initiated from the internal network to remote DirectAccess clients must also use IPv6. If IPv6 is not deployed natively on the internal network, the Intrasite Automatic Tunnel Addressing Protocol (ISATAP) IPv6 transition technology can be used to enable manage out.
