Home Assistant Community Add-on: Nginx Proxy Manager

Is there by any change an event that is triggered just before a certificate is going to be renewed? I’d like my port 80 closed until the HTTP-01 challenge, open the port and close it after it updated the certificate.

Just want to say thank you - awesome plugin!

Cross posting from the thread I started, perhaps this would get more visibility here ( link to the thread NGINX (Proxy Manager) + basic auth + websockets = experiencing issues )

Hey everyone,

I have been going crazy, trying to figure this one out but yet to find a solution. I am running Home Assistant Supervised 0.116.4 on Intel NUC. Now, I am trying to configure easy external access to the system with a custom domain.

I installed NGINX Proxy Manager addon and configured the domain I want to use and enabled websocket support. This part works ( I can access HA and all pages inside, Lets Encrypt installed SSL, etc.).

After adding basic HTTP auth (so I am not leaving the interfaces fully exposed), the connectivity issues start. Entering the basic auth credentials and then logging into HA instance is OK, but then, for some reason, I am getting 401 error (Authorization Required) when accessing other HA pages (e.g. logs). It seems that WebSockets URL are not being proxies properly or not passing the authentication header.

In NPM logs, I can see these lines:

Copy to clipboard

[19/Oct/2020:11:18:22 +0200] - - 401 - GET https ha.example.com "/config/logs" [Client 12.12.12.12] [Length 574] [Gzip -] [Sent-to 192.168.0.198] "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36" "https://ha.example.com/config/dashboard"
[19/Oct/2020:11:18:24 +0200] - - 401 - GET https ha.example.com "/service_worker.js" [Client 12.12.12.12] [Length 574] [Gzip -] [Sent-to 192.168.0.198] "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36" "https://ha.example.com.xyz/service_worker.js"

Considering that I haven’t really made any changes to the networking/HTTP configuration of Home Assistant, do I miss on any configurations in NPM/Nginx itself to support basic auth? Any help here is appreciated, just point me in the right direction :slight_smile:

1 Like

Recently, my NPM started to show 403 Forbidden. I’ve just updated to Home Assistant 0.117 (probably it started in an earlier version, can’t really say).

image
Any ideas?

Why would you need this for Home Assistant?

As an additional security measure for an exposed HA instance you should always enable MFA but I don’t see the point of enabling NPM auth on HA addon (and probably with the same password as with HA).

Sorry for not being able to help; however, how would you expect other persons to help you if you don’t give any details on your setup?

The plann was (perhaps still is) to have some additional apps behind the reverse proxy, where they might not havea good auth mechanism(and/or 2FA). I’ve gone ahead and enabled 2FA and left HA with that for now. So it can be considered as resolved.

With that being said, the issue that HA doesn’t work with HTTP auth still remains and the question here - is it a bug or it is never meant to work with it in the first place?

I’d weigh on the second option.

The issue is that you shouldn’t really be able to circumvent HA authentication mechanism; although if you enable trusted_networks and use NPM in front of HA then anyone on the internet can connect to your HA instance without any need for the password or 2FA…

Oh, sure… Well, I’ve added a proxy host in like april or so.

That worked well until I’ve updated to some version.
If I am calling that URL now, I receive the 403: Forbidden message.

Sorry to disappoint; however, I don’t think this ever worked (at least, it didn’t worked as you intended).

In order to work you would need a proper domain served by DuckDNS (something like my_domain.duckdns.org) that you would first need to register with DuckDNS - please check DuckDNS addon documentation. Afterwards, you would come with a subdomain as my_subdomain.my_domain.duckdns.org in NPM.

The idea is that you could then issue my_subdomain1.my_domain.duckdns.org to my_subdomainx.my_domain.duckdns.org (with x being anything you can think of) without ever fiddling with DuckDNS again (that can handle only 5 hosts).

Not an expert here, but isn’t using .local domains not supported? AFAIK, HA already advertises itself on this domain via mDNS, so that perhaps creates a conflict? If you have own domain, try using that or check for DuckDNS sub-sub-domain.

I was able to authenticate into HA and could see dashboard(login information was saved). But as soon as I clicked on e.g. view logs or check Supervisor tab, it was never loading and in network console I could see 401 errors.

So I assume that HA after a successful login was trying to open additional connections (for Ingress) but doesn’t preserve auth header info from NPM.

I’ve searched Google far and wide for 2 days and the config generated by NPM was matching what people suggest to enable basic AUTH with websockets but it didn’t work. So, as you mentioned, I decided to not to bang my head on the wall and just enable 2FA :slight_smile:

Agreed.

I don’t think .local domain would be accessible from outside the network. The issue is that, being very common, someone else had already registered it.

In LAN .local is perfectly fine to be used (although there might be some firewall software that would not accept it). However, it won’t register with a DDNS such as DuckDNS.

That definitely worked for months.

I dont know what DuckDNS would have to do with my proxy manager as I only want to forward local stuff. I dont want to be able to access HA from outside of my network (thats handled by my nabucasa sub), I just dont want to access HA via port 8123 anymore. Just want to enter homeassistant.local and the NPM internally redirects to my HA. And again, that worked for months and recently stopped working.

So either in 0.116 or 0.117. I think it was already “forbidden” with 0.116 but cannot say for sure.

I think this was a loophole and you need a proper DNS server on the LAN side to resolve the same address that you might need in WAN.

I use something like the following with an Asus router to resolve addresses on LAN (pointing to the same address that is served by DuckDNS):

address=/my_subdomain.my_domain.duckdns.org/192.168.1.1

LE: 192.168.1.1 is the WAN IP of the router (not the LAN IP)

Well, the 403: Forbidden message is from my NPM.
So its not about “not working” DNS as it properly resolves the HA host.
Its just that the Webserver (I think its the HA frontend) is rejecting my request due to a missing configuration or sth. like this.

So I probably just missed some migration message and I just have to fix my config… Thought s1 here could give me a hint.

AFAIK, HA is to be served directly on the internet, without any proxy authentication and 2FA is handled by HA server itself.

I think when you say HA you mean NPM as HA is definitely not meant to be served directly on the internet…

Sorry, English is not my native language, I meant HA authentication.

Basically, with own certificate, just leave HA connect to internet (however, this complicates things with additional hosts), with NPM don’t use its authentication method in front of HA.

I appreciate that you are trying to help but actually I dont think that you fully understood the problem and that your suggestions are not what I expect to solve my problem. :thinking: