We help IT Professionals succeed at work.

Why Can't We Access our Server 2016 Essentials RWA/Anywhere Access site Internally?

Working through some issues on a Server 2016 Essentials server and noticed that the remote web access portal site (remote,domain.com/remote) is not accessible internally (on the LAN) but works fine externally. If I ping the site internally from the Server 2016 Essentials server, it replies back with the public IP address of the server. This seems correct and matches what we see on other Server 2016 Essentials servers with Anywhere Access/RWA working internally and externally. Likewise, if we compare DNS settings (Forward Lookup Zones) between working and non-working servers, settings appear to be the same.

Internally, if I enter the public IP in a browser, the page does not resolve. Externally, it does resolve, as does the DNS address - remote.domain.com/remote.

Running the Anywhere Access repair wizard did not address the issue. It completes successfully, but does not allow us to access the site internally on the same LAN as the server. Doesn't matter if I try from the server itself or a client workstation.
Watch Question

Jackie Man IT Manager
Top Expert 2010
What is the public IP address of your computers in your internal network when you use a browser to access www.whatismyipaddress.com?
Top Expert 2014
It's pretty typical for a firewall to block requests which originate inside the network from connecting with the IP/interface on the external side (though not all do it).
You need a DNS record on your internal DNS which resolves "remote,domain.com" to the internal IP of the server.  This is known as split DNS - when you have DNS records for the same resource hosted in different locations and those records differ.

Create a new Forward Lookup Zone with the same name as the FQDN you want to resolve, e.g. "remote,domain.com".  Inside that zone, create a new A record, leave the name blank (after it's created you will see it as "same as parent folder", and point it at the internal IP.  In this way, only the "remote,domain.com" record (and any records existing below that like "xxx.remote,domain.com", and "blah.remote,domain.com") would be resolved by your internal DNS, while other queries for domain.com would get passed to forwarders or root hints.
Thanks. That fixed it. I guess what I don't understand is why that happened. We had this all setup and tested months ago and no Forward Lookup Zone was necessary. Then, out of the blue, it stopped working internally.

But, it makes sense that it's a split DNS issue. Kinda figured it was, but just can't put my finger on what changed to make it necessary to implement split DNS.