Home assistance and caddy as a reverse proxy

Configuration
1

Hey I’ve been using home assistant for a little while now and have it configured with a cert from let’s encrypt probably similar to how many of you do it.

I’ve recently stood a couple other servers up and have decided to make a reverse proxy using caddy so that I can just manage one cert for everything.

My Caddy config is a simple cut and paste from the home assistant docs → Reverse Proxy with Caddy - Community Guides - Home Assistant Community

I’ve reconfigured my configuration.yaml file to remove the cert.

http:
api_password: somepassword`
#ssl_certificate: /etc/letsencrypt/live/whatever.duckdns.org/fullchain.pem
#ssl_key: /etc/letsencrypt/live/whatever.duckdns.org/privkey.pem
base_url: whatever.duckdns.org
cors_allowed_origins:
- https://google.com
- https://home-assistant.io
trusted_networks:
- 127.0.0.1
- ::1
- 192.168.0.0/24

Now I can reach the frontend by IP address, but not when going through the reverse proxy. The gives me an error in caddy: -0700 [ERROR 502 /favicon.ico] tls: oversized record received with length 20527 and the web browser responds with 502 Bad Gateway

What am I missing? Is there some other configuration that’s required for using hass behind a reverse proxy?

thanks for your time

2

Bump. Also interested in a solution to a similar reverse proxy setup.

3

I was able to get this working with help from the caddy forums. It was rather easy, all in all.

Here is my caddy file:

mydomain.com
{
  tls [email protected]
    proxy / 192.168.0.181:8123 {
	websocket
	transparent
    }
}

and here is my config yaml

http:
  # Secrets are defined in the file secrets.yaml
  api_password: !secret frontend
  base_url: mydomain.com:8123
  trusted_networks:
    - 127.0.0.1
    - ::1

I had no trouble making it work as a subdomain (like the example on hass.io docs) but did have trouble making it work as a subdirectory, so I abandoned that.

the only real caveat is that all logins come from the IP of your reverse proxy server, which is stated in hass.io docs, so you probably want a password and no ip_ban_enabled

hope this helps.

4

@avalanchevm thanks for putting your resolution up!

I will attempt this probably tonight and wanted to ask can you add other devices to your caddy file? If so, any chance you can post a copy of your caddy file? I want to add a few other devices and trying to make it as neat as possible.

Thanks

5

Has someone been able to config Caddy to work with ip_ban?
For me it bans 127.0.0.1, so it does not seems that HA gets the source ip.

6

Yes, ip_ban is working for me.
HA configuration:

http:
  ip_ban_enabled: true
  login_attempts_threshold: 5
  use_x_forwarded_for: true
  trusted_proxies: <CADDY_IP>

Caddy configuration:

<HA_DOMAIN> {
    header / {
        Strict-Transport-Security "max-age=31536000; includeSubdomains"
        X-XSS-Protection "1; mode=block"
        X-Frame-Options "DENY"
        Referrer-Policy "same-origin"
    }
    proxy / <HA_IP>:8123 {
        websocket
        transparent
        header_upstream Host {host}
        header_upstream X-Real-IP {remote}
        header_upstream X-Forwarded-For {remote}
        header_upstream X-Forwarded-Proto {scheme}
    }
1 Like
7

I use 127.0.0.1 and ::1 as trusted proxy as well as x_forwarded_for and ipbans and it works fine. I was getting banned every couple of weeks on 127.0.0.1 before I did that… No idea why but it would just suddenly stop working.

I also use that authenticated sensor that logs every successful login which is useful as well.

8

After adding use_x_forwarded_for: true I never had a ban for 127.0.0.1. But with this configuration I have sometimes error with mobile Chrome (Android 8/9). I don’t know that is a HA, Caddy or my configuration isuue.

Screenshot_20181129-094632
Screenshot_20181129-0946321080×1499 60.4 KB

I have to click RETRY or reload the page and then HA loads without problems.

9

I see that sometimes as well… I think it’s just HA or chrome or a browser issue.

10

@Bieniu
Thanks.
Found my problem: I used localhost instead of the local ip. (in proxy / <HA_IP>:8123 . )
Why is that required?

11

Honestly I don’t know. in my configuration Caddy is on a different device than HA.

I think that is Caddy or Caddy configuration issue. As I changed Caddy on nginx, the issue never appears.

12

I use localhost with no problems.

13

I don’t think so. If I connect on localipaddress:8123 it occasionally does it as well. What do you mean by “I changed Caddy on nginx” Are you indicating you use both?

14

You are using the proxy option with the websocket preset which is a shorthand for

header_upstream Connection {>Connection}
header_upstream Upgrade {>Upgrade}

The 2nd line in combination with HTTP/2 most certainly leads to this error since HTTP/2 does not support protocol upgrade.

Please pass the flag -http2=false to Caddy and that problem should disappear.

If you’re using korylprince’s Caddy add-on you can configure the add-on option like so:

{
  "flags": [
    "-http2=false"
  ]
}
15

So I should change that as well?

Wouldn’t you normally want to use http2? Why does it work on a refresh?

16

i’m not forcing anybody so you have to decide that for yourself :wink:

if you really want to disable http2 only on one of your sites you could also use the tls directive in combination with the alpn subdirective in your Caddyfile. but I would first try the flag to see if the retry problem goes away. if it does you can tinker with the finer grained configuration options…

i’m not deep enough in the technical details why the browser accepts that communication on the 2nd try. if somebody has a deeper knowledge on that topic please let us know :slight_smile:

17

It’s really not a big problem - it only happens once a week maybe…

Of course not… I’m only asking…

18

lucky you! most of the people i know that used an http2 enabled proxy with home assistant saw that retry button each and every time they tried to connect.

1 Like
19

Of course not, I used nginx and changed it to caddy a few months ago and I have saved nginx configuration for testing.

Yes, it’s works, issue gone! Thanks. I used option alpn http/1.1 in tls section for HA subdomain and the rest subdomains work with http/2.

2 Likes