Hello,
I just start using Nabu Case for cloud connection.
When looking in the HA App i have the following settings:
HA URL:
https://nabucasa…
Internal URL:
was https://nabucasa.
Than all works fine.
But when i change it to the ‘real’ local url, https://homeassistant.local:8123.
The remote connection does not work anymore. i only can use it when connected to wifi?
Whan im a doing wrong?
I think that local address should be http, not https.
or configure NGINX (or set up hairpin nat on your router)
i have https and my own certs for local, or does this give a conflict?
I have to look that up, dont know wat this is yet 
http is indeed working,
but i would like to have local also in https, is that why i need to set up a ‘hairpin’?
I have a nabucasa and local cert so that I can use ssl on local network. I use for internal network https//my.domain/
did you set the extern url also?
i have the same, but can not connect extern if i set a local url on https…
I have remote nabucasa link, my local wifi ssid and local https link. That all.
Can you connect to your local https with comp? Not nabu casa
Edit:
Prioritize internal Url is disabled.
“Prioritize internal Url is disabled.”
Think this is the problem! when i disabled this it works.
But why, and how do i see now if it uses the Local when on Wi-Fi or still the extern?
I don’t know I never bother my self with that question. You can try disconnect wifi on your router.
Do you see how it’s says enable this is you leave location off on the device? That’s the only part you need to be concerned with otherwise you don’t need to enable it as the app already does the url switching. Let the app do it’s thing without using the override.
Also the app requires a valid certificate and on a local IP it will never be valid.
Yes it will. I use dynu dns to get a cert. It’s renewed every few months and it’s valid. I use it for local ssl, in adguard etc.
If the dyndns cert has the same URL as the address in the calling URL, DNS resolves properly and that Cert chains up to a trusted root cert that is accessible and trusted by the device you’re using, yes. In almost all home use cases one of those falls apart… Make sure that’s completely true.
I resolve my dynudns hostname using dns rewrite. I resolve it as my ha ip name. As I can’t use dynamic dns due my provider settings I found my self a small workaround.
I get it. Just realize certs complicate stuff. Everything can be perfect from a connection standpoint and if the certs are borked, no connection. I ran a split DNS at home with my own fully functional three tier CA with an offline root for 10 years. What you want is entirely possible, it’s also a massive PITA from a support and maintenance perspective and why I don’t do it anymore.
Considerations when troubleshooting.
(all things are name resolution issues until proven otherwise - especially with SSL and certs)
The URL reported by the cert MUST match the caller to be valid. This gets especially tricky when playing stupid DNS tricks…
Ask it this way
When my client calls server at myurl.com from external what is the path and what does the server report. Resolve DNS for that and every single URL up the chain when chasing Cert Revocation Lists (CRL).
This usually works because it’s what most people setup to hit. It’s the internal that gets weird.
Now I’m hitting the internal site.
Do I use a different URL? If so, how is whatever I’m using as my reverse proxy /ssl termination point responding there? Same cert? If it’s a different URL with the same cert you’re broken right there.
I expect that’s your case as you said DNS rewrite (I promise I only cringed a little)
If I use the same URL but different ip space can I resolve all the things i need to to properly chase CRL with the network and DNS im currently connected to. (pull the cert and try to resolve and connect to every URL you see - especially those listed. In fields labeled CRL.)
If.you then can resolve and see all the certificates in the chain, is it a well known trusted root thats already trusted by your device? If no did you manually install the trusted root?
Your DNS can be perfect and all of that still matters.
Now you got me. Gotta switch from my mobile to comp.
My provider is using NAT on their routers. I have external ip but the same ip is shared with a bunch of other people. Maybe the obvious solution would be to use NAT hairpinning. I never set this up and I believe I can’t do it with my routers.
So I set myself a hostname and get a cert for it. My hostname do resolve to my provider external ip address, but I can’t access my comp as its behind NAT.
I set up of course nginx ssl proxy. For server I use my dyundns hostname with ssl certs provided by them to resolve on my internal home assistant ip. If I got this setup explanation right.
To make this setup work I configured adguard dns to rewrite dnydns hostname on my ha ip address.
If I want resolve my dynudns hostname from net it will resolve but the only thing you will get is external ip address of my provider.
From the inside it will resolve this hostname as my ha ip.
Your question are maybe too much for my knowledge. I’m not an expert in this matters. I don’t have any formal education on computer science. I learned everything on line.
Edit:
I use in adguard encryption. For a server i use my dynudns host name and Certificate chain is valid as well as ECDSA private key.
I used to do the something similar, i assigned the domain to my local network (something my router can do), and made a dhcp reservation for the host name, hence the dns resolve’s locally.
The only downside was I had to use https://ha.domain.mine:8123 local, and external without the 8123.
I enabled hairpin nat now, so no need to specify the port anymore
I don’t have this downsides. I can access it on https://mydomain/ and from http://homeassistant.local:8123/
But I believe I set up my host file right.
Ah, but then your SSL certificate must be on nabucasa.
I don’t have nabucasa, but I still use https:
The SSL certificate resides on my HA server local, and therefore http usage on 8123 is not possible, it can only use https (and therefore the dns must resolve to the address used for the SSL certificate)
So my only solutions are
Butt as you said:
This would never work for you, as you can’t use port forwarding…
By the sound of it (AdGuard, NGINX), you quite over complicated things, unless you have a lot of guests on you local network, using https is not required at all…and due to being behind your isp’s nat, you can’t access HA from outside anyway (except using nabucasa. which is basically the opposite….it is HA contacting Nabucasa, and not the other way around)