NGINX configuration - connection refused

Hi all,

I’m trying for a lot of hours to get NGINX working to get a secure connection to my home assistant server.

My setup is as follows:

  • Intel NUC with Proxmox running several VMs, all network traffic from the VMs is redirected to 192.168.1.x via a virtual network bridge inside Proxmox
  • one of the VMs is an Ubuntu Server running home assistant (installed via Python virtualenv), I forwarded the port 8123 to 192.168.1.x, I’m able to reach home assistant via 192.168.1.x:8123
  • one of the VMs is an Ubuntu Server running NGINX, I forwarded port 443 and 80, I’m able to reach the nginx start page via 192.168.1.246
  • I have a dynamic DNS from my ISP which translates my dynamic IP to xxx.internet-box.ch
  • I own the domain example.ch, I pointed several CNAME entries to xxx.internet-box.ch, e.g. hass.example.ch, mqtt.example.ch etc.
  • created a SSL certificate for all the subdomains and main domain with lets encrypt

What I want to achieve is, that when I go to hass.example.ch, it will redirect me to the home assistant frontend.

I edited the file /etc/nginx/sites_enabled/default to look like this:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    server_name hass.example.ch;
    listen 80 default_server;
    return 301 https://$host$request_uri;
}

server {
    server_name hass.example.ch;

    ssl_certificate /etc/letsencrypt/live/example.ch/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ch/privkey.pem;

    listen 443 default_server;
    add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
    ssl on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    proxy_buffering off;

    location / {
        proxy_pass http://192.168.1.x:8123;
        proxy_set_header Host $host;
        proxy_redirect http:// https://;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

I can start the nginx service and get no errors. However when I try to access hass.example.ch, I get the following error message in /var/log/nginx/error.log:

2018/08/02 17:15:40 [error] 1815#1815: *2 connect() failed (111: Connection refused) while connecting to upstream, client: 176.127.142.136, server: hass.example.ch, request: "GET /favicon.ico HTTP/1.1", upstream: "http://192.168.1.x:8123/favicon.ico", host: "hass.example.ch", referrer: "https://hass.example.ch/"

I read countless topics and tried different configurations for NGINX but nothing seems to work, I always get this error message above. I don’t know what I’m doing wrong!

I would really appreciate your help.

I solved the issue. I had to change the IP in the location section to the subnet IP of the home assistant server then it worked.

HI
sorry to revive this ancient issue, but it is very much alive in my new Nginx setup…

seeing this repeatedly in the log:

2021/07/19 13:33:55 [error] 222#222: *5764 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.1, server: mydomain.duckdns.org, request: "GET /api/websocket HTTP/1.1", upstream: "http://172.30.32.1:8123/api/websocket", host: "mydomain.duckdns.org:myip"

I am out of ideas what to change in the config (and where…)
3 places of config:

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

in configuration.yaml:

  auth_providers:
   - type: homeassistant
   - type: trusted_networks
     trusted_networks:
       - 127.0.0.1
       - 192.168.1.0/24

and I the Nginx config:

domain: mydomain.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

please have a look? thanks!

Don’t you have an error in the ha log?
Looks like the trusted proxy should be 172.30.32.0/24 (or 172.30.32.0/23)

1 Like

I guess @koying’s suggestion is correct. I don’t use HAOS or Supervised, but as far as I remember you should be able to get the IP address with something like

docker inspect addon_core_nginx_proxy | jq -r .[].NetworkSettings.Networks.hassio.IPAddress

See also the default network mask for Supervisor is 172.30.32.0/23:

Personally I’ve set a fixed IP for the NGINX (actually SWAG) container and just added this single IP to the trusted proxies.

thanks!

didnt edit trusted_proxy yet, didnt notice that in any setup guide for Nginx so guess I copied the default values… all connections do work flawlessly though, isnt that odd?

and yes, my instance running the Nginx add-on has a fixed Ip, should I use that only? like 192.168.1.71? or must it be the internal 172.30.32.0/24 format, and why not the mentioned 172.30.32.1 for that matter?

while you both are with me here, does it still make any sense to have the ip_ban enabled? Believe to have read that with Nginx, we need to create a dedicated list for that too, (since anything is originating from the Nginx address anyways now?

EDIT

I followed your suggestion on the trusted_proxy, and now see this error spamming the homeassistant.log:

2021-07-19 22:54:31 ERROR (MainThread) [homeassistant.components.http.forwarded] Received X-Forwarded-For header from an untrusted proxy 172.30.33.7

where before I didnt have any error.

Trusted proxy wasn’t “needed” until 2021.7.x, now it will give an error when it’s not configured.

It should be the docker IP, so 172.30.xxx.xxx. A single IP is enough, I’m however not sure whether this IP can change when the containers are rebuilt or if they stay the same, that’s why it’s suggested to use the CIDR 172.30.32.0/24 network to cover all the possible IP addresses in the range 172.30.32.0 - 172.30.32.255.

IP ban should still work as far as I remember, because when you set use_x_forwarded_for the original IP address will be forwarded to HA. But I’m not sure on this one.

So add 172.30.33.7 to the trusted proxies.

yes, that fixed the HA log. however, The Nginx log still shows frequent:

2021/07/19 23:02:51 [error] 222#222: *7441 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.1, server: mydomain.duckdns.org, request: "GET /api/websocket HTTP/1.1", upstream: "http://172.30.32.1:8123/api/websocket", host: "mydomain.duckdns.org:myport"

even with this in the http:

  use_x_forwarded_for: true
  trusted_proxies:
#    - 127.0.0.1
    - 172.30.33.7
    - 172.30.32.0/24
#    - 172.30.33.0/24

but they stop after startup? not sure, havent seen new errors added now for some time

Ah this an NGINX error, I somehow assumed it was a HA error.

Does everything work fine and you get the error only after startup? Could be that it’s because NGINX starts faster than HA. I also can not really help as I don’t understand the config of the NGINX add-on, I “only” have the standard config of NGINX and don’t know how this translates to the add-on config.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

# redirect all traffic to https
server {
	listen 80;
	server_name *.yourdomain.com;
	return 301 https://$host$request_uri;
}

############### Home Assistant ####################
server {
	listen 443 ssl default_server;

	server_name ha.yourdomain.com;

	# enable subfolder method reverse proxy confs
	include /config/nginx/proxy-confs/*.subfolder.conf;

	# all ssl related config moved to ssl.conf
	include /config/nginx/ssl.conf;

	proxy_buffering off;

	location / {
		proxy_set_header Host $host;
		proxy_redirect http:// https://;
		proxy_http_version 1.1;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_pass http://ip-of-ha-instance:8123;
	}

}


# enable subdomain method reverse proxy confs
include /config/nginx/proxy-confs/*.subdomain.conf;
# enable proxy cache for auth
proxy_cache_path cache/ keys_zone=auth_cache:10m;

exactly, what’s happening.
Using HA OS here, so I have no access to that file you copied I guess. If you don’t mind Ill take this to the release topic, where a. number of other issues where raised on trusted_proxies, maybe Frenck can chime in, as he authored the latest PR…

thanks for helping me this far! much appreciated
see: 2021.7: A new entity, trigger IDs and script debugging - #501 by Mariusthvdb

Startup of what? The nginx message says it cannot (yet?) connect to the HA instance, which makes sense if HA is not (yet?) started.

startup of HA indeed.
I guees it makes a lot of sense what you say, but how can the Nginx add-on be up before HA would be? they are no fully separated containers are they? (given the fact we configure the add-on from within HA, I suppose I expected that Nginx always will see a completely started HA instance)

Each add-on is a separate docker container, so it’s definitely possible that an add-on finished startup before HA has been fully started.

1 Like

ok thanks. That explains what is happening then.
Still, to have the Nginx log be of use, and show only important events, I would love to prevent this from being logged. Other than adding it to the trusted_proxies, would you know of another way? Guess it should not only be trusted, but maybe even ignored I(since there isnt anything to be trusted yet in the situation at hand)?

Ive also seen this being logged (in the Ha log this time):

Login attempt or request with invalid authentication from fe80::1886:d980:2b88:46a6 (fe80::1886:d980:2b88:46a6). (Home Assistant/2021.8 (io.robbie.HomeAssistant; build:2021.208; macOS 11.4.0))

which I suppose is my HA Mac App, and can be trusted or ignored too. Where do I add this? In trusted_networks, or also in trusted_proxies?
(dont know of a way (a tool) to check these Ipv6 addresses, and am a bit surprised, as my Router is configured not to support Ipv6 in then first place…

fe80 are local ipv6 addresses (a bit like 192.168).
You can add fe80::/10 to your trusted_network addresses.

great, thanks I will!

any reason this is suddenly logged? Is this Nginx originated? I’ve never seen these before. Did see the 192.168.1.1 before so this would be the Nginx translation for those?

Ok, I want to share my problem/solution with the exact same failure scenario

I was running nginx in a docker container and HASS as well. So I had a docker-network quirks

  • HASS has been running on the “host” network
  • nginx has been running on a virtual (docker) network

nginx couldn’t reach HASS from a network POV.

Solution: I put nginx and HASS in the same (docker) network (e.g. by passing --network host to nginx as well)

Could you give more details ?
Are you talking about official nginx addon ?
How did you do this ?

3 Likes