nls server detection issue

Yuso Faisyahhhhh 60 Reputation points
2026-08-19T02:30:03.2433333+00:00

Hi all

May i know if someone here when use remote directaccess inside corporate network have problem where sometime the client fail to detect internal nls server and keep ipsec tunnel active, losing local network access? I don't know if my issue is from endpoint side or from nls certificate trust or url reachability.

Windows for business | Windows 365 Business
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Harry Phan 28,780 Reputation points Independent Advisor
    2026-08-19T04:03:55.05+00:00

    Hello,

    When DirectAccess clients fail to detect the internal NLS server and keep the IPsec tunnel active, the issue almost always comes down to either NLS reachability or certificate trust. If the client cannot reach the NLS URL or validate its SSL certificate, it assumes it is outside the corporate network and maintains the tunnel, which blocks local LAN access. Start by confirming DNS resolution of the NLS hostname and test HTTPS connectivity directly from the client. If reachability is intermittent, check firewall rules, load balancer health, or packet drops.

    On the certificate side, ensure the NLS certificate chain is fully trusted. If it’s issued by an internal CA, the root CA must be deployed to all clients via Group Policy, and CRL/OCSP endpoints must be reachable. Even a temporary CRL outage can cause trust failures. If connectivity and trust are fine, review the client’s DirectAccess configuration with netsh namespace show policy and clear NRPT cache with ipconfig /flushdns to rule out stale policy data.

    If the tunnel persists despite NLS availability, enable DirectAccess tracing (netsh trace start scenario=DirectAccess) and check logs under %windir%\tracing to see whether the failure is due to DNS, HTTP, or certificate validation. In most cases, stabilizing NLS availability and ensuring proper certificate trust resolves the problem.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    HP.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-08-19T02:30:22.2933333+00:00

    Yes. This can happen when the DirectAccess client cannot reliably determine that it is inside the corporate network by reaching the Network Location Server (NLS). In that state, the client can keep DirectAccess/IPsec active instead of switching to local access.

    Check these areas first:

    1. Verify NLS reachability from an internal client
      • On an internal DirectAccess client, run Get-NCSIPolicyConfiguration.
      • Check the DomainLocationDeterminationURL value.
      • When that URL is reachable, the client should detect it is inside the corporate network.
      • Run Get-DAConnectionStatus. If NLS is reachable internally, the expected status is ConnectedLocally.
    2. Confirm the NLS DNS behavior
      • Internal clients must be able to resolve the NLS name.
      • Internet-based DirectAccess clients must not be able to resolve or access the NLS site.
      • By default, the NLS FQDN is added as an exemption rule to the NRPT. If name resolution is inconsistent, clients can mis-detect location.
      • Run Get-DnsClientNrptPolicy and confirm the NLS server exemption is present.
    3. Validate the NLS website requirements The NLS site should:
      • use an HTTPS server certificate
      • have high availability for internal computers
      • not be accessible from the Internet
      • be resolvable by internal DirectAccess clients
    4. Check NLS certificate trust DirectAccess clients must trust the CA that issued the NLS server certificate. For the NLS certificate:
      • the Subject should contain the intranet IP address of the NLS server or the FQDN of the NLS URL
      • the Enhanced Key Usage should be Server Authentication OID
      • the certificate should be checked against a CRL
      • the CRL distribution point should be accessible to DirectAccess clients on the intranet and should not be accessible from outside the internal network
    5. If the issue is intermittent, focus on endpoint-side detection Since the symptom is intermittent, test whether the client is failing DNS resolution or LDAP/domain detection during network changes.
      • Collect a Wireshark trace while disabling and re-enabling the network adapter or restarting the NLS service.
      • In the trace, filter for dns and look for the _ldap query.
      • Then verify the client can establish LDAP over TCP 389 to a domain controller. This helps determine whether the problem is broader network/domain detection on the endpoint rather than only the NLS certificate.
    6. If using DirectAccess IPsec certificates, validate them separately If the client also has IPsec errors, verify the IP-HTTPS or machine certificate is:
      • not expired
      • has a private key
      • configured for client authentication
      • chains to the configured root or intermediate certificate

    A practical way to separate the cause is:

    • If DomainLocationDeterminationURL is unreachable or inconsistent internally, investigate NLS URL availability, DNS, and certificate trust.
    • If the NLS URL is reachable but detection still flips unexpectedly, investigate client-side network/domain detection with a trace.

    If the issue persists after trace collection, Microsoft Support is the documented next step for deeper troubleshooting.

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.