My instance is accessible through https using a DuckDNS domain. I don’t want to change that, as I also Google Assistant configurated using that domain.
How can I add access using http and my local IP without losing access to my instance?
I know that I have to use a reverse proxy but all my attempts using NGINX Proxy Manager or the NGINX add-on always resulted in my losing access to my instance and having to reinstall + restoring a back-up.
Is there a step-by-step tutorial for this? Everything I’ve found was for a fresh install and not a running setup using DuckDNS add-on (as my certificates are already created using this).
When you are using NGINX your settings have to be different, otherwise you can have trouble accessing.
We have another discussion running on this post, but I will come back with more comments here:
If you have https://yourdomain.duckdns.org/ working, that means you already have the certificate files and your http session on the configuration.yaml has references to those files, right?
In order to work with NGINX, you will have to do the following:
- Install NGINX and set it to start with Home Assistant
- Comment out the cert files on
httpsession of yourconfiguration.yaml, like this:
http:
#ssl_certificate: /ssl/fullchain.pem
#ssl_key: /ssl/privkey.pem
ip_ban_enabled: true
login_attempts_threshold: 5
use_x_forwarded_for: true
trusted_proxies:
- 172.30.33.0/24
- Add the trusted proxy to your
httpsession, as per my example above (you can use the same values) - Restart Home Assistant
- While HA is restarting, set your router to forward external port 443 to internal port 443 on the Home Assistant IP address.
Done! You should be good to go.
3 Likes
Thank you so much, very concise instruction. I think I tried all of this but never added another port forwading. I’ll try this out.
(Yes to your first question, btw)
One more question, just to be sure. You meant “NGINX Home Assistant SSL proxy”, right? Not the proxy manager
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