After configuring a Windows Server 2012 DirectAccess server to use an intranet-based Network Location Server (NLS), you may notice that the operations status in the remote access management console indicates a critical problem with NLS, when in fact you can browse the NLS server from the DirectAccess server.
The issue here is that the DirectAccess server, in addition to being able to successfully connect to the NLS using an HTTP GET, must also be able to ping the NLS server. However, inbound ICMP is often blocked on web servers which results in the DirectAccess server marking the service as failed. The issue can be quickly resolved by modifying the host firewall policy to allow inbound ICMPv4 echo requests. For example, in my test lab I’m using a Microsoft Windows Server 2012 server with Internet Information Services (IIS) installed. A new access rule can be added to the Windows Firewall with Advanced Security (WFAS) by executing the following PowerShell command:
New-NetFirewallRule -Name “Allow Inbound ICMPv4 Echo Request” -DisplayName “Allow Inbound ICMPv4 Echo Request” -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 172.16.1.241, 172.16.1.242 -Profile Domain -Action Allow -Enabled True
Note that my lab server is domain joined, so I’ve specified the WFAS profile to be the Domain profile. In addition I’ve included the IPv4 addresses assigned to the internal network interfaces of my two DirectAccess servers. You’ll need change the command as required to work in your environment.
Shakeer Ali (@tkpthalayck)
/ May 4, 2015Dear,
i have the same issue … i have tried applying the rule in firewall and still it is the same.
kashif
/ June 3, 2015Still same error coming any other solution?
Richard Hicks
/ June 3, 2015That’s the only solution. 🙂 As long as your NLS responds to ICMP echo requests, has a valid and trusted SSL certificate installed, and responds to HTTPS requests with a 200 OK, everything should work!
Stuart
/ March 23, 2016We have Network Location Server error on status page but can both ping the NLS server and access the https URL from the DirectAccess 2012 server manually but it fails to validate via the mgmt console. The event log has EvtID 10038
“Network Location Server monitor has gone from HEALTHY state to UNHEALTHY state on 21/03/2016 at 14:10 on DAServer-01. The failure heuristic IDs for state change of Network Location Server are 800d0002.”
Have altready tried reboot. DA Clients are generally still working. Any ideas how to troubleshoot this further please?
Richard M. Hicks
/ March 23, 2016Is DirectAccess running on Windows Server 2012 or 2012 R2? Also, is it running on VMware?
Fraser
/ April 16, 2019Was there a solution to this error, we are encountering this aswell.
Chris
/ April 13, 2016What about if you have 2 NLS servers behind a load-balancer? I’m trying to run DA in Azure and have tried a couple of load-balancers (Azure’s own and loadbalancer.org) but neither allow icmp responses from the virtual IP. The real servers respond to pings so it’s not an issue with the firewall on the IIS servers. Thanks
Richard M. Hicks
/ April 13, 2016This check is performed by the management console, so the VIP must respond to ICMP. However, you can disable the ICMP health check in the management console by highlighting Operations Status in the navigation tree and then clicking on Disable Connectivity Check (PING) below Monitoring in the Tasks pane.
Chris
/ April 14, 2016Thanks Richard, I had not even noticed that option as the window had been collapsed!
George Magdy Philip
/ July 14, 2016Hello Mr. Richard I had the same error and I am just wondering if this could affect the connectivity between the clients and the server via the WSE connector cause I can’t get any of my clients to successfully connect to the server though the client did find the server name yet never get connection and it gives me this message ” can’t get information from “my server name” .please contact your server administrator .
Thank you for your time 🙂
Richard M. Hicks
/ July 18, 2016I apologize, I don’t have any experience with configuring DirectAccess on WSE. There could very well be a conflict that I’m not aware of.
Paul
/ March 19, 2018Hi, new to DA – just enabled it on a 2016 Server Standard with Essentials role installed. Getting this error although I am able to ping directaccess-corpconnectivityhost and directaccess-webprobehost on the LAN. But, testing the connection in a web browser i am running into a certificate error. We have a trusted SSL cert installed for remote.domain.com, but of course that is only valid for the external server name (where as I understand it we do NOT want nls to resolve. .) We do not have a trusted cert for the internal domain.local names, although I do see a DirectAccess-RADIUS-Encrypt-server.domain.local cert in the store that seems to have been auto-created by the wizard. I suspect that the HTTPS GET part of the connectivity test is failing because there is no cert for the https connection to the internal nls name – so, since we have a trusted cert installed for all the external communication purposes, are we expected to also obtain a trusted one for this internal purpose and bind it as well to port 443 in IIS? Or to 62000? For which site? Or, can we self-issue one for this purpose (which you do not recommend)? Or is it just a matter of binding the RADIUS cert correctly?? Thanks!!
Richard M. Hicks
/ March 21, 2018If the NLS is hosted on the DirectAccess server it will use a local certificate for the NLS, typically a self-signed one. DirectAccess clients are then configured to trust it through group policy. If you are testing with a non-DirectAccess client you will likely get a certificate error. FYI, best practice is to host the NLS off-box and use a certificate issued by your internal PKI. Might be a good time to do that just to make sure things are more stable in the future. 🙂
Paul
/ March 21, 2018It is all on the same box (single-server environment.) I no longer think it is a certificate issue, although still not totally sure. I did find in the configuration where cert is specified, and also where the NLS test URL is listed – interestingly, it was http:// not https:// (and the only two choices for test types are HTTP and PING. . .) But changing this made no difference. Neither did removing the HTTP test and putting in only a PING test – same error reported! So who knows what the configuration test is actually doing. I downloaded your NLS testing utility (THANKS!) and it gave the same results. I also tried using puTTY to open a plain old session to the url and got the 400 error message on connecting, which I have seen mentioned elsewhere. Connection closes right away. My feeling is it has to do with the Remote Web Workplace which is what opens by default if you browse to the server – possibly a conflict with that redirection? Another classic case of Microsoft’s own products not being compatible with each other (at least this time it didn’t take me long to figure out that DA had stolen the TCP ports used by the Server Essentials Connector – like when I tried out Work Folders and it clobbered DNS. . .) I noticed an “insideoutside” folder link had been added to the default site in IIS, maybe the NLS test is expecting to get that by default? But in any case I started to see more recent information (from you as well as others) that DA was being abandoned by Microsoft, so I probably won’t waste any more time pulling my hair out over this & just see if I can figure out how to deploy Always-on VPN without shelling out for an Intune or MSCCM subscription (small-ish client, not very many mobile users. . .) Thanks for all the helpful info!
Paul
/ March 21, 2018Looking into the “insideoutside” virtual directory, if I browse that from the links in IIS manager I get variously a certificate error or not, but always some form of 503 Forbidden if I bypass that – either .503 (do not have permission to view) or .14 (server configured to not list contents) Except one method that gives me ERR_NETWORK_ACCESS_DENIED. . .
Paul
/ March 22, 2018Now I’m back to the cert issue – the only way I have been able to successfully browse to the /insideout virtual dir is to enable directory listing on it in IIS, then https://directaccess-webprobehost:62000/insideoutside and bypass the certificate warning. But of note, in the DA infrastructure configuration the certificate selected for NLS is not for this host name, it is a self-issued cert for the server name. But if I replace the url with the server name instead of direcaccess-webprobehost it is the same – works but have to go past the cert error, so no https. I would say the solution would be to get a cert for directaccess-webprobehost but then I don’t know why using the server name didn’t work, since there is a cert for that. . . Or, can we just disable SSL for this virtual directory? The client config only specifies HTTP anyway – or is that just inaccurate? Sorry to take over your blog! Thanks. . .
Richard M. Hicks
/ March 23, 2018I think you are confusing two different things here. The Network Location Server (NLS) is definitely SSL and you probably have it hosted on the DirectAccess server. If so, it is running on port 62000. It is used by clients to detect if they are inside the network or outside. It must have an SSL certificate trusted by the client. If you are using a slef-signed certificate, that certificate is pushed to all DirectAccess clients via GPO so they trust it. The web probe host is for the Network Connectivity Assistant (NCA) and is used by clients to validate the DirectAccess connection when they are remote. It is HTTP and does not require an SSL certificate.
Paul
/ March 23, 2018Well I am definitely confused! Thanks for that clarification, I was assuming that webprobehost is what clients used to determine if they were on the LAN already & thus didn’t need to connect via VPN. Would https://directaccess-corpconnectivity:62000 be the correct url to troubleshoot NLS connectivity? That is listed in DNS as 127.0.0.1 so I don’t see how it will work from any other location than the server itself. . .What would be the best way to troubleshoot this issue of not being able to retrieve the NLS server url in the Operations Status of Remote Access Management Console? What is the actual URL it is trying to use for that test? BTW, the server does respond to pings on the LAN.
Richard M. Hicks
/ March 23, 2018No. The NLS URL is most likely https::/directaccess-NLS.[FQDN]:62000. The directaccess-corpConnectivityHost is used for something entirely different.
Paul
/ March 23, 2018Well surprise update, somehow since yesterday the status of NLS has gone to green in the RAMC. The last thing I tried was enabling directory browsing for the /insideout virtual directoy, maybe that was the trick & it took a while to kick in??
Paul
/ March 23, 2018I am still curious what the url is that it is looking for – if I browse to https://servername:62000/insideoutside using the same server name specified on the cert that is selected in the Remote Access infrastructure setup, I get a NET::ERR_CERT_COMMON_NAME_INVALID error. If I accept the risk & proceed anyway (this is using Chrome. . ) then I get the (empty) directory listing – but only since enabling directory browsing on it in IIS. I don’t know if that is what has allowed the status to go to green, or if it is because I have added the site to my security exceptions in Chrome, or something else. . .or, if it will actually work for the DA client.
Richard M. Hicks
/ March 23, 2018https://servername:62000 is incorrect. It should be https://DirectAccess-NLS.[FQDN]:62000. That should match the subject name on the self-signed certificate.
Paul
/ March 23, 2018Hmm, well the only DNS records added by the Remote Access Management Console (I did the basic configuration walk-through) are directaccess-webprobehost and two for directaccess-corpconnectivityhost – both A and AAAA. Maybe that’s the problem?. But, then I don’t know how the NLS test went green in the console. . . And of course, the cert selected in the Infrastructure config is not for any of those host names, just the regular server name. BTW Is there a comprehensive guide to all of these details anywhere? All I have been able to find are little bits & pieces, mostly pertaining to Server 2012. Even the documentation on Technet under Server 2016 still references 2012 for DA. Thanks again for your guidance!
Richard M. Hicks
/ March 24, 2018The directaccess-NLS record should be created automatically when you install DirectAccess (if you chose the option to host the NLS on the DirectAccess server) and it would resolve to the DirectAccess server’s internal network interface IP address.
The only comprehensive guide I’m aware of is my DirectAccess book. 😉
Richard M. Hicks
/ March 23, 2018Not sure. Making changes to the /insideoutside virtual directory shouldn’t have been necessary, so I’m not certain why it wasn’t working, or why it suddenly started working now to be honest.
Paul
/ March 24, 2018Interesting, I poked around in the registry and under HKLM\System\CurrentControlSet\Services\RaMgmtSvc\Config\Paramteters the value for NlsUrl is in fact https://SERVERNAME/insideoutside with no port specified. There is also a NlsDasOnSameBox key, which is set to 1. Maybe that is new.
Another thing I have noticed – depending on which browser I use to test the url, I get different SSL errors. Chrome gives me NET::ERR_CERT_COMMON_NAME_INVALID, while Firefox reports
SEC_ERROR_UNKNOWN_ISSUER. The cert that is configured in DA matches the servername, BUT I am not able to check the “Use a Self-Signed Certificate” box, it is grayed out. The Firefox warning indicates a problem with the certification path, so that may be part of the issue there. I have read that the latest version of Chrome requires a check on an IP address in the SubjectAlternativeName extension, which is causing a lot of problems for internal self-signed certs – so these may not be the best way to test this anyway. What would be the closest thing to how the DA service actually retrieves this url?
Paul
/ March 24, 2018AND, trying IE I get no SSL error but a 403.503 Forbidden error just using the plain url, and a if I append port 62000 I get Server Error in “/” Application. . . . A potentially dangerous Request.Path value was detected from the client (:). . . what a rabbit hole!
Just for kicks, I went back and disabled Directory Browsing on /insideoutside in IIS, and sure enough the NLS test in the Remote Access Dashboard went right to red again. . . at this point my conclusion is that the SSL error is not a problem for DA, but not being able to browse the virtual directory is.
Richard M. Hicks
/ March 25, 2018Taking a step back for a second, I have to say that all of this is typically not necessary. You should never have to make changes to IIS over to the file system to get the NLS to work. Not sure what happened, but I suspect that somehow the install went sideways and you’ve been fighting gremlins because of it. That said, I would be very hesitant to put this server in to production as I would have serious doubts about its reliability going forward. I would recommend removing the configuration entirely, rebuilding the server, and starting over from scratch. Also, if you go that route, I would strongly encourage you to deploy a separate NLS, as that is the best practice recommendation (ideally two for redundancy!). Or better yet, consider moving to Always On VPN as there is no NLS to worry about. 🙂
Paul
/ March 25, 2018So far it has pretty much just been an experiment – and yes, I agree it sounds like Always On VPN is a more reliable route (although unfortunately there doesn’t seem to be an easy implementation wizard for it. . . this is a single-server operation with about 25 users so they aren’t probably going to want to invest in Intune or MSCCM. . . ) My gut feeling is that maybe I used a newer/updated version of the configuration wizard and there are some kinks to it, and/or some conflicts in IIS with the RWW aspects of the WSE Role that is installed. But thanks for the tips & maybe you’ll hear from me on the VPN side!
tFable
/ October 19, 2018Hey Richard,
Regarding the requirement for the NLS endpoint to be ping-able by the DA server:
Is there any functional issue of the NLS endpoint is NOT ping-able by the DA server? Or is the only issue the cosmetic annoyance of seeing the NLS service as “failed” on the DA health dashboard?
Thanks!
tFable
Richard M. Hicks
/ October 20, 2018No functional issues at all if ICMP echo request isn’t allowed on the NLS. The only negative side effect is the reported health status in the Remote Access Management console.
Rudreshamurthy R C
/ August 1, 2023Hello Richard, my case projecting that “Network location server not working properly” NL server is pingable from DA server, FQDN is getting resolved, local IIS page opens with no errors, both servers are reachable from network front, but critical error still comes up…not sure
Richard M. Hicks
/ August 1, 2023If you can browse the NLS without errors and you can ping the NLS from the DirectAccess server, the only thing I can think of that will result in an NLS error in the remote access management console is if TLS 1.0 and 1.1 are disabled on the NLS server. You may need to re-enabled TLS 1.0 and 1.1 on the NLS server to resolve that error.