Hi folks,
TL;DR: my remaining issue seems to be firefox specific, I’ve otherwise made it work on other browsers and other devices, so I’ll consider this issue resolved. Thank you very much for all your replies and help! (Edit, this was also solved now in EDIT-4).
I’m trying to setup HTTPS for my local services on my home network. I’m gotten a domain name mydomain.tld and my homeserver is running at home on let’s say 192.168.10.20. I’ve setup Nginx Proxy Manager and I can access it using its local ip address as I’ve forwarded ports 80 and 443 to it.
Hence, when I navigate on my computer to http://192.168.10.20/ I am greeted with the NPM default Congratulations screen confirming that it’s reachable. Great!
Next, I’ve setup an A record on my registrar pointing to 192.168.10.20. I think I’ve been able to confirm this works because when I check on an online DNS lookup tool like https://centralops.net/CO/Traceroute as it says 192.168.10.20 is a special address that is not allowed for this tool.. Great!
Now, what I’m having trouble with, is the following: make it such that when I navigate to http://mydomain.tld/ I get to the NPM welcome screen at http://192.168.10.20/. When I try this, I’m getting the firefox message:
Hmm. We’re having trouble finding that site.
We can’t connect to the server at mydomain.tld.
Strangely, whenever I try to navigate to http://mydomain.tld/ it redirects me to https://mydomain.tld/, so I’ve tried solving this using a certificate, using the DNS-01 challenge from NPM, and setting up a reverse proxy from https://mydomain.tld/ to http://192.168.10.20/ and with the wildcard certificate from the challenge, but it hasn’t changed anything.
I’m unsure how to keep debugging from here? Any advice or help? I’m clearly missing something in my understanding of how this works. Thanks!
EDIT: It seems several are confused by my use of internal IP addresses in this way, yes it is entirely possible. There are multiple people reporting to use exactly this kind of setup, here are some examples.
EDIT-2: I’ve made progress. It seems I’m having two issues simultaneously. First one was that I was trying to test my NPM instance by attempting to reach the Congratulations page, served on port 80. That in itself was not working as it ended in an infinite-loop resolving loop, so trying to instead expose the admin page, default port 81, seems to work in some cases. And that’s due to the next issue, which is that on some browsers / with some DNS, the endpoint can be reached but not on others. For some reason I’m unable to make it work on Firefox, but on Chromium (or even on Vanadium on my phone), it works just fine. I’m still trying to understand what’s preventing it from working on Firefox, I’ve attempted multiple DNS settings, but it seems there’s something else at play as well.
EDIT-3: While I have not made it work in all situations I wanted, I will consider this “solved”, because I believe the remaining issue is a Firefox-specific one. My errors so far, which I’ve addressed are that I could not attempt at exposing the NPM congratulations page which was shown on port 80, because it lead to a resolution loop. Exposing the actual admin page on port 81 was a more realistic test to verify whether it worked. Then, setting up the forwarding of that page using something like https://npm.mydomain.tld/ and linking that to the internal IP address of my NPM instance, and port 81, while using the wildcard certificate for my public domain was then necessary. Finally, I was testing exclusively on Firefox. While I also made no progress when using dig, curl or host, as suggested in the commends (which are still useful tools in general!) I managed to access my NPM admin page using other browsers and other devices, all from my home network (the only use-case I was interested in). I’ll keep digging to figure out what specific issue remains with my Firefox, I’ve verified multiple things, from changing the DNS on firefox (seems not to work, showing Status: Not active (TRR_BAD_URL) in the firefox DNS page (e.g. with base.dns.mullvad.dns). Yet LibreWolf works just fine when changing DNS. Go figure…
EDIT-4: I have now solved it in firefox too, thanks to @non_burglar@lemmy.world! So it turns out, firefox has setup a validation system for DNS settings, called TRR. You can read more about it here: https://wiki.mozilla.org/Trusted_Recursive_Resolver Firefox has a number of TRR configurations, preventing the complete customization of DNS, but also with specific defaults that prevent my use-case. By opening up the firefox config page at about:config, search for network.trr.allow-rfc1918 and set it to true. This now solved it for me. This allows the resolution of local IP addresses. You can read more about RFC1918 here: https://datatracker.ietf.org/doc/html/rfc1918
I’ll probably still look to actually make other DNS usable, such as base.dns.mullvad.net which is impossible to use on Firefox by default…
It does work. In my first edit I’m sharing multiple examples of others making it work, and I’ve made it work in some cases which I explain in my second edit. I’m not using an HTTP challenge, but a DNS challenge which is not specific to any IP address and does not require the IP address to be reachable from outside my network. I only care about accessing the endpoint from within my home network. The use of a real domain allows me to make use of the public chain of trust infrastructure and DNS allowing me to reach my homeserver using any device without having to setup any specific local DNS or installing any custom certificate on any of my devices.
Try turning off WiFi on your phone and see if you can connect from there. Connecting from a device within your home network to a another device in your home network is different than connecting from a device out on the internet to a device in your home network. Phone using data is a good way to check that “internet device to home network” case.
Works flawlessly with my tailscale setup :) Thanks for asking! I’m not trying to expose anything to the open. Just for me personally, from home or remotely using my VPN.
No, it is not fully working.
Many have tried to explain to you that your setup only works for YOU on YOUR subnet.
Your are then asking other public tools meant to lookup public ips with publicly-available DNS names to resolve your internal addresses, which they obviously don’t know anything about, and you’re getting those errors from tools that follow rfc because you are putting the equivalent of “bedroom” on the outside of an envelope and expecting the post office to know that it means YOUR bedroom.
For dns to work properly, the authoritative DNS server should be able to create a reverse lookup record for every a record that allow a DNS client to ask “what record do you have for this IP?” and get a coherent response. Since 192.168.10.0/24 is a non-routable network, you will never have such a reverse record.
Wolfgang has done you a disservice by giving you a shortcut that works as a side-effect of dns before you fully understood how DNS works.
That’s exactly what I want. I don’t know why you thought I wanted something else? I’m trying to reach services in my home network from home, using HTTPS, without requiring a local DNS or to load self-signed certificates.
EDIT: I realize I maybe could’ve made a better job at explaining that the intention was for it to work exclusively for me on my home network.
I know what you’re trying to do, and what those tutorials don’t tell you is that you are shortcutting normal DNS flow, which most apps are expecting.
DNS isn’t designed to work that way, so some apps (like Firefox) with internal hard-coded DNS functions are going to balk at private RFC ips in a DNS record. Or a lack of reverse record.
Again, slow down and think about what your trying to do here. You are complicating your stack for no reason other than you don’t want to set up a local DNS handler.
Thank you! This was the information I needed! It landed me on this page https://support.mozilla.org/en-US/kb/firefox-dns-over-https which shows
When DoH is enabled, Firefox by default directs DoH queries to DNS servers that are operated by a trusted partner, which has the ability to see users' queriesand lead me to this page https://wiki.mozilla.org/Trusted_Recursive_Resolver where I was able to read more about it. That explains why it does not work, I appreciate the insight!Glad you figured it out.
Yes, I now managed to make it fully work on firefox too, needed to set
network.trr.allow-rfc1918totruein theabout:configsettings! :)Does DoH stand for DNS over HTTPS in this case?
I’ve run into similar problems as you, and am now in the habit of adding my mydomain.TLD to the exceptions for DNS over HTTPS.
Yes it does. Are you using Firefox? And you can’t resolve local ip addresses, so that’s why you are setting this exception?
I am not a very good sysadmin. All I remember is the DoH feature was causing me problems in accessing my LAN servers.
I have it a little different than you: I have a halfbaked split-DNS system wherein nc.mydomain.TLD resolves to my public IP address in public DNS, and then on the LAN, the router and the pihole both have DNS entries saying that nc.mydomain.TLD points to 192.168.1.10 . I know I should just have one DNS provider for simplicity or do it better somehow, but I don’t want a single point of failure BC the raspberry pi has failed in the past.
That’s why I started out setting an exception in firefox. I’ve since put other LAN-only services on mydomain.tld, and I think I was having trouble resolving those too without the exception. But unlike you I don’t have private ips in public DNS, although AFAIK that’s a fine practice.
Interesting setup. Funnily, I have one specific subdomain hosted on an actual cloud provider, publicly and all other subdomains are private and local. It works just fine :)
In the end, there’s like a tradeoff between enjoying your system as is and pouring I don’t know how many hours in setting it up when it’s a new idea haha