Well it does work. I’d suggest the x_forwarded_for is misconfigured in the proxy as that is supposed to pass through the real IP address instead of the proxy.
Try 172.30.33.0/24 instead.
Well it does work. I’d suggest the x_forwarded_for is misconfigured in the proxy as that is supposed to pass through the real IP address instead of the proxy.
Try 172.30.33.0/24 instead.
I use 172.16.0.0/12
it works but I am not sure about the security.
It’s an internal IP address range so should be ok but I think you don’t have proxy configured correctly.
what’s wrong with proxy?
This is the config:
http:
use_x_forwarded_for: true
trusted_proxies:
- 127.0.0.1
- ::1
- 172.16.0.0/12
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
ip_ban_enabled: true
login_attempts_threshold: 5
that is not the proxy
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
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 ).