Issues with internal vs external URL (DuckDNS)

can confirm, mine also working now.
also used nGinX, but also played with ports on switch, external I come in via 8124: mapped to 443 on the container that then goes to 8123 on host.
this then locally left 8123 open which then allows me normal http:// onto 8123 via internal address.

G

how about to us https with duckdns inside the mobile app is that working as well. I mean internal with local ip and external with duckdns.

For anyone who stumbles upon this old thread (as I did this morning) the process is now extremely easy and is in the documentation for the Add-On.

I struggled as did others at the time and the addition required in the add on documentation was the fix for me.

http:
use_x_forwarded_for: true
trusted_proxies:
- 172.30.33.0/24

I initially misread this and thought I’d need to put my own trusted local subnets in but this I imagine is the internal hassio addressing, notthing to do with your own home subnet(s).

Sorry if this has been answered somewhere else but I thought it may help some confused by the steps earlier in this thread.

1 Like

Just tried this, but unfortunately this does not work. Access via external URL (I use duckdns) does work, but when connecting via my internal WLAN I still get this certificate error.

So I think I have to try it with nginx.

Go for that… No regrets from my side.

1 Like

Yes the documentation I pasted above is for the NGINX addon. As well as removing the http url and certificate entries, you add the above to configuration.yaml

Once complete, you no longer port forward 443 to 8123 it’s pure 443 external and 8123 internally on http. My reason for implementing this was due to a recent loss of Internet meaning no access to HA internally. Now internal only devices interact with 8123 and mobile apps etc will automatically choose the correct URL based on whether the device is connected to known SSID or not.

1 Like