Hass on https for internal lan

https://sub.domain.com:8123
    ^

The FQDN (sub.domain.com) ‘should’ work, but if you use the local/internal IP address, then it will not resolve to the external sub.domain.com id, and therefore would fail.

Yes, but why would it need to resolve to the external address within the network?

I have abandoned that setup and I’m trying to install home assistant behind apache with mod_proxy.

Is there a setting to specify a document root for home assistant?

I would like something like: https://sub.example.com/hass/

but home-assistant use absolute path in the source code, and apache+mod_proxy fail

something like this, works but load only the first login page:

<VirtualHost *:443>
ProxyPreserveHost On
ProxyRequests Off
ServerName home.example.org
ProxyPass /hass/ http://localhost:8123/
ProxyPassReverse /hass/ http://localhost:8123/

Have you tried this?

Yeah, thank…but the issue is that guide don’t use the path but only sub-domain.

Home assistant does not use relative path for internal resource, but only absolute path…that fight with the virtual host with a sub path (ei. domain.com/hass/)

If the SSL certificate is based on the external FQDN, then the address you connect to (internal IP) won’t match the external address.

Thanks, that makes sense.

What I was trying to say by this is that you don’t say that you tried https and port 8123 at the same time, internally.

Also, I use nginx to reverse proxy to HASS, but not Apache. I could share the nginx config if you wanted.

I use duckdns and letsencrypt.
My Raspberry runs home assistant on port 443.

I reach it from outside with https://myadress.duckdns.org/

and from inside too with the same adress https://myadress.duckdns.org/

no adaptation needed.
I think about a function of your router…

I think you had right :slight_smile:

Anyway, if you don’t use a virtual host with sub-domain, but something with a path, please share.

ei. domain.com/hass

I really don’t know how to do that if hass internally use absolute path.

Very interested in your nginx config. Id like to do no password inside and require auth for external ssl access.

Ok, so:

  • I have a subdomain (hass.example.com) pointed at my external IP
  • But internally, my DNS server (router) replies with the internal IP of my HASS box for this subdomain
  • My hass is running on default 8123 with SSL (why not), and my nginx is running on 8124
  • My router port forwards 8124 to nginx, and hass is not exposed externally
  • Hass does not have a password configured

Then my nginx config is below (there are comments inline, and things you need to change).
End result: https://hass.example.com:8124 works externally and internally. Authentication is required only externally. https://hass.example.com:8123 goes to HASS internally (only), but I don’t often use it (you could switch the ports as long as you do it consistently).

/etc/nginx/conf.d/hass.conf :

[code]server {
listen 8124 ssl;
listen [::]:8124 ssl;

Default deny

deny all;

but passing any of the subsequent checks allows access

satisfy any;

Allows internal LAN. 10.0.1.0/24 is my internal IP range (like 192.168.1.0/24)

allow 10.0.1.0/24;

Prompts everyone else and allows if they enter a valid user & pass

auth_basic “Restricted”;

Create this with: htpasswd -c /etc/nginx/.htpasswd some-username

If you add more users, omit the -c

auth_basic_user_file /etc/nginx/.htpasswd;

location / {
proxy_pass https://hass.example.com:8123;
}
}

Global nginx proxy settings, from some Google tutorials

proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffers 32 4k;
proxy_buffering off;

Global nginx SSL settings. Mozilla intermediate, mostly

ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers ‘ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS’;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

Generate this with: openssl dhparam -out /etc/nginx/dhparam.pem 2048

ssl_dhparam /etc/nginx/dhparam.pem;

Replace with your key/cert path

ssl_certificate_key /etc/nginx/hass.example.com.key;
ssl_certificate /etc/nginx/hass.example.com.crt;
[/code]

2 Likes

The issue is when you have a Virtual Host with a sub path (sub.domain.com/hass), this because the links (js, css, imgs, etc…) inside the html of Hass are absolute and not relative.

I guess this could be consider a bug :slight_smile: (all web app should be able to install under a sub path, and not only in the DocumentRoot)

@AlucardZero: aynyway, I though, why you don’t add hass.example.com in the internall dns, and you can say to ngnix that:

  • Request come from your router ip (external) display login form (auth)
  • Request that come from others internal ip (internal) don’t display login form

So, you can avoid to switch from a port to another :slight_smile:

It is in internal DNS, and hass and nginx are on the same box for me, so I can’t have them on the same port.

You don’t have set them on the same port…really, you don’t have to use any port in my opinion.

  • ngnix listen on hass.domain.com:80
  • if client that request connection is router-ip, display auth login…and proxy to localhost:8123
  • if client that request connection is NOT router-ip, proxy to localhost:8123

where 8123 is the port of your hass :slight_smile:

anyway this topic is going OT :wink:

1 Like

Yes, you can do that.
I don’t want to expose external services on common ports. Obscurity is not security, but it is a good layer of a secure install.

Sorry for digging up this old post, but it is just my problem. Most other Nginx reverse proxy threads are about “location / {…}”, not “location /hass {…}”.

Due to a dyndns I cannot use subdomains (so I’m stuck with FQDN/hass) and because of other things running on the same server I cannot put HASS in the server root.

Is there any progress in that matter?

I must admit, I don’t understand the solution proposed by @elbowz

I’ve tried your nginx config, but some weird things happened…

  1. it ignores any combination of IP addressed added to automatically allow access
  2. HASS repeatedly asks me for a password to login, despite the fact their isn’t an API password set.

Any ideas?