Learn PowerShell!
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 
When configuring Windows 10 Always On VPN using the Routing and Remote Access Service (RRAS) on Windows Server 2012 R2 and Extensible Authentication Protocol (EAP) authentication using client certificates, clients attempting to establish a VPN connection using Internet Key Exchange version 2 (IKEv2) may receive the following error.
I’m pleased to announce that I will be bringing my popular three-day Windows 10 Always On VPN Hands-On Training classes to Denver and New York in May and June! Join me May 15-17, 2018 in Denver or June 5-7, 2018 in New York. These training classes will cover all aspects of designing, implement, and supporting an Always On VPN solution in the enterprise. These three-day courses will cover topics including…
Performance issues with DirectAccess are not uncommon. In fact, there are numerous 
To enhance 
One of the many advantages 
Note: The process of saving the network interface configuration takes a few minutes. Be patient!
