Reverse proxy error

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.

docker network inspect -f \
'{{json .Containers}}' fd57d5eebb12 | \
jq '.[] | .Name + ":" + .IPv4Address'

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.

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.18.0.12
1 Like

This fixed for me as well ever since I updated to 2021.7.X

Thanks!

How is this working on ESXi? Do i have to put also the 3th address in the list?

image

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.

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - 172.30.33.0/24

@matthewjporter, thank you for posting your solution which works well for me. I have been pulling my hairs out since 2021.7.0 came out.

@pn5068 :+1:

I’m having this issue, even after adding the configuration:

Settings for http proxy

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - 10.42.5.0/24

The ip blocked is 10.42.5.50 that is the ip of the Nginx-ingress pod. Adding that ip or the range doesn’t make any difference.

Anyone with a solution?

Here is my setup topology

Solution:
In DSM edit your reverseproxy rule and add:
image

And edit your configuration.yaml file with the ip of the Synology
image

After these changes it will work again. :+1:

Found it, if anyone need the solution for a similair situation, i can post mine.

You should post it for others. This is typically something that many people don’t understand.

1 Like

do note Frenck said: Discord

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.

‘that example’ being Error in ingress.py TypeError: 'NoneType' object is not subscriptable · Issue #46323 · home-assistant/core · GitHub

I edited the solution within the question message.

Made an account to comment here.

The error in my configuration.yaml after the 2021.7 update was this :

  - http:
    use_x_forwarded_for: true
    trusted_proxies: 
    - 192.168.10.20

Instead of this (correct):

http:
  use_x_forwarded_for: true
  trusted_proxies: 
    - 192.168.10.20

Worked after changing the spaces. Weird it worked before, because that’s definitely not correct.

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.

1 Like

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:

networks: 
  default: 
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.16.239.0/24
          gateway: 172.16.239.1

Solution part B:
I’m letting all the containers do their own thing, except for swag (or whatever your nginx container is)

services:
  swag:
    ....
    networks:
      default:
       ipv4_address: 172.16.239.99

Solution part C:
Same as everyone else, just adding the config to HA to allow reverse proxy requests from this static IP:

http:
  use_x_forwarded_for: true
  trusted_proxies: 
    - 172.16.239.99
2 Likes

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.

The config for http is,

http:
  use_x_forwarded_for: true
  trusted_proxies: 
    - 192.168.0.1 #router
    - 192.168.0.42 #proxy

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?

1 Like

OK. I’m very confused here. I have this issue but am not using my own reverse proxy - I’m using:

HA 2021 8.2 in docker (image [homeassistant/home-assistant])
NabuCasa

I’ve tried adding the code above to config - no dice (127.0.0.1 is the IP complained about in the config):

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

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?

1 Like

Open a support ticket with nabucasa and they will help you sort it out.

Sorry if its wrong to post it in this thread

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?

Hey, my docker swag works fine with home assistant, I just had to set the trusted_proxies with appropriate netmask

# swag reverse proxy
http:
  use_x_forwarded_for: true
  trusted_proxies:
   - '10.10.0.0/16'

In this case the networks are on 10.10.x.x classes just because I’ve set

  "default-address-pools":
  [
    {"base":"10.10.0.0/16","size":24}
  ],

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.