Can't connect to Home Assistant from external via https, Synology reverse proxy

I have 2 ideas.

=== route #1 ===

Does this “to Synology” mean… to Synology management (DSM) port, or to the port of the reverse proxy server on Synology?

Could you share the setup screen in pi-hole?

Is this “port” the port for pi-hole, or the port for nas?
Could you show us your reverse proxy setup screen from Synology?
If you setup another reverse proxy of nas.mydomain.com:443 https, to http://192.168.1.153:(your DSM port), would that work when you access from outside?

It’s fine. For a reverse proxy setup, you could point that to http://192.168.1.154:8123, no ssl cert is needed.

This statement need to be checked. When you do use that ha.mydomain.com from LAN, it goes to pihole for dns lookup, and then with the local dns rule you set, you’d go directly to 192.168.1.154. This does not go through reverse proxy.

=== route #2 ===

I am actually thinking about the same thing.
Given you have HAOS, and you and do add-ons easily, then you can look into this add-on:
New Add-On: Cloudflared - Share your Projects! - Home Assistant Community (home-assistant.io)
I setup mine in 30 minutes. Including the time to register my account and domain name.
And the best part is that you don’t even need to open any port on your router.

Well… both, actually. When you enter “yourdomain.synology.me” it takes you to DSM main page, but if you enter anything else before your domain, like “ha.yourdomain.synology.me” it takes you to defined web page (defined via proxy manager).
I defined my setup like THIS and everything works.

@k8gg - Maybe you wouldn’t recommend this, but I ran in to the same issues. Installed deb 11 supervised in no time and had HA running in even less. But if you guys want to continue messing about, by all means do so :wink:
The fact that he has pi-hole running behind the reverse proxy proves that it works. So it has to do something with HA. But as it is a fairly closed OS its hard to analyse.

Well router forwards 443 to Synology 192.168.1.153:443
There nas does its stuff.
So ph.mydomain.com reverse proxys to my internal access to pihole 192.168.1.153:port
All it does is take http and make it https

ha.mydomain.com reverse proxys to 192.168.1.154:8123
but it needed all those other websockets and proxy config

Now I guess your point about pihole is interesting. Because my Local DNS Records point to 192.168.1.153. Then ha.mydomain.com is a cname to the nas name.

So internally ha.mydomain.com → 192.168.1.153 so it does hit the reverse proxy.

Externally I guess ha.mydomain.com is a cname to duckdns. So it would be my ip:443, which goes to 192.168.1.153:443 → reverse proxy

But main thing, why internally is desktop differnt from mobile (both chrome)?
Mobile redirs me to /lovelace. Then has the fail/retry screen.

My setup is the same as yours. Not sure why I can only access internal on desktop.

Even internal on mobile fails?!

I’ve installed and set up
New Add-On: Cloudflared - Share your Projects! - Home Assistant Community (home-assistant.io)

I think. I got
INFO: Finished setting-up the Cloudflare tunnel

I’m not sure how to check.

Then a few errors, then 4

 INF Connection ______ registered connIndex=3 ip=198.41.192.27 location=BNE

I guess those are CF ips.

I can still access internally. Mobile still doesn’t work. Is it something to do with HA having a different IP to the nas?

I still don’t get the desktop vs mobile chrome difference.

I was going to mention that you had ‘cloudflare’ mentioned. and it seemed like you were getting slowness rather than not seeing HA at all. IF that is correct, I had the same symptom and simply disabling caching in cloudflare fixed it completely.

I don’t use the cloudflared addon (didnt want to have to rely on an addon for this) and rather just use a proxy setup. But in my setup you need to whitelist the cloudflare IPs too. I don’t see where you did that?

This all may be moot now that you installed cloudflared though.

In synology–>virtual machine manager, select your HA instance and under “general” check which IP’s are there… i have two of them starting with 172, so i entered in configuration this:

http: # ------------------------------------------------------------------------ HTTP
  ip_ban_enabled: true
  login_attempts_threshold: 10
  use_x_forwarded_for: true
  trusted_proxies:
    - 192.168.0.0/24
    - 172.30.32.0/24
    - 172.17.0.0/24

also: did you try to turn off pihole and try to access? Just to definitely eliminate pihole’s fault…

  • Post the entire log from Cloudflared please. Hard to know what “a few errors” are.
  • Also what do you see from the Cloudflared dashboard?
  • Did you follow the instructions to authenticate at Cloudflare, using the link from the log?
  • Did you add 172.30.33.0/24 to the http section of your HA config?
  • Also did you follow instructions to remove / disable SSL certs? After Cloudflared add-on setup, the certifications of your domain name would be done by Cloudflared. Meaning no LetsEncrypt, no DuckDns, no Synology handling domain certification nor any other reverse proxy setup outside of Cloudflare, within your LAN network.

====

I would second this. Remove pihole from the equation, roll back DNS settings temporarily.

====
And, again,

I’m using

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - 10.0.0.0/8
    - 172.16.0.0/12
    - 192.168.0.0/16

So that covers 172.30.33.0/24 and more
Anyway when that was empty, I’d get a ERR400 rather than the HA screen

So the addon, I went with the local config, followed it fine under

Initial Add-on Setup for local tunnels

It all worked. This was the log. I’m sure the last lines show it’s working.

2022-08-30T14:04:24Z ERR Failed to serve quic connection error="Unauthorized: Failed to get tunnel" connIndex=0 ip=198.41.200.33
2022-08-30T14:04:24Z ERR Register tunnel error from server side error="Unauthorized: Failed to get tunnel" connIndex=0 ip=198.41.200.33
2022-08-30T14:04:24Z INF Retrying connection in up to 2s seconds connIndex=0 ip=198.41.200.33
2022-08-30T14:04:26Z INF Connection 45d6bc44-4ff0-451c-920f-4291cb776024 registered connIndex=0 ip=198.41.200.33 location=SYD
2022-08-30T14:04:28Z INF Connection 9e37d67f-d134-4ebd-887d-d49f1740aceb registered connIndex=2 ip=198.41.200.73 location=SYD
2022-08-30T14:04:28Z INF Connection 6d5a8e07-3c0e-468e-93c7-074a280602a3 registered connIndex=1 ip=198.41.192.77 location=BNE
2022-08-30T14:04:30Z INF Connection 468b3e19-bd7e-4b7e-afc3-12c7bd4ba1ef registered connIndex=3 ip=198.41.192.27 location=BNE
2022-08-30T23:54:58Z INF Unregistered tunnel connection connIndex=2

The instructions to remove / disable SSL cert refers to on the HA, I don’t have any related addons in HA.

The tunnel would bypass the reverse proxy on synology anyway right?


image

Anyway, I disabled pihole, which was simply taking it out of deco’s dns.

Let me restart everything and try it out.


So I restared HA via the menu. Then rebooted my phone. Hooked my laptop to my phone hotspot.

Results:
phone - retry screen
laptop - retry screen

Actually worse than before.

Unless is there any other action I need to do each time I change these settings?

Maybe I do the final route, forward router 8123 → 192.168.1.154:8123
I’d need ssl addon in HA

If that doesn’t work then I’d need to see how to backup then install debian in a VM.

Tried router 8123 → 192.168.1.154:8123
Le’ts encrypt ssl addon in HA. But I couldn’t get it working

Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.

So I don’t think that’s an option then.

Another thought, in cloudflare should I have dns cname as proxied? Should it matter?

i created a post yesterday (Link) and your issue seems like the same issue i have.
the setup was working for almost 3 years now, i changed nothing and it suddenly stopped working.

I also use cloudflare and a reverse proxy, all my other services (9 in total) are working fine except Home Assistant.

strange…

i use HA behind synology reverse proxy too, however i do not use the external 443 port, but 55xx range. Did you try moving to other port for HA in your case?
And then i mean both external port as receiving port on synology and synology forwarding to 8123 to ha host.
And update external url including the new port number in HA config

If that would work then it’s only a port conflict somewhere which can be investigated separately ofcourse

Did you by any chance enter anything from THIS site in config file? When i played with that i almost locked myself out, so i don’t use anything but default.

@Protoncek I am not using Authentication Providers

But firstly, I wonder what [homeassistant.components.http.ban] means. I haven’t been getting these in my logs since the 1st day. Does that mean the ban sticks, and my errors are actually leftover from the 1st day before adding trusted_proxies?

How to clear ban list? suggests I don’t have a ip_bans.yaml file so it’s not the case.


After all that stuff, I’ve basically exhausted all options. Then I remembered I have multipl ext urls to use, so I can set them up differently.

I’ll use shortnames now:
myurl = ha.mydomain.com
ddns = me.duckdns.org
nas = 192.168.1.153 - synology instance
haos = 192.168.1.154 - vm on nas

I installed Duck DNS on HA again. Set up my DuckDNS.org domain. (currently unused). It’s time to do a reset/check. I have

  • Cloudflared off
  • cloudflare subdomains reset to cnames on ddns
  • pihole back on - otherwise my local links to nas etc are broken
  • pihole local is cname myurl = ddns (ie nas)
  • router 80/443 → nas
  • 8123 → haos:8123
  • on HA, Le’ts encrypt off, Duck DNS on

On synology reverse proxy I have

  • myurl:443 → haos:8123
  • ddns:8123 → haos:8123

I noticed when I forgot to put the myurl:443 → haos:8123 back on, I would get the retry screen

Unable to connect to Home Assistant.
Retrying in 15 seconds…


Internally:
Now if I access https://myurl it is fine (going thru pihole → reverse proxy)
https://ddns or https://ddns:443 redirects to ddns:50xx nas login (where’s this from?)
https://ddns:8123 takes me to HA login, I can login (going thru pihole → reverse proxy)

https://nas:8123 gives me

400 Bad Request

The plain HTTP request was sent to HTTPS portnginx
I guess this is expected, no reverse proxy entry for this

Externally:
https://myurl seems to work
https://ddns:8123 seems to work
https://nas:8123 times out

Does that initially seem like I’m good now?
The difference is then the Duck DNS addon. Why does that help the reverse proxy work, which isn’t even related to it?

FYI I had Duck DNS added to Synology’s ddns option as a custom provider. It worked and the Duck DNS site showed my ip.

Did further test.
Disabled Duck DNS addon
Reboot router (changes IP)
Update ddns on synology
Restart HA

All still seems to work. The only difference from when nothing worked is that Duck DNS addon
is installed - but disabled.

What does this mean?

Looks like you are good to go.

The purpose of the Duckdns add-on is to handle certifications.
Now that it is your synology box doing reverse proxy and thus handling certificates for 2 urls, you likely would not need the add-on on HAOS.

Next is to monitor the situation, run further tests on various scenarios, and maybe think about simplifying your setup / reducing attack surfaces.
I say this mainly because, (while I don’t know what you want,) you likely don’t “need” both myurl and ddns in place, and you likely don’t “need” to open port 8123 on your router - if/when the reverse proxy setup on your nas box works.

Thanks, though we still don’t know why it wasn’t working initially. I’m basically back to the same as how I started.

I took off open port 8123. Still good. Next is to delete Duckdns add-on (now disabled).

I now have myurl = ddns = syndns. 3 domains pointing to my ip. Does it matter? Security is https and long password right?

So I have rebooted my VM.
Now I again cannot access from outside. Same as before,
ph.mydomain.com working
ha.mydomain.com broken

Internally I can access via wired desktop but not mobile phone browser

Reinstall duckdns on ha, rebooted ha. Still the same.

Mobile can use internal ip, without https

One thing changed is I installed web station, because my public ip automatically redirected to my secret DSM port.

I stopped the service to see if it changed, but still not working.