Networking – Public IP address answered by router, not internal web server with Port Forwarding

According to the screenshots you are showing, you have port forwarding oddly set on your WAN connection as follows:

• External Port Start/End: 80/80
• Protocol: TCP
• Internal Port Start/End: 80/80
• Server IP Address: 192.168.1.11
• Schedule Rule: Always
• Remote IP: 192.168.1.11

The way you have that setup basically tells the router to just route all traffic from 192.168.1.11 on port 80 to 192.168.1.11 on port 80 which makes no sense. The “Remote IP:” should be set to your external IP address of 117.218.XXX.XXX like this:

• Remote IP: 117.218.XXX.XXX

With that in place that tells the router to route all traffic from 117.218.XXX.XXX on port 80 to 192.168.1.11 on port 80.

That said, if the router itself uses port 80 for the D-Link management page, then you need to see if you can change the port that management page uses. Otherwise all you are doing with that ruleset is exposing your D-Link management page to anyone/anything that can reach that 117.218.XXX.XXX. As to how to do that? Each router has different ways to handle that and some routers just don’t provide end users with that option since ISP’s generally don’t want end-users to easily run web servers off of their ISP-provided Internet connection.

If you cannot change the D-Link management page port to be something other than port 80 the next best thing is to just change your web server’s port to be something else, like 8000 or 8080. Of course you now need to adjust your port forwarding rules to match the new port, but it might be the best/simplest solution to this issue.

As suggested in the comments to your question, you have several options:

• See if you router supports NAT Hairpinning (also referred to as NAT Loopback or NAT Reflection per @DavidPostill) and whether it might need to be enabled (per @AFH).

• If your router does not support hairpinning, buy a new one that does. This feature is semi-common in modern day consumer-grade routers but you will still likely want to do a bit of research before making any new purchase.

• It may be possible to upgrade the router with Linux-based firmware such Tomato, DD-WRT or OpenWRT which can allow hairpinning (but this is likely a very technical endeavor).

• As suggested by @SpiderPig, you can set up your own private DNS server on your internal network. This route is a bit more technical (and unnecessary if hairpinning can be enabled) but is probably the safer of the two technical solutions.

Private DNS Requirements

While there are obviously different steps for different network configurations, the principles for working around a lack of hairpinning with the last solution are the same:

• Configure the external version of your domain with a DNS server that does not otherwise directly provide services for your internal version of that domain (likely DNS provided by your Registrar or 3rd-party services such as Namecheap FreeDNS).

• Configure a separate DNS server (such as ISC BIND) for your internal network which handles your domain locally. That is, create an entry for your domain on that server and point it towards the correct internal web server IP. You can then have your internal computers use this local DNS server for domain resolution.

The reason this setup works is because non-internal queries are going through one (external) DNS provider (which has your public IP) while internal queries go through a second (i.e. the local DNS server with your private IP).

It is probably worth mentioning that besides "regular" domains, this option will also likely work for many "Dynamic DNS" providers as well (where the provider automatically satisfies the first requirement).

Note that both Namecheap FreeDNS and BIND are currently free and thus very cost-effective.

Basics With BIND

I going to assume that you have your domain configured with your Registrar to use DNS servers you do not control. In this instance, you likely do not need to take additional steps to meet the first requirement listed above.

Regarding the second requirement (your local network setup), I wrote a pretty thorough explanation on the basics of getting BIND working on Windows with a local domain a while back.

As for the choice of which computer to use as a local DNS server, the only real requirement is that it be ON consistently (as it will be needed for domain resolution). Outside of that stipulation, you can pretty much pick whichever computer on the network you like (even the web server itself).

Answer Notes

In my answer linked above, there are definitely a few spots you can ignore (mostly the WAMP stuff). Otherwise, the setup detailed there is the basic setup you need locally for your domain. For your situation, the few things that need to be altered are:

1. Substitute your own (external) domain for the "free.goodies" example domain.

2. Make sure any other miscellaneous items match your set up (e.g. installation paths, IP addresses, file names, rndc secret, etc.)

3. Make sure to uncomment the line for "forwarders" in "named.conf" (i.e. remove the hash #):

         forwarders { 8.8.8.8; 8.8.4.4; };
   

Note that the last item is absolutely necessary so your local network can contact non-local domains (i.e. the rest of the internet other than your domain). The specific IPs listed are functional as-is (they are Google's Public DNS servers) but you can substitute any others you like as well (including those of your ISP).

You still need to make sure to configure your local computers and router to use your local DNS server (as detailed near the end of the linked answer).

Linux Notes

If you are using Linux, you can of course choose to install files from the ISC BIND website. However, as an alternative, many distributions of Linux come with BIND already installed or available through their respective repositories.

As far as a local DNS server is concerned, there are a number of good net tutorials for different distributions. But the principle is the same -- set up a local DNS server to access your domain entirely from the local network (without needing the internet).

Caveats

• Successfully accessing your domain locally will not always mean it will be accessible externally. You will always need to test external access with a network that doesn't use your router (e.g. your phone connected through its data plan).

• There are some potential risks involved in running a DNS server and specifically in emulating domains with TLDs such as .com or .net. While it is possible to do so (as outlined here), you may want to consider researching any potential pitfalls.