I need to be able to access HA via the DuckDNS domain on my phone when I’m away, but in the house the internet goes out quite frequently so I need to access it via the local ip (192.168.100.10) as well (otherwise no internet, no HA, which is bad).
I setup DuckDNS and now I can access https://XXXX.duckdns.org:8123 but I couldn’t reach 192.168.100.10 with either http or https, with or without :8123. Alright, time for NGINX Home Assistant SSL proxy (according to a half-dozen sites I consulted for this prior to posting here). I setup the addon and added the required lines to my configuration.yaml (adding a few additional trusted_proxies because I don’t actually know what’s going on and I’ve been trying to debug this for days):
http:
use_x_forwarded_for: true
trusted_proxies:
- 172.30.33.0/24
- 192.168.100.10 # the HA machine
- 127.0.0.1
- ::1
- 192.168.3.1 # router
The result: 192.168.100.10: I can’t access https:// with or without :8123. I can access http:// only with :8123. XXXX.duckdns.org: I can’t access https:// with or without :8123. With :8123 fails the wss connection, without gets intercepted by the modem (192.168.2.1) for some reason. I can access via http:// with :8123 only, like with the internal IP.
So going that route only allows http, so that’s not great either.
192.168.100.10 and 192.168.3.1 are different networks. (Assuming your mask is the default 255.255.255.0).
Why are your router and Home Assistant on different networks?
And what is “modem (192.168.2.1)”- yet another network?? I am surprised that anything works.
You cannot use https on a local server. (If there is a way to add SSL to your local network, I haven’t heard of it).
Without understanding why you have three different local networks, I would only be guessing where to begin.
Please draw a picture of how things are connected.
Why wouldn’t they work? They’re configured to communicate with each other via the EdgeMAX router.
.2.1 - modem
.3.1 - router
.20.0/24 - HA devices with internet connection (chromecast)
.30.0/24 - HA devices with no internet connection (printer, vacuum)
.100.0/24 - Trusted devices with unfettered access (my PC, HA box, phone)
You cannot use https on a local server.
I’d prefer HTTPS only on the duckdns domain and HTTP for the local server, but at present I can only use one or the other, which is the problem.
Seem to be getting off topic, but it’s to manage security of my connected devices. I control communication between the groups and the internet to, for example, disallow my chromecast from knowing other devices on the network, or to prevent my robot vacuum from sending photos and telemetry back to China. I can setup these groups (Unrestricted, IoT, NoT) and stick dozens of devices into them and then manage communications at the subnet level instead of per-ip. It works really well, but perhaps something internal to these addons maybe doesn’t like it.
Sometimes the ONT is called a MODEM, but ONT is the proper term.
If that helps you figure out how to fix up my HA to allow both types of access, great! Let’s call it an ONT. Sorry if “modem” confused you.
First of all, ignore this other guy giving you poor advice from up on his high horse.
You can ABSOLUTELY use ssl on an internal network - I’ve seen me do it, AND I’ve installed proper multi-level PKI infrastructures on private networks professionally for over a decade. Offline roots, issuing subordinates, the works. Nevermind him.
Further, it doesn’t matter if you have 5 networks or 50 networks, it can work just fine as long as you’ve got your routing sorted.
Now that we have that load of nonsense out of the way - the only thing he said that flirted with correct is that what you’re doing is unnecessarily complex. Except - he was unable to correctly identify what part of it is unnecessarily complex. It’s not the networks, that’s fine. For the record, my network is divided up very similarly to yours, in that my iot devices are not allowed internet access either. There’s no good reason for them to.
NOW - yours is the second post in as many days to be attempting to use nginx to solve a simple problem in the most complicated way possible. I have no idea what websites are offering this advice, but I wish they’d stop. Lol
If the goal is to be able to access HA using ssl from inside the network without relying on the internet to do so, the answer is not to hairpin your firewall (thats bad, by the way) and use some complex proxy service.
What you need is an internal dns server with an A record that resolves your external duckdns FQDN to the internal ip of your hone assistant server. Problem solved.
I wish I could figure out the string that all these people are typing into Google to land on all these crazy, overly complicated blog articles. I’d use that same string as an SEO keyword on my YouTube channel and make a video clearly explaining the whole topic for them. DNS, how it works, how SSL works, all of it. Lol
Accessing internal services from the LAN through the WAN IP (NAT hairpinning) is done transparently by all SOHO routers. If there’s a specific reason not to go through the WAN IP (in the OP’s case, because that link tends to go down), then the solution is what exx says. Simply use an internal DNS server mapping the public domain name to the internal IP. This is commonly called split DNS. I’ve been doing this forever.
However, this tends to cause glitches in DNS resolution for the companion app when the phone switches between cellular and home WiFi. Sometimes the DNS cache doesn’t update and I have to force close the app it or even reboot the phone.
Sounds to me like it’s time for you to get a new phone. When you switch connections - from wifi to cellular data in this case, you are using a different source address, different gateway, different dns servers, different everything. DNS lookup information does not persist across connection state changes.
I have been using HA in this configuration with numerous mobile devices now for over 18 months and have never once had to reboot my phone or force close the app due to anything remotely resembling the issue you describe. That is not normal or expected behavior, and you should look to remedy it, rather than try to warn someone off the correct solution because of an issue unique to you.
As to whether or not soho firewalls are capable of hairpinning is irrelevant. It is a horrible practice from a network standpoint and should never be allowed in any properly designed network that was configured by anyone with even a modicum of professional understanding.
The DNS cache is not necessarily cleared on interface state change. What dictates the duration of a cached DNS record is the record’s TTL.
The OP may or may not face the issue. But he is better informed by knowing about it. The fact that you’ve never heard about it doesn’t mean it cannot be talked about.
Yes, hairpinning is not a best security practice, neither is UPnP and many other services. Still people have a use for them. It’s up to them where to stand on the balance between security and convenience.
“homeassistant local ip and duckdns” and I found a half dozen sites saying that using that specific NGINX plugin was the solution.
What you need is an internal dns server with an A record that resolves your external duckdns FQDN to the internal ip of your hone assistant server.
I’ll start researching this today, but if there’s a standard setup or something that you could point me to, I’d appreciate it. EDIT: Actually I found this guide for my router (https://help.ui.com/hc/en-us/articles/115010913367-EdgeRouter-DNS-Forwarding-Setup-and-Options) and I setup a DNS forwarding option address=/XXXX.duckdns.org/192.168.100.10 and it worked just like you said. I think my issue is resolved! Thank you!
You’re sort of right. TTL controls when the record dies, but the interface determines where that record is cached Multihomed systems (such as a cell phone) have more than one cache. I may have simplified for the sake of brevity since I was typing on my cell phone. And your phone is still broken.
You have multiple interfaces. One is private (your LAN), and the other is essentially public (your provider’s data network). The two interfaces have different DNS servers, and different DNS caches. They do not share the same DNS cache. If they did, then you would run the risk of internal DNS records being leaked to the public network. DNS leaks are bad, and have security implications.
So again, I say unto you - get your phone fixed, because anyone running a modern, proper OS should not suffer from that problem.
As for hairpinning (at least we agree there) - the problem is that I’m sure better than 99% of SOHO users that enable that type of shenanigans don’t even know why they are doing so - they just found a blog article somewhere that told them to. That is dangerous. I choose not to perpetuate such nonsense, that’s all. I think that if people are going to do something that has security implications, it should be laid out to them in clear and concise language so they can make an informed decision, not just “click this and stuff will work”.
Come off it. You know what you did, and you really don’t want me going into detail in public scolding you like a small child that is behaving poorly in a restaurant, do you? Just let it go and do better next time.
EDIT: Actually I found this guide for my router (
