It works, thank you so much
1 Like
I’m curious why the need to add internal http access? Are you using a particular integration that requires it?
I already experienced a few times when DuckDNS was offline and I don’t want to loose access just because of this. And I think it is actually one of the reasons why Home Assistant is so cool. Let me quote from the frontpage of home-assistant.io:
Home Assistant keeps your data local, no need for a cloud.
Home Assistant communicates with your devices locally, and will fallback to pulling in data from the cloud if there is no other option. No data is stored in the cloud, and everything is processed locally.
I don’t want to loose that
Just to be clear, you want http access externally, or only internally?
Only internally, of course
OK, this is an easy fix. Rather than enabling http, just make it so you aren’t relying on duckdns for name resolution. Then you can access it locally via https without relying on the cloud.
Install a local dns server. There is one you can run on HA. Then, just make an A record for your home assistant server so you can resolve the duckdns domain name to your internal ip. This is better anyway since then you aren’t hairpinning your firewall by contacting the external ip just to get at it.
I made a video that included how to do this. Jump to 4:50. Super easy, the entire relevant part of the video is only 45 seconds long.
Then you just use the ip address of your home assistant server for the dns server in your dhcp scope, and Bob’s your uncle.
I prefer this method since then the internal and external url in the companion app are the same. Less confusing that way, and no more messages about “unable to contact external url” “wait” “retry” and all that nonsense.
Lastly, ignore the crazy intro about cooking & boating & nonsense. This was a pretty early video when I was all over the place. The channel only focuses on smart home stuff now, primarily home assistant.
Hope this helps,
Jeff
Sounds a lot more complex but to be honest, I already got into the problem of not being able to contact using the companion app. I think, I only have access using the internal IP using LAN and not Wifi. For now, I’d prefer to use this method since I just got it running (well, most of it)
I’m glad you found a solution you are happy with, but I’m not sure why you think this is complex.
DNS is a pretty core principal of tcp/ip networking, and the ability to override public dns to keep your traffic internal is very useful - for a lot more things than just HA.
Do I understand correctly? What I would have to do is:
- Add cert files back to configuration.yaml and remove trusted proxies
- Disable NGINX add-on
- Install dnsmasq Add-on
- Add duckdns domain and internal IP to dnsmasq config
- Set router port forwarding back to forward 443 external to 8132 internal
and that’s it?
Thanks for the help. I think I did everything, but I can connect to my HA anymore. I’m doubting about the value for “trusted_proxies”. I have 192.168.1.0/24. Can that be correct for me?
Another problem could be that my port 443 is already forwarding to my Synology. So I changed the value in all the places (NGINX config and my router) to 444.
Any ideas?
Since you’ve already got nginx installed and changed your firewall rules, that does add a handful of additional steps.
The only step it looks like you are missing is to configure your devices to use your home assistant ip for dns, via dnsmasq. If everything is dhcp, that’s easy - just make the change to your dns scope and restart your devices. Then any device on your network would resolve myhomeassistant.duckdns.org to your local, internal ip address instead of going out to the internet to resolve it to your public address. Any dns lookup requested by a client that does not have a matching record in dnsmasq would be forwarded to the internet for resolution, same as normal. This allows you to continue using https - internally, as well as externally. I’m a big fan of making things more secure, so https internally is obviously a step in the right direction in my mind.
OH - as for the port number, I left mine 8123. Like I said, that way the internal and external url are the same. But if you want 443 externally and 8123 internally, you can certainly do it that way, sure.
The step about dnsmasq wasn’t in the instructions, so I didnt do that. But for now I’ve rolled back the changes until I figure out how to do this. I’m not good with networking.
That’s two different ways to do it, you didn’t follow his instructions but the one’s by EwardTFN. No need for dnsmasq for this way of doing it
The trusted_proxies value is correct. Your problem is probably with your port forwarding
1 Like
Oh, I understand. I think my setup would even be more complex, since I am already using Pi-Hole (on a different device) as a local DNS server
Actually, it would be easier. You could just add an A record for your local ip of home assistant to your pi hole, no need for dnsmasq.
Do you have any idea why I can connect using my desktop PC (using both Ethernet and Wifi) but not my smartphone (neither any browser nor companion app)?
My idea is that this is maybe due to a different Wifi network (I have both 5 Ghz and 2,4 Ghz running). How could I solve this?
Oh, great. So I would do this to my current configuration:
- Add cert files back to configuration.yaml and remove trusted proxies
- Disable NGINX add-on
- Add A record to pi-hole
- Set router port forwarding back to forward 443 external to 8132 internal
Are you talking about difficulty connecting via https? I had that problem too, initially. It had to do with the type of certificate being used not being supported by the browser on my phone.
However, since you also don’t have proper name resolution configured, you may also be getting a certificate error if you’re trying to access it via ip instead of by name. Some mobile phones won’t allow that to happen, either.
Id set up name resolution first, and see if the problem persists. If it does, then the issue is likely the certificate type.
Take a look at that same video, but a but earlier. Maybe around the 3:30 mark or something I think? It’s during the duckdns config where you configure the encryption. Set it to the same value I did in the video.
If, on the other hand, you are not talking about https, and are instead talking about just being unable to access it at all, that’s likely a routing issue.