Reverse proxy error

that is not the proxy

1 Like

What should be the correct config? Iā€™m using below. If I comment out 172.18.0.2, log will have warning.

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - 172.18.0.2
    - ::1

This is nginx config (just copied from sample file and update the ip address).

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name xxxx.xxxx.duckdns.org;
    include /config/nginx/ssl.conf;
    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_homeassistant 192.168.x.xx;
        proxy_pass http://$upstream_homeassistant:8123;
    }

    location /api/websocket {
        resolver 127.0.0.11 valid=30s;
        set $upstream_homeassistant 192.168.x.xx;
        proxy_pass http://$upstream_homeassistant:8123;
        proxy_set_header Host $host;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

see this post

You need to have something like this in the proxy:

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

I donā€™t use NGINX myself - I use Caddy and it has a similar setting in there and I have no errors with this.

Thanks. Tried to add that actually created a new error log, seems the header is duplicate of the ip address

ERROR (MainThread) [homeassistant.components.http.forwarded] Too many headers for X-Forwarded-For: ['ipaddr', 'ipaddr']

I think in my case, that 172.18.0.2 is actually the correct proxy ip. Iā€™ve removed the 127.0.0.1 and ::1. rebooted, no warning.

Having same issue, so added:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.33.6

to my configuration.yaml.
But then I had to open port 81 in my firewall for Nginx to open the Web UI.

Can I close port 80? Thatā€™s what Nginx used before.

I added those localhost and docker addressing IPs ranges to the trusted_proxies as suggested for the others. Since that time I donā€™t see any problems with local addressing. Unfortunately, I started to see
Login attempt or request with invalid authentication from 141.101.105.90 and the IP led me to Cloudflare portal (my domain is set for DNS proxy via Cloudflare). I think, adding the external IP to my trusted proxies is rather a security risk. Is there any other way to get rid of the above notifications?

I am using apache, running HA in Virtual env on Ubuntu, got the same error message, but adding the following lines to my config resolved it (in case it helps someone):

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - ::1
1 Like

This became real painā€¦ Everyday I can find some new and different, external IP addresses 141.101.xxx.xxx (all of them coming from Cloudflare service) in notification section with ā€œLogin attemptā€¦ā€

I simply canā€™t add all of them to trusted_proxies.

Any idea?

do you get this error if you use your local ip or your domain?

Normally I am opening HA interface using my domain only. Since a long time I didnā€™t login to HA via local IP and port as I found this inconvenient.

Maybe

Normally you port forward directly to the service,like HA. Nginx, reverse proxy, now sits in front of the service and accepts traffic and forwards it to the service.

If port 80 is only port forwarded to nginx then No, you must keep open. If nginx is receiving traffic on different port then Yes, you can close

do you use nginx proxy manager or nginx home assistnant ssl proxy?
iam using proxy manger with cloud flare integration and added to my configration yaml
maybe this helps and are you using supervised home assistnant or homeassistant os?

http:
  ip_ban_enabled: true
  login_attempts_threshold: 5
  use_x_forwarded_for: true
  trusted_proxies:
    - ::1
    - 127.0.0.1
    - 172.30.33.6
    - 172.30.33.0

@alanp . I donā€™t have any Cloduflare integration. I have DNS server for my domain in Cloudflare, which I was using sucessfully for the last 5 years as additional protection for domain Cloudflare and I had for the last half year subdomain for HA without any issues. With recent changes it became pain.
I use Nginx Proxy Manager and my config.yaml is the same as yours
I even added as test that one external IP like below:

http:
  ip_ban_enabled: True
  login_attempts_threshold: 5
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - 172.16.0.0/12
    - ::1
    - 141.101.76.6

so I donā€™t have notifications from the particular one, but from the others IPs belonging to the Cloudflare service still appears at least a few each day:

Login attempt or request with invalid authentication from 141.101.98.244 (141.101.98.244). See the log for details. checking whois of course it leads to CloudFlare CDN, but it will be not possible to add all of them to config.yaml belonging to CloudFlare

Checking that whois link maybe I should add

141.101.103.255 /21

What do you think?

I dont know why you get non local ips in your log. As long as i know this error happen if you use your local IP instead of domain. And what i dont get why you can add 172.16.0.0/12 in your config. Iam getting errors if i add IP with ā€œ/ā€. Do you have a static IP from your provider?

doesnā€™t CIDR notation with ā€œ/ā€ work for you? I am surprised, I never had any issues with this. Answering your question. I put the whole subnet of docker IPs to avoid changing config after adding any new container (integration) in the future, but I doubt it can be related anyhow to that external addressing appearing in logs. Regarding the IP, no - I donā€™t have static IP (at least I am not paying extra for it and I could), although I can monitor it (thanks HA integration) and my public IP did not change since a month (with my previous provider it was changing a few times during every day, so apart from the higher price this was also a reason, why I swapped my provider :wink:).

I closed once port 80 as it seems not needed of course if you just use https only.

Later, I forgot about this fact and when I added a new integration and I tried to generate a new Letā€™s encrypt cert for the new subdomain, I could not do it. So, just remember that Nginx Proxy manager will work for you with port 80 closed, but for any changes you will need to open it.

Not sure why those discussions about nginx proxy for ā€œLogin attemptā€ errors.

This just inform about a possible break-in attempt, with the IP being the one that was put by nginx in the ā€œX-forwarded-forā€ header, i.e. the public IP of the potential hacker or script-kiddie.

Agree, I understand the purpose of this added protection, but it looks like because of this, developers created some innocent causalities.

Nevertheless, it looks like, I will have to check with Cloudflare support their safe IP addressing range, and add it to the trusted proxies config.

No. The only proxy talking to your HA is nginx.

That you see a cloudflare address as the IP address in ā€œlogin attemptā€ errors just means a hacker is using cloudflare to attempt to break-in into your system.

Went through the HA code and it does something peculiar.

Per definition, a X-Forwarded-For is

X-Forwarded-For: client, proxy1, proxy2

So the originator of the request is always the first IP.

Now, HA goes through the list of proxies in the header, and consider the first one that is not part of trusted_proxies as the originator, and uses that IP in the logs.

Quite confusing, imho. Itā€™s documented in Improve X-Forwarded-* request headers handling by frenck Ā· Pull Request #38696 Ā· home-assistant/core Ā· GitHub but Iā€™m not sure what was the reasining behind implementing this.

1 Like