I know by default I can’t access local “web-sites” like UnRAID, ESXi ect trough Home-Assistant over the internet. By default this is not possible if i don’t open up for these services trough the internet (And i don’t think that is a good idea).
But it would have been helpful if I could create shortcuts in the side menu and administrate all my internal webservers from home-assistant, now it looks like the client is calling the services directly, so what I think is needed is a built-in web-proxy ect. Do anyone know a way?
Unfortunately, to connect to the url, iframe will use the source address of the client itself (not HA). So if the client is on the internet, as the op asked, this will not function, since it cannot access local addresses from Internet.
It’s strange to me that this is not a more common request. Home assistant nabu interface looks like an ideal secure place to use for accessing local web pages from Internet.
Would appreciate to learn if anyone has solved this in the meantime.
Not sure if anyone is still trying to make this work but I think I’ve solved it …?
By creating a Wireguard VPN instance in docker-compose I was able to connect to my Home Assistant while away from home through the Wireguard tunnel … this means that Wireguard is allowing me to enter my network but still stay within HTTP, thus; all my HTTP iFrames work seamlessly away from home. ( This would however mean that HTTPS iFrames would fail )
Please note ! Wireguard will require you to port forward a single port on your home network to access your local services … so admin access to any routers and the modem to get to your public IP is required. You might also want to setup a duckdns docker-compose and corresponding web service if your ISP is giving you a dynamic public IP … I’ve got all this up and running so if someone needs help with that let minnow ><;>
I’ve tested this will several iFrames including Pihole, Portainer, and Uptime Kuma … all of them worked great but the only kicker is that the device you’re connecting from ( Wireguard client ) must have the Wireguard application installed and must be connected to a peer within your home network.
If you wish to connect to web services [ like Home Assistant ] outside your network without HTTPS then the only way that you could secure this connection properly would be a local-to-outside VPN connection … you could create a reverse proxy without SSL certification but I strongly advise against this since you’re leaving your network open for attacks.
The VPN connection will fulfill your requirements but ultimately without a VPN your best bet is to use a reverse proxy to convert all your other services to HTTPS so that they work with Home Assistant’s HTTPS, not the other way around.
Personally I use duckDNS to get a domain and connect that to my Public IP … after that just port forward your Nginx Proxy Manager to the Modem and use the Nginx to add HTTPS and SSL certification to all your containers that you want to access externally … this will allow secure HTTPS access to all your containers including Home Assistant.
Notes:
Make sure your passwords for your containers are strong (100+characters)
Nginx and all other containers must be on the same network docker network inspect network_name_here
should give you a look under the hood
only allow Nginx to access WebUi ports … this is a critical issue with containers like Pihole where you only want the WebUi to be accessible externally, not the actual Pihole services.
Connecting Home Assistant not in network_mode=host to allow connection to Nginx proxy manager could cause some issues with integrations that rely on Home Assistant being within the same subnet.
This is the best I can suggest for your issues but basically:
If HTTP then use Wireguard ( will require pihole for DNS records probably )
If HTTPS then use a reverse proxy like Nginx
Did you ever find a solution to this? I am looking for the exact same thing ans wireguard defeats the prupose somehow. Through VPN i do have acces to these sites anyway. I would like to use the home assistant to acces them.
