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 
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. 
Probably
However, if everything works out fine in LAN (and you can connect with an address like 192.168.x.y:8123), then adding NPM proxying (without auth) as https://my_subdomain.my_domain.duckdns.org to NPM (with my_domain.duckdns.org registered with DuckDNS) should work.
Still learning after 2 weeks with home assistant running headless on my raspberry pi 4.
I’ve got duckdns with encrypt installed ok, and with the http integration found that i had to use my duck domain name to log in, even locally! Thought that a bit off and found that nginx got round that issue. I have no idea what a proxy server is, but it looked reasonable.
So, i installed nginx and commented out the http integration, and rebooted. I now have my local login back and was lookoing to go into the gui of nginx but can’t find it ie there is no OPEN WEB UI in the Suervisor/Info llike other add-ons have.
The log shows nothing odd, fairly short ending with “INFO: Running nginx…”
What am i missing?
For the time being I’ve disabled it from starting.
This Proxy handles all the requests.
Imagine something like a airport ramp agent that tells the visitor where to look whenthey arrived at your destination in “[domain].duckdns.org”. It is especially very useful when you expose multiple webservices, because nginx (if properly configured) will handle all the Cert/SSL things etc.
You can “easily” create subdomains e.g. mail.[domain].duckdns.org , whatever.[domain].duckdns.org etc.
you can find out whether a webservice is reachable in the supervisor-page of the addon you installed
I was able to symlink my letsencrypt wildcard cert like so after creating a missing directory that NPM was complaining about.
ln -s /ssl/fullchain.pem /ssl/nginxproxymanager/live/npm-1/fullchain.pem
ln -s /ssl/privkey.pem /ssl/nginxproxymanager/live/npm-1/privkey.pem
Things seem to be working fine so far.
Since latest update to Home Assistant 0.117.6, anything works as expected. So I think there was some kind of “bug” within the HA frontend or so.
Haven’t understood your request the first time but now I see that you only wanted NGINX for LAN (which kind of beats its purpose, I think ). In my opinion, as you still need to type the address, there are more convenient (and some more powerful) ways of dealing with long address names, ranging from simply adding entries to the bookmarks bar to using Muximux, Organizr or Heimdall as homepage and then deal with links to a lot of services (both from LAN and WAN).
Anyway, on the topic: you might want to look at https://en.wikipedia.org/wiki/Top-level_domain as you’re likely have to troubleshoot later issues connected to using .local as TLD because it is used by Multicast DNS.
By default, it seems that google will try to index your home assistant web page so I think that an action is necessary on nginx proxy manager.
I receive a mail from google Search Console which said : “MysubDomain .com : Indexed despite being blocked by the robots.txt file”. See here :
https://developers.google.com/search/docs/advanced/crawling/block-indexing
It seems it requires a noindex header . If I understood well it means that it has be added in nginx proxy manager (I’m not an expert 
)
Someone has already did it ?
Very nice add-on, thanks for that !
