Reverse proxy error

I guess it depends how you see containers.
I see them as a convenience, not really as a security mechanism, and definitely not for HA.

From a KISS perspective, adding components to workaround security settings that you decided to implement yourself seem dubious :wink:

1 Like

Worked for me aswell - I am using Traefik as proxy

After my last message I had to edit my configuration to include all addons IPs because when I upgraded and restarted Home Assistant OS the IP of Nginx changed and it broke again.

This is my working configuration:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - 172.16.0.0/12
    - ::1

1 Like

I am running HA inside a docker container on my Raspberry Pi 3 with nginx as a reverse proxy running on a Raspberry Pi Zero and had the same issue and removing proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; also solved it for me. Thank you for sharing @dvoijen .

@frenck Can you maybe explain the security risk here? I am not to deep into that topic and don’t get it.

this worked for me as well. Thank you

At this point does anyone have a working config for a reverse proxy with apache? I’ve seen configs for ngnix and traefik, but not Apache since about July. There’s a few threads on it:

In that thread, people are adding their reverse proxy based on an IP being blocked from the logs, I don’t have any log entries about a proxy being blocked.

I have exactly the same issue with the wss to /api/websocket being blocked, however proxy_wstunnel is already enabled.

This whole /api/api thing didn’t change anything.

I documented my Apache config here back in April, and since then I’ve updated my config to allow both my proxy host IP AND the entire /24 subnet of the proxy, no good:

I’m using this and it works for me anyway. Home Assistant is running on host 192.168.1.1 at default port 8123. One of the problems why it didn’t work at first was the end slashes. For some reason they’re pretty mandatory(?) Also modules like these are required:

  • mod_proxy
  • mod_rewrite
  • mod_http
  • mod_headers
<VirtualHost *:443>
    ServerName ha.domain.co
    SSLEngine on
    SSLCertificateFile	/etc/letsencrypt/live/domain.co/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/domain.co/privkey.pem
			
    ProxyPreserveHost On
    ProxyRequests Off
    ProxyPass /api/websocket ws://192.168.1.1:8123/api/websocket
    ProxyPassReverse /api/websocket wss://192.168.1.1:8123/api/websocket
    ProxyPass / http://192.168.1.1:8123/
    ProxyPassReverse / http://192.168.1.1:8123/
    
    RewriteEngine On
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteRule ^/?(.*) "ws://192.168.1.1:8123/$1" [P,L] 
</VirtualHost>

I was led to this thread, but i’m just feeling more confused now. My setup was working just fine (HassOS, NGINX Proxy Manager) until a few days ago when i got a new phone. I got to the login screen, but my login attempt was refused. Also upgraded my PC to Win11, and it also got rejected. I found a “hack” that works, but not for long i suppose, as i added the remote IP range (Cloudflare: 162.158.222.0) to the thrusted proxies. I think my problem is that i have ip_ban_enabled: true also. As I read the documentation, the use_x_forwarded_for: true will forward the remote device/service IP to HA, instead of the reverse proxy’s IP. But in that case, I would have to enable all possible IP ranges that Cloudflare might use in my case, and that seems counter-intuitive. If I understand this correctly, I don’t see any practical way of combining ip_ban_enabled and a reverse proxy. Or am I misunderstanding this?

I am relatively new to Home Assistant and have installed Nginx for a separate requirement on a separate Raspberry Pi 4 in a docker container. I am having the same issues as discussed above and attempted different trusted IP addresses with no luck at all.

I can get to the login page but after login I get a message “Unable to connect to Home Assistant”

The log indicates: 2022-01-16 15:11:16 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from 110.xxx.xxx.xxx (110.xxx.xxx.xxx). (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36 Edg/97.0.1072.55)

Seems like the Nginx is not allowing the authentication to pass through to HA?

I would appreciate any ideas or pointers.

Likely, you didn’t configure nginx properly for websockets.

In case you’re using Nginx Proxy Manager, make sure that you’ve enabled the Websockets support on your subdomain

2 Likes

This fixed all my web issues but I can’t make it work on the iOS.
Getting NSURLErrorDomain - 1003 error when tried to connect via the App on an iPhone

Weird, if have read everything, and configured it properly, but i still get ERR_CONNECTION_REFUSED.
image
All other reverse proxy rules are working. So it must be something with HA.

Home Assistant relies on websockets, which basically are a “stay open” type of connection, and requires extra configuration on the reverse proxy side to allow websockets to work. Which proxy are you trying to use?

To rule out the block issue on the Home Assistant side, you can TEMPORARILY add this to your config:

http:
    use_x_forwarded_for: true
    trusted_proxies:
      - 0.0.0.0/0 

This will completely open the Home Assistant block and allow any reverse proxy to go through. If this works then the issues is not specifying the right IP for the trusted proxy. If it still doesn’t work even after allowing all IPs, the issue is on your reverse proxy configs and likely not on the Home Assistant side (likely not configuring websockets properly). I say Temporarily set this only for testing because leaving it like this overrides the security and leaves your system vulnerable to attacks, which is the reason specifying this IP was added as a requirement last year.

Update:
Took another look at your post and possibly its just a YAML formatting issue. Move the IP to another line and indent it with a dash instead of putting it right after the colon. Try this instead of what you have:

http:
    use_x_forwarded_for: true
    trusted_proxies:
      - 192.168.178.whatever
1 Like

@mwav3 , thanks for helping out. With this setup i have the same result:
image
Same issue with these settings:
image
these are the reverse proxy settings:
image

image

That appears you are using the NGINX proxy manager - if so checkout this post. You need to go to advanced settings and specify additional info. This user was able to get it working successfully with the config they posted

@mwav3 , thanks again. i don’t use a NGINX reverse proxy. I use the standard build in reverse proxy from synology.


All the setting they are talking about are not in here or in a different location.
What do you use as a reverse proxy?

I’m not too familiar with synology, but I know it’s more locked down then just running on a Linux os like Ubuntu or debian.

I use the SWAG docker container, which sets up nginx and some other tools like ssl and fail2ban. I’m running it on Ubuntu.

The thread I linked in the last post contains a comprehensive setup guide. Pretty sure you can run docker containers on synology, but it might be a little different from the guide. Guide is in the top post (linked below)

@mwav3 thanks again. i will check this setup, but it seems a bit of big change for something that should work with the syno reverse proxy. But many thanks for your help!

I have HA in a docker container on a raspberry pi.
I use remote.it to proxy my network, since I could not edit port forwarding of the router.
SSH works flawless, but I am having problems accessing the web interface.

I added

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.0.0.1

to my config, but now I am getting Received X-Forwarded-For header from an untrusted proxy 127.0.0.1

I saw in this thread, that deleting proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; is the only solution (but with security risk?). But where can I edit my nginx, since I am using remote.it?

This is my config there: image

EDIT: Guess it was just a typo. Thanks @w35l3y