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!
I agree with this comment, and would suggest going with the first solution (NAT loopback, aka NAT hairpin) rather than split-horizon DNS. I say this even though I have a strong dislike of NAT (and would prefer to see networks using flat IPv6 addresses, but that’s a different topic). It should also be fairly quick to configure the hairpin on your router.
Specifically, problems arise when using DNS split-horizon where the same hostname might resolve to two different results, depending on which DNS nameserver is used. This is distinct from some corporate-esque DNS nameservers that refuse to answer for external requests but provide an answer to internal queries. Whereas by having no “single source of truth” (SSOT) for what a hostname should resolve to, this will inevitably make future debugging harder. And that’s on top of debugging NAT issues.
Plus, DNS isn’t a security feature unto itself: successful resolution of internal hostnames shouldn’t increase security exposure, since a competent firewall would block access. Some might suggest that DNS queries can reveal internal addresses to an attacker, but that’s the same faulty argument that suggests ICMP pings should be blocked; it shouldn’t.
To be clear, ad-blocking DNS servers don’t suffer from the ails of split-horizon described above, because they’re intentionally declining to give a DNS response for ad-hosting hostnames, rather than giving a different response. But even if they did, one could argue the point of ad-blocking is to block adware, so we don’t really care if SSOT is diminished for those hostnames.