When you access your server from LAN IP, why don't you access the private network IP address of the server directly? 

If you must access the server thorugh WAN IP, suggest to contact TP-LINK SUPPORT for help. This issue should be related to the NAT loopback for virtual server.

That's a great question! Let me add a little commentary fully explaining *why* I am attempting to do this.

Behind the scenes is a mesh network of EAP225 that are configured with multiple SSID. I have two of the SSID set to "Guest" mode, which blocks traffic to any RFC1918 ip range (10.0.0.0/8, 172.168.0.0/12, and 192.168.0.0/16). Of course, like everyone, my internal network uses one of these.

In my network, I am required to host my own DNS -- multiple reasons, but let's let that stand on its own. So if my DNS server were, say 192.168.0.1, then the PCs on any of the "Guest" networks could not access the DNS server to resolve queries. There does not seem to be any workaround for this in the Omada configuration.

So, my next thought was that since I do have a static IP, why not simply use the public ip for DNS resolution and hosting any other internal services? Then I get exactly what I want:

• The "Guest" networks cannot access any internal site unless I explicitely allow it.
• The Guest network still can access *some* internal sites that I explicitely allow.

So I added a virtual server for port 53, pointing to my internal DNS server. Externally, I can resolve the queries, but internally, I cannot.

-BlackOak

I used the below firmware and everything worked fine. You can have a try.

https://we.tl/t-ZNMLjJdP3r

For obvious reasons, I am a bit hesitent to use firmware from a random friend online in my environment :-)

While attempting to locate an "official" version, I stumbled accross this:

https://community.tp-link.com/en/business/forum/topic/150305?page=1&t=2019%2F02%2F03%2011%3A33%3A01%20%2B0000

It seems this BETA version was specifically released to address my specific problem.

Thanks, Andone! You helped me resolve tthie issue.