Installation on Docker with Reverse Proxy (Synology) allows log in but disconnects immediately

Installation
, ,
1

I’m trying to set up Home Assistant 0.114.3 in Docker for remote access via a reverse proxy, and am failing to be able to log in - or I think I’m logging in but failing to maintain a connection: I enter username and password, and get kicked back out to a “RETRY” screen, but a login token is created for each attempt.

I don’t think I’m an idiot, but I might be over my head.

My detailed situation is:

  • A have a Synology Diskstation (192.168.86.37) and a separate Ubuntu box (192.168.86.99); I’m using the reverse proxy and SSL certificate services on the Diskstation and Docker on the Ubuntu box. I’ve done this before with other programs.
  • I’ve registered a domain, TimTLD.com, and a dynamic DNS account, Tim.myDS.me.
  • I added a “CNAME” record to my DNS, Name ha[.TimTLD.com] and Hostname Tim.myDS.me.
  • My Verizon G3100 router forwards ports 80 and 443 (and a few others including 8123) to my Google WiFi, which forwards them to my Diskstation.
  • On the Diskstation I’ve added a reverse proxy, Source HTTPS ha.TimTLD.com port 443, Destination 192.168.86.99 port 8123
  • On my Diskstation I’ve added a Let’s Encrypt certificate and associated it with ha.TimTLD.com.
  • Note: If I change the reverse proxy destination port to a different one, associated with a different Docker (Bitwarden), it works perfectly - so I think the configuration to this point is working.
  • On my home network, connecting to Home Assistant on 192.168.86.99:8123 works perfectly.
  • Connecting to https://ha.TimTLD.com gives me a normal-looking login screen with “You’re about to give https://ha.TimTLD.com/ access to your Home Assistant instance.”
  • It (apparently) allows me to log in because a Refresh Token is created (“Refresh token for https://ha.TimTLD.com/”) - but I’m instantly kicked back out to a “RETRY” screen. (I have to log in with the IP address to see the Refresh Token.)

I’ve tried setting the logger default to debug and scanning the wealth of information that produces, but without knowing what to grep for it’s difficult. It seems as if the local IP login and the DNS login look similar, but the local IP login proceeds to a homeassistant.components.websocket_api.http.connection step that doesn’t happen with the remote login, specifically:

The successful local IP login/connection:

2020-09-10 10:14:26 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/login_flow/52b663c3ec1d47dfbd2ca7593cbaca2b to 192.168.86.238 (auth: False)
2020-09-10 10:14:27 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.140127263332384] Sending {'id': 3, 'type': 'result', 'success': True, 'result': [lots of stuff]

The failed remote login/connection:

2020-09-10 10:13:07 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/login_flow/457066aeedc348cd894f58b7b5433d51 to 192.168.86.37 (auth: False)

I’ve tried various things with external_url and cors_allowed_origins and even ssl_certificate/key, but none of them seem to change anything.

Any ideas?

Thank you!
Tim

2

Post your proxy setup

I was guessing websocket issue but I don’t understand websockets enough to know how to troubleshoot.

I do know(or I think I do) that your proxy must be setup for websockets so posting proxy settings and looking more closely at that will likely be answer.

Also http: settings in HA must one checked. If using recommended from docs for proxy you should be ok

3

Thank you! Fixed!

I had to add a websockets header to my reverse proxy configuration. (Note I have no idea what that means, but it worked).

I worried for a moment because the Synology uses a for-dummies form for setting up reverse proxies and doesn’t seem to provide detailed control. However, there’s a “Custom Header” tab, and it has an “Add - Web Socket” button that creates two custom headers: Upgrade: $http_upgrade and Connection: $connection_upgrade. So, working blindly (but google gave me some hope), I added those, and my connection now works.

I suppose I could have seen that from the debug log - but as I wondered, I was over my head on reverse proxies.

How excellent.

Thanks!
Tim