Ran into this same issue over the past few days and finally had some time to troubleshoot. I run with my CNAME record’s Cloudflare proxy enabled, using the SWAG/LetsEncrypt docker container. I was bombarded with the errors indicated above every time I attempted to hit my external CNAME defined URL in Cloudflare.
My IP being blocked was 172.18.0.12, so just to make sure it was a safe internal IP from docker, I inspected my host’s docker networks via:
docker network ls
This resulted in the following, which homelab_default being of interest.
58005b20839e bridge bridge local
fd57d5eebb12 homelab_default bridge local
a88560f8d8ec homelab_zwave bridge local
9ee8d549a0ab host host local
96f42f3c12bd none null local
343e79eedfcb test_default bridge local
Run the following to inspect all the internal docker IP’s to validate that the blocked IP isn’t something from Cloudflare.
The above command will output all your container’s IP addresses, and you should see the reverse proxy container IP you’re using (in my case, SWAG) Note the fd57d5eebb12 network ID I used in the command above.
Knowing it was safe, I updated my configuration.yaml to the following, rebooted the homeassistant container, and was back in business from external access.
Just update Core Version from core-2021.6.3 to core-2021.7.3, then my reverse proxy ngrok was not working anymore.
Then found the error log:
“A request from a reverse proxy was received from 172.30.33.1, but your HTTP integration is not set-up for reverse proxies”
Then add these to configuration.yaml works for me.
Specify the IP address of your proxy as trusted proxy, so we know information we get is trustable.
Specifying a range as in that example means, all IPs in that range can spoof an IP address
So, please, unless you run a cluster of reverse proxies in a dedicated subnet, do not use ranges.
it probably didn’t work before. http is never under homeassistant like the first example. It never worked and probably a log error about it as well but it was only from 2021.7 that it checked this and had a requirement to use it.
Have been fighting with this for a bit on HA container / docker version. HA would keep telling me about reverse proxy requests from different IPs in the 172.xx range. Finally got things happy, hope this can help someone else.
I’m using docker compose for a bunch of containers, including swag for nginx reverse proxy. By default, docker compose creates a default network which bridges between all of the containers. The fun part is any time a container is recreated, it’s assigned a new IP in the pool, so we can’t rely on nginx container always starting at the same, it was jumping from 172.16.238.5 to 172.16.238.6. And, every time the whole compose set is stood down/up, it increments the whole pool octet, so it was jumping from 172.16.238.5 to 172.17.238.5 and confusing me more.
We have to get NGINX container its own static IP and include only that in the HA config.
NB: Basically everything else in HA and everything docker is fine accepting localhost or looking up by hostname which docker-compose configures by default, but this section of HA config is adamant about having an IP. I also can’t seem to get CIDR notation to be accepted like others show above… at any rate this is more strict because it only needs and allows 1 IP.
Solution part A - set up the docker compose network with a static pool of IPs. I still let it keep the default network name so I don’t have to put every container on. Not worried about intrusion or segregating as the only entry point is nginx and it only leads to HA… famous last words… Anyway this goes in the root of compose file:
Hi,
Having a problem with using a reverse proxy to access home assistant, and am unable to identify the cause and fix it, so I turn for help. I’ve looked in the forums and already checked the guides.
I have apache2 running on another machine in the local network acting as a reverse proxy, passing specific subdomain requests to my homeassistant.
Homeassistant is running as a docker compose container.
Where …42 is the proxy server, and …1, as the router.
Everytime I try to connect I get the following error,
[homeassistant.components.http.ban] Login attempt or request with invalid authentication from 192.168.0.1 (192.168.0.1).
This was when attempting to connect through the external address internally, it appears when attempting to connect from outside the network, with the necessary IP.
When connecting using the same credentials through the internal IP, it does work.
Anyone got any ideas of what to do?
Now instead of 400: Bad Request, I get that nabucasa terminated the connection.
The whole point of paying $5 a month for NabuCasa is it’s supposed to take care of external connectivity by default and I shouldn’t need to be resolving config file issues. And yet here I am…
So - dummies guide for resolving this with NabaCasa and no reverse proxy?
I have actually faced another problem after adding my nginx proxy ( my homeassistant is in a docker and running stable tag ).
I were able to fix the 404, “Received X-Forwarded-For header from an untrusted proxy”
by adding the proxy’s ip to the configuration.yaml
But the next issue is then that as soon I then log in and it accept my credentials its then saying “Unable to connect to Home Assistant.” on the webpage.
is there some other settings that I don’t know of?
it does works fine when I call it on the home assistants mapped ip and port directly ( so starting to think its actually after i entered the server_name in nginx there is giving me the issue )
Is there somewhere else we also need to remember to set the server name within homeassistant?
within /etc/docker/daemon.json, but it should even work for networks from other address pools, i.e. 172.17.0.0/12 and so on… provided that the trusted_proxies netmask includes the network of your actual reverse proxy.
