Issue with NGINX reverse proxy setup (external access)

Configuration
1

I am using the Home Assistant image for my RaspberryP1 3B. I have configured remote access using DuckDNS and NGINX and it has been running fine until I recently upgraded to core-2021.7.0.

While looking into this issue I did find the information about the breaking changes around the reverse proxy. I also found a lot of messages related to this topic and for most the resolution seems simply to add the following two lines under the http: section in the configuration file.

http:
  use_x_forwarded_for: true
  trusted_proxies:
  - 172.30.33.0/24

Unfortunately that did not work for me and I have tried all other suggested subnets and ip addresses to be added to the trusted_proxies as well. But so far no luck and it is driving me mad.

I have now rolled back to core core-2021.6.6 and I have at least regained my external access again. However I need to fix the issue in order to make sure I can keep up with the newer core releases. And of course to stay as secure as possible.

In the Home Assistant logs I can still see the warning messages as below:

Logger: homeassistant.components.http.forwarded
Source: components/http/forwarded.py:90
Integration: HTTP ([documentation](https://www.home-assistant.io/integrations/http), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+http%22))
First occurred: 14:41:26 (6 occurrences)
Last logged: 14:42:33

A request from a reverse proxy was received from 172.30.33.6, but your HTTP integration is not set-up for reverse proxies; This request will be blocked in Home Assistant 2021.7 unless you configure your HTTP integration to allow this header

Based on what else I could find on the internet I have the impression it is caused by the actual NGINX configuration but have no clue how and where I can validate this. I have even uninstalled NGINX and re-installed again to make sure I have a clean setup. So far still no luck and as said it is driving me mad!

Any ideas how I can troubleshoot this further or how I can check the NGINX config itself?

My current http section in the Home Assisatnt configuration file looks like this:

http:
  ip_ban_enabled: true
  login_attempts_threshold: 3
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.32.0/23
    - 172.16.0.0/12
    - 192.168.54.0/24
    - 192.168.56.0/24
    - 127.0.0.1

And my NGINX add-on configuration looks like this:

domain: <my subdomain>.duckdns.org
certfile: fullchain.pem
keyfile: privkey.pem
hsts: max-age=31536000; includeSubDomains
cloudflare: false
customize:
  active: false
  default: nginx_proxy_default*.conf
  servers: nginx_proxy/*.conf

Any ideas?

2

It should work.

Do you restart HA after modifying configuration.yaml?
Wouldn’t you happen to have http: twice?

3

You probably should regroup all “trusted_proxies:” into one series of data, it seems you have two…

5

How do you suggest to regroup the “trusted_proxies:” and why would that be required? I have also checked with the individual entries but same result every time.

6

I know and it is driving me mad.

I tried all the suggestions that I found related to this topic but for some reason I cannot get it to work on my setup. I have double checked but I only have one http: section in my configuration.yaml file.

I rdo indeed estart the core every time after making changes to the configuration.yaml file.

7

Because you have two http in your first message one with trusted-proxies:

  - 172.30.33.0/24

and the other one with :

    - 172.30.32.0/23
    - 172.16.0.0/12
    - 192.168.54.0/24
    - 192.168.56.0/24
    - 127.0.0.1

So I propose :slight_smile:

    - 172.30.33.0/24
    - 172.30.32.0/23
    - 172.16.0.0/12
    - 192.168.54.0/24
    - 192.168.56.0/24
    - 127.0.0.1

You have to check your subnet masks as well: /12 /23 /24

This site will be helpful I think:

In my two HA configuration.yaml files (as I have two HA instances), I only have (and it is working fine, I am using DuckDNS and NGINX as well):

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.33.6
    - 172.30.33.5
8

Thanks for the clarification. Now I understand your comment.

However 172.30.32.0/23 covers both 172.30.32.0/24 and 172.30.33.0/24. The first http was when I tried with a single subnet and the second http was what I ended up with based on the information I found what other shave been using.

As both both 172.30.32.0/24 and 172.30.33.0/24 were mentioned I combined them into 172.30.32.0/23 for simplicity. But whatever I have tried sofar it does not seem to work.

I have seen some comments about the NGINX configuration itself reated to double forwards providing similar issues but I am not quite sure whether that is related. Neither do I know how I can validate this as I do not know how I can check the NGINX default config files.

9

I used your exact same “trusted_proxies:” entries and restarted my home assistant but it still does not seem to resolve the issue unfortunately.

I wish I knew how to troubleshoot this further. I would like to understand what I am doing and this is very much a grey area for me at the moment. Are there any more detailed log entries that I can look in to that might give a better clue?

10

What error message do you still get ? The error message “A request from a reverse proxy was received from 172.30.33.6, but your HTTP…” should have disappeared…

Maybe this could help you too:

11

Unfortunately I still get that error. What makes you think it should have disapeared?

I have done the same as you stated in the link you shared and it has been working fine ever since I originally setup DuckDNS and NGINX. The breaking change as of core-2021.7.0 also affected me and I applied the recomended changes to the http: section in the configuration.yaml but without luck.

I have now reverted back to core-2021.6.6 so I at least regained my external access while I am trying to resolve the warning in the logs. Not sure whether there are more low level log messages I can look at that might give more information about the underlying problem…

12

Can this in any way be related to this issue Too many headers http 400 Error while using revers proxies. It might not be related but when I upggraded to core-2021.7.0 I did get a 400 response.

Problem is I would not know how to apply and test the fix they mentioned for the issue mentioned in the link.

13

Pfff finally found the root cause of the issue. It no longer showed in the logs for core-2021.6.6 so I was convinced it was indeed resolved.

Believe it or not but it was a simple space in front of the http: section header. As a result the whole section was never loaded. I must have looked at this a thousant times by now and never noticed the misplaced space before.

The section now looks like this:

# Uncomment this if you are using SSL/TLS, running in Docker container, etc.
http:
  ip_ban_enabled: true
  login_attempts_threshold: 5
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.33.0/24

Instead of this:

# Uncomment this if you are using SSL/TLS, running in Docker container, etc.
 http:
  ip_ban_enabled: true
  login_attempts_threshold: 5
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.33.0/24

I was so confident that this indeed fixed the issue that I have directly performed the update to core-2021.7.2 that was released today. And I can confirm all is working as it should!

I am one happy camper :slight_smile:

Thanks everyone supporting me on this one. Although in this case I found the root cause myself, caused by my own unintentional misconfiguration, your mental support was priceless!

2 Likes
14

How do you know what your trusted_proxies are? I use synology reverse proxy, and I’m seeing in the log a bunch of stuff starting with 172.68.

The whole HA is in VM, and I don’t know what is defining the proxy network.

I’m tempted to put all of Private network - Wikipedia in there. It’s private, so safe right?