External Custom Domain inside LAN

I have an external custom domain, mydomain.com, which points to my public IP address, which is dynamically updated from my server, which has my reverse proxy installed (Caddy) that tells the traffic where to go based on the subdomain.

Ports 80 and 443 are forwarded at the router to the server, and I have all the various CNAME records set up with the registrar for the various subdomains that correspond to my reverse proxy config (Caddyfile).

All of this works beautifully when I’m not on my LAN (or when I’m on my LAN using Tor or a VPN); for example, going to emby.mydomain.com brings up Emby, going to tv.mydomain.com brings up Sonarr, etc.

When I’m on my LAN, all those URLs redirect to my router login page. I cannot for the life of my figure out how to get this to work. I’m also using unbound, in addition to pihole and the Caddy reverse proxy.

I do not care about accessing it via my-server-name. I want to use the custom domain.

Any help is much appreciated.

Depending router implementation, probably the router is only port forwarding traffic coming in via the router’s WAN interface and not when coming in via the LAN interface.

How do I confirm that this is happening? Is there any way to trace this? Because everything that comes close to resembling any setting like this on my router/modem is enabled.

Its already confirmed by you seeing the router web page instead of getting routed to the internal LAN IP’s.

EDIT: You would want to check the routing table on the router somehow.

Yesterday, I added 3 lines to my pi-hole.conf file in unbound:

private-domain: mydomain.com
local-zone: "mydomain.com" redirect
local-data: "mydomain.com A server_LAN_IP"

and after restarting unbound, it worked! Then this morning it stopped working.

Your clients might be bypassing your Unbound setup by having another DNS server configured.
For Windows clients, you can check DNS servers assigned, and by whom, with below one in a CMD prompt:

ipconfig /all | findstr "Server"

For Linux and MacOS clients, below might reveal if not have a local caching DNS service running:

cat /etc/resolv.conf

Testing on a client can be done with the nslookup tool (Windows/Linux/MacOS).
Below = Pi-hole @ my place:

C:\Users\deHakkelaar> nslookup pi.hole
Server:  noads.dehakkelaar.nl

Name:    pi.hole

nslookup for *.mydomain.com returns my public WAN IP, where * is any of the CNAMEs I have registered with the DNS of mydomain.com registrar.

Looks like Unbound is bypassed and you get the public records returned.
Pi-hole has got their own Unbound setup guide and use dig instead of nslookup to test:


Try go through that before try creating those local A records etc.
Am unfamiliar with Unbound’s syntax for creating local records so cant help you with that.

That’s the guide I used from day 1.


I did a dig for emby.mydomain.com (listed in the question section), the answer section says:

emby.mydomain.com 60 IN CNAME mydomain.com
mydomain.com 60 IN A my_public_WAN_IP

Can you copy past output for below instead of pasting the screenshots ?
Easier for you to redact and for us to read/copy/paste.
Can enclose with the </> button while entering here.
Replace mydomain.com with actual one oc.

dig +short @ -p 5353 mydomain.com

dig +short @ chaos txt servers.bind


"internal_router_IP#53 62 6" " 2623 790"

Thats probably the bypass.
Pi-hole should have only one upstream custom DNS server configured according to the official guide !

Found the issue. I had conditional formatting set up in pihole with internal_router_IP to mylandomain. I think the problem was that in my router settings, I put mylandomain to match mydomain.com, including the .com part (thought I’m not using .com). So I had it set that mylandomain = mydomain.com. Same exact strings. Removing the conditional forwarding in the pihole fixed it.

1 Like


I didn’t realize I wasn’t allowed to do what I did. I’m new to this, as you can tell.

Well now your the expert :wink:

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.