I have duckdns set-up and working just fine. My duckdns domain (e.g. ABC123.duckdns.org:1234) works beautifully both on mobile and desktop. As long as I am connected to the internet (obviously).
Now: I have set up a static IP for my HA (e.g. 1234); this is not the problem.
I would like to be able to access HA from within my network locally. To do so, I set my static (internal) IP as the “internal IP” within HA. So far, so good. This also works with the desktop login (e.g. via Chrome on a laptop). However, when I use that IP + port to access HA through the Android app, this does not work.
I have listed my SSIDs within HA, so that shouldn’t be the problem.
When you say “works” here, do you mean it actually works? Or do you mean when you first go to it you see a nasty warning about how the SSL certificate doesn’t match and you clicked “proceed at your own risk” to get past it? Because the latter isn’t working, that’s an SSL error and you can’t choose to ignore it on mobile.
I have a similar question. If you have DuckDNS setup with SSL cert, how do we make sure everything works in case the internet goes down? One example would be an automation based on an Android alarm. How can we be sure that it will still work if the internet is down? Removing the requirement of having a connection for my smart functionalities to work is one of the things that attracted me to HA away from SmartThings.
If you are on a container or core install then same thing applies except you won’t be able to use the addon I suggested as a reverse proxy, you’ll need to install and configure a different one on your network.
EDIT: I guess I forgot this step from the addon’s docs:
And you need to add the trusted_proxies section (requests from reverse proxies will be blocked if these options are not set).
This may be the issue I had. Sorry - I didn’t get any notifications about replies to my question and forgot about it but that may have been the issue. Thanks!
So your config looks right so lets check a few things:
You should have port 443 on your router forwarded to 443 of the HA device, nothing else. NGinx SSL proxy should be listening on port 443. Leave HA on port 8123 like normal (but don’t forward anything to that port).
When you go to the URL you are just entering https://<your subdomain>.duckdns.org right? Not https://<your subdomain>.duckdns.org:8123? The latter is no longer correct and won’t work anymore.
What do you actually see when you visit https://<your subdomain>.duckdns.org in a browser? Any messages or codes on the screen? Please share if there are.
Is there anything in the logs of NGinx SSL proxy after you try to go to that URL? Or in the logs of HA? Which one is logging an error helps us determine how far the request is making it and where the error is.
If neither of those things has a log about it then something is going wrong before that. Check duckdns to ensure your IP address is correct.
If duckdns is correct then take a look at the certificate to ensure that looks correct. You can do this by entering this command after SSH’ing: openssl x509 -in /ssl/fullchain.pem -text -noout. This dumps out a lot of info but you’re basically just looking at the “Common Name” (CN) to see that it matches your duckdns URL and that the expiration date is not in the past.
Also not sure how you’ve been testing this but get it working in a browser first. Browsers are a lot more informative then the mobile app when it comes to errors. Once its working in a browser then try the mobile app.
In a mobile browser I simply get directed to the log-in screen (so it’s working as it should)
Nothing (!) in the NGinx log. I also don’t see an error related to the HA mobile app in the HA main log. The only error I see there is something about an Alexa integration.
I went to duckdns and “updated” the IP, though the IP entered there was the same before and after.
CN is correct.
So yeah, when I go out of my home network and enter HA through a mobile browser it works. However, with mobile data (not local WIFI) and mobile app = no luck.
On my desctop browser I can access HA both using my local IP and using my DuckDNS adress.
To clarify here, does works still mean you had to ignore a certificate error? Like if you look in the URL bar at the top of the mobile browser, is there a warning indicator on the lock icon that when you click it says something along the lines of “Connection not secure”? Or is the lock icon all good and clicking on it shows “Connection secure”?
lock item is there and all seems good.
at this point it’s really just the HA Android App that won’t access HA when I connect to it through mobile data (=outside my home).
Even the google home integration (through YAML and using the google console.action page) works when accessing from outside my home network (as well as inside it).
If you are able to use the app in one connection method, then the issue is that your other connection method needs to be adjusted and there is no issue with the app. There will also definitely be a Companion App error in the logs showing the cause of the connection failure. The app makes no distinction between connections, it either works or doesnt and if it works for one connection then that means the other connection is what needs to be fixed.
I see you are testing things with a proxy. The easiest way to rule out an issue with the app is to completely bypass any proxy or SSL certificate and do a straight connection. If it works then you need to fix your network setup, which it seems others have been trying to help you with as I can see above.
Are you sure the app is using https://<subdomain>.duckdns.org and not https://<subdomain>.duckdns.org:8123? That’s what you used to use right, did you make that adjustment? Also did you change the External URL in HA? I forget if the app looks at that.
The first line is the external adress (https://example.duckdns.org)
Then come my internal SSIDs
And then comes the internal IP adress (http://192. … :8123)
If I’m understanding the system correctly, when I’m in one of my private SSIDs (TV2 / TV5) it should default to my internal IP for HA, but if I am not in one of those networks, then it should default to the external adress.
by keeping “prioritize internal” enabled it will always try the internal address first regardless of you being on the home network…try turning that off…the feature should really only be used if you typically keep Location off on the device.
but that may have been the issue. Thanks!
