5
Need help getting domain to resolve over LAN (sh.itjust.works)
submitted 1 month ago* (last edited 1 month ago) by iAmTheTot@sh.itjust.works to c/selfhosted@lemmy.world
11 comments fedilink hide all child comments

Hey all. I'm hosting a Docmost server for myself and some friends. Now, before everyone shouts "VPN!" at me, I specifically want help with this problem. Think of it as a learning experience.

The problem I have is that the Docmost server is accessible over internet and everyone can log on and use it, it's working fine. But when I try to access over LAN, it won't let me log in and I am 99% sure it's related to SSL certs over LAN from what I've read.

Here's the point I've gotten to with my own reading on this and I'm just stumped now:

I've got an UNRAID server hosted at 192.186.1.80 - on this server, there's a number of services running in docker containers. One of these services is Nginx Proxy Manager and it handles all my reverse proxying. This is all working correctly.

I could not for the life of me get Docmost working as a docker container on UNRAID, so instead I spun up a VM and installed it on there. That's hosted at 192.168.1.85 and NPM points to it when you try to access from docmost.example.com - that's all dandy.

Then, I installed Adguard Home in a docker container on my UNRAID server. I pointed my router at Adguard as a DNS server, and it seems to me that it's working fine. Internet's not broken and Adguard Home is reporting queries and blocks and all that good stuff. So that's all still working as it should, as far as I'm aware.

So, in Adguard Home I make a DNS Rewrite entry. I tell it to point docmost.example.com to 192.168.1.80, where NPM should be listening for traffic and reverse proxy me to the Docmost server... at least I thought that's what should happen, but actually nothing happens. I get a connection timed out error.

I'm still pretty new to a lot of this stuff and have tried to figure out a lot of things on my own, but at this point I feel stuck. Does anyone have advice or tips on how I can get this domain to resolve locally with certs?

I can provide more info if needed.

Cheers all!

Edited 19 April 2025 to add: Thanks for all the tips and suggestions everyone. I'm not 100% sure I fully wrap my head around what was going on here, but I did end up getting something working. I am going to continue looking into alternative solutions if only for educational purposes.

For anyone in future land who stumbles on this looking for help with a similar issue...

I'm not 100% sure what did end up fixing the issue, but I'll remark on some things I did here. Check my comments in threads below to see troubleshooting steps and advice from others.

This bit is specific to Docmost itself, but I ended up switching the APP_URL variable from https to http. This change allowed me to login to Docmost over LAN using the IP:Port of the service itself, though my browser was of course warning me that the connection was not secure.

It may be just because I restarted my PC between tries, but upon trying it again tonight, the domain resolved when I entered it into my browser... but the issue now was that it was just going to the UNRAID login page rather than getting proxied by Nginx (which as a reminder, runs in a container on UNRAID system).

So I decided to spin up a different Nginx Proxy Manager container running in a VM on a different local IP, and pointed my Adguard Home DNS rewrite entry to that IP instead of the UNRAID system. Once I configured the NPM at that IP to proxy the address to Docmost's IP:Port, voila! It worked! My friends were able to access Docmost at docmost.example.com and I was also able to access it at the same URL on my local network, and we were using the service simultaneously without issue.

top 11 comments
sorted by: hot top controversial new old
[-] Zwuzelmaus@feddit.org 0 points 1 month ago

I tell it to point docmost.example.com to 192.168.1.80, [...] but actually nothing happens. I get a connection timed out error.

I suggest to collect more info about this "nothing".

ping from your PC on the inside to the name docmost.example.com

ping from your PC on the inside to the number 192.168.1.80

traceroute from your PC on the inside to the name docmost.example.com

traceroute from your PC on the inside to the number 192.168.1.80

Then do the same in the reverse direction: from that docker container to your PC.

Maybe traceroute shows you some stations on the route. Then do the same from this station.

Write down the results thoroughly.

[-] iAmTheTot@sh.itjust.works 0 points 1 month ago

Thanks for the suggestions.

Ping from PC to docmost.example.com: Pings fine, packet loss.

Ping from PC to 192.168.1.80: Pings fine, no packet loss.

Traceroute from PC to docmost.example.com: 1 hop, all <1 ms, to 192.168.1.80

Traceroute from PC to 192.168.1.80: 1 hop, all <1 ms

Ping from Nginx container to PC: Pings fine, no packet loss.

Traceroute from Nginx container to PC: Hops to 172.18.0.1 in <1ms, and then it times out on subsequent hops.

I decided to try to traceroute from my PC to 172.18.0.1 and 172.18.0.9 which is the actual IP of the Nginx container according to UNRAID, and in both cases they hop to 192.168.1.254 which is my router, and then all subsequent hops time out.

Do you know why pings would go through without any loss but traceroutes would fail? Any idea what's going on here?

[-] Zwuzelmaus@feddit.org 1 points 1 month ago

Now you know that the problem is not your DNS.

It is either your routing or firewalling.

[-] Opisek@lemmy.world 0 points 1 month ago* (last edited 1 month ago)

Never point your DNS at two different IP addresses like this. It will only cause you pain and unexpected behaviour.

What you are experiencing is solved by so-called "NAT reflection" or "NAT loopback". It's a setting that - in the optimal case - you should just be able to activate on the appropriate interface on your gateway.

If you do not have that setting or do not have access to the edge router, but only some intermediate router, you can do a nasty hack. You can point static routes to your public IP address to point at your local IP address instead. In that case, you also need to tell your server to accept packets with your public IP address as the destination.

[-] rumba@lemmy.zip 1 points 1 month ago

Hard disagree, I'd bifurcate my internal DNS in a hot second before I tried to fix this with static routes. Was internal services aren't going anywhere in that DNS servers ain't going anywhere The only time they can figure it should take effect is when it's needed

Asking a noob to handle static routes is a double ungood situation.

Home gamer with a router that can handle reflection would be rare.

It's one service that he's hosting and in control of, and he's also in control of that internal IP so it doesn't have to change.

If anything I'd be worried that those VMs and applications in the VMs are getting regular updates. He's more likely to get intruded through a zero day on one of those hacks than he is to see any serious issues through throwing a couple DNS records around.

[-] fishynoob@infosec.pub 1 points 1 month ago

I don't think OP made two A records here. He simply configured the reverse proxy to point to the VM and the A record to point to the reverse proxy. In my mind, if NGINX is terminating SSL then the only problem could be ports.

[-] Opisek@lemmy.world 0 points 1 month ago* (last edited 1 month ago)

Not two A records. From what I understand, OP has an A record pointing to their public IP address (which Nginx is listening on behind a NAT). Then, on the local network, OP uses their own DNS server to ignore that entry and instead always serve the local IP when a host on the LAN queries it.

Aside from OP's devices potentially using a different DNS server (I was only able to solve it for my stock Android by dropping outgoing DNS in my firewall), this solution is a nightmare for roaming devices like mobile phones. Such a device might cache the DNS answer while on LAN or WAN respectively and then try to continue using that address when the device moves to the other network segment.

These are the most likely scenarios in my opinion - OP's devices are ignoring the hacky DNS rewrite (either due to using a different DNS server or due to caching) and try to access the server via the public IP. This is supported by the connection timeout, which is exactly what you would see when your gateway doesn't do loopback.

[-] ashley@lemmy.ca 3 points 1 month ago

It's called split horizon dns and it's not that bad/nightmarish.

[-] Zeoic@lemmy.world 3 points 1 month ago

Yeah, you are 100% right. Not only is it not bad in any way, but it is how nearly every single company with internal resources works.. It is incredibly common.

[-] sugar_in_your_tea@sh.itjust.works 0 points 1 month ago

Never point your DNS at two different IP addresses like this. It will only cause you pain and unexpected behaviour.

Why?

I have a similar setup, but to add to the problem, I'm also behind CGNAT. Here's my setup:

  • LAN - 192.168.. addresses
  • WAN - 10... address from ISP
  • VPS - public address

To access my LAN from outside, I have a WireGuard tunnel to my VPS.

The address my DNS resolves to is absolutely unrelated to any addresses my router understands. So to prevent traffic to my locally hosted resources from leaving my LAN, I need my DNS to resolve to local addresses. So I configured static DNS entries on my router to point to local addresses, and I have DHCP provide my router as the primary DNS source and something else as a backup.

This works really well, and TLS works as expected both on my LAN and from outside my LAN. The issue OP is seeing is probably with a non-configured device somewhere that's not querying the local DNS server.

[-] Opisek@lemmy.world 1 points 1 month ago

I explained why. Misconfiguration and caching.

this post was submitted on 18 Apr 2025
5 points (100.0% liked)

Selfhosted

48161 readers
301 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz