This might be an overkill solution to this problem, but my router does NOT allow NAT loopback, so I had to find alternatives.
I already had NGINX reverse proxy set up, and all my HTTPS stuff is set up there. So facing the internet, I just have my NGINX proxy listening on port 443, and forwarding traffic to my internal HA instance, unencrypted on port 8123. My Home Assistant itself knows nothing about HTTPS, but it is not directly exposed to the internet.
Then, I have my http: section’s base_url as my public duckdns domain name, so that webhooks from the internet can work.
http:
base_url: yourmom.duckdns.org
Finally, in the TTS section of my config I have my internal, HTTP (not HTTPS) address for HA in the base_url property:
# Text to speech
tts:
- platform: google
base_url: http://192.168.x.x:8123
This means that my Google Homes, or whatever is trying to play the TTS URLs will go to the internal HTTP site instead of not being able to hit my public duckdns URL.
No. Leave the duckDNS + let’s encrypt as it is… that will sort out the SSL certificate for you, and update the duckDNS ip address,
BUT
Install NGINX as well and remove ssl and certificate from the http: section of your config
You might not need to if you’re using the custom component… I haven’t tried it, so can’t say, but you definitely do have to be either over an unencrypted local ip address or have a router that supports loopback.
Using NGINX allows unencrypted internal connections to hassio via ip address, while keeping ssl for external traffic
This is the correct way to fix the issue. Nothing else needs to be done. Insert the base_url with the LAN IP (change to https if you’re using SSL internally) of HomeAssistant.
Correct. If my router supported loopback, I probably wouldn’t need NGINX.
However, I like that NGINX keeps the SSL business separate from Home Assistant.
If you have https://.... and ssl certificates in your http: section of config, all access to home Assistant is forced to use ssl.
If you’re using https and your router does not support NAT loopback, Google will Not be able to access the address if you use the duckDNS address OR not be able to validate the certificate if using the IP address.
You only need to go the NGINX route if your router does not support NAT loopback… AND you want external ssl
So, since I access HA from outside only via VPN (I don’t like ports to be opened to the outside!), NGINX is not needed, right?
My other question is, when I connect thru VPN and HA does not have SSL active, the traffic to the internet is encrypted because of the VPN or is clear?
You can leave ssl off completely (no https:// or ssl certificates in the http: section), leaving home assistant unencrypted. as your VPN secures the connection. Then just use http://IP_ADDRESS:8123 in the tts config
Hi! I have a problem related to this.
I had a working configuration with google tts which stopped working after configuring remote access using duckdns. My router does not allow Nat loopback, so google tts in google home mini was not working.
I have installed NginX, configured my domain from duckdns, removed key certs from http in configuration.yaml and added the local http ip to base_url in tts in configuration.yaml.
After reboot tts was finally working from UI. But now I cannot access to Home Assistant using my remote duckdns domain.
Thanks for the prompt response. Now I can remotely access to my system and play tts. However I have some questions
I have opened the port 443. But I could not open port 80, I think is blocked or something because im not allowed to include the rule into the router. What is port 80 for? Yet, I’m able to open HA UI using port 8123 when in lan, I don’t really understand it very well.
Since port 8123 is no longer open, now I have to use https://mydomain.duckdns.org:443 is that right? I realized that google assistant integration was not properly working. After modifying the port I can use it again.