It seems simple, and working locally - I can no longer access by server via http, but https is now working (although I do get a certificate error on Chrome, but I can click through that).
DNS is registered correctly, and a nslookup shows the correct public IP.
I have not opened any port forwarding, as per the docs, which is strange to me.
Can anyone tell me how this works, without port forwarding? i.e I don’t understand how I can connect into my network from the public internet - without a port open?
How to start diagnosing why remote access isn’t working? As I don’t understand this new connection type, I’m not sure how to diagnose it? e.g if it was an open port, I could test with netcat etc to check the port is open.
I’m super curious how this works without opening ports.
Hi, You need to port forward to be able to access it externally. It is impossible because of the way firewalls work, so that way no one can access things in your network that they aren’t suppose to. The ports you need forwarded is 8123 to 8123, and make sure it is set to TCP. If you are unable to access port forwarding, or just want to support the Home Assistant, try signing up for a trial with Home Assistant Cloud. It is very easy to configure, and they will just give you a url to go to access your Home Assistant. After the 31 day trial, it will cost 5 US dollars a month. I am currently using the DuckDNS plugin, and I had to port forward to set it up.
Question: the original remote access instructions say “This means that it’s not needed for the user to open any ports!”
Do you know what exactly is ment by that? It sounds to me like they are saying port forwarding is (somehow!) not required, but clearly they must mean something else??
If that’s not something you want to do then you can, as explained, subscribe to Nabu Casa or use something like ZeroTier (not the same as what Nabu Casa offers but does allow for remote-access without port-forwarding). There’s an existing ZeroTier Add-on.
It seems to be an absolutely unlucky formulation.
No port forwarding is needed for creating the certificate, but to access from remote port forwarding is necessary.
If you read the official guide I linked to, it refers to one not having to open any ports.
And unless there is some kind of unusual “DNS tunnelling” or similar going on, I assume the “do not have to open ports” must be referring to something else, and standard f port forwarding is required, but not mentioned anywhere in the guide?
You forward ports to your reverse proxy, not home assistant (unless using VPN or nabu Casa). The proxy host then typically terminates the SSL connection and forwards traffic on to home assistant over http.
Thanks. Whats the reasoning you would just forward the ssl connection direct to home assistant and terminate it there? (Using the Lets Encrypt built in addin)
Often times people will host multiple services, so managing all the traffic on and out is easier with a reverse proxy. Also, in a private network, you might feel safe with http over LAN. It is faster (I think?) and easier to manage when you factor in all the other stuff that may be talking to HA, like esphome, mqtt, etc.
It’s a three year-old blog post (which is like 30 Home Assistant years). So how have those instructions worked out for you? Based on your first post, not so well.
By ‘as explained’ I meant as explained by community member MrNewton.
Thanks to a blog post by Andreas Gohr I realized that DuckDNS supports setting TXT records, making it compatible with the DNS-01 challenge of Let’s Encrypt. The DNS-01 challenge is using the DNS record of the domain instead of interacting with the server. This means that it’s not needed for the user to open any ports!
What they are referring to is the set up of letsencrypt and the way it confirms you are the domain owner and validates the certificates. using that type of challenge requires no ports to be opened for the challenge. Otherwise you would need to open port 80 and port 443 for letsencrypt to confirm the config.
after that you will need to open a port for access thru your firewall for you to access your HA instance.
But also make sure you understand that letsencrypt and duckdns aren’t sufficient security measures to fully protect you.
The only thing Duckdns does is to translate your external IP address to a domain so you don’t have to keep track of that IP address as the ISP may sometimes change them. Its easier to remember a domain name than an IP address, especially if it changes. So it really offers no protection at all.
The only thing Letsencrypt does is that it encrypts the traffic between your browser and you HA instance so that other public people can’t “listen in” on your traffic to get access to usernames/passwords/etc.
It won’t protect you if someone finds an open port on your router (especially if its the standard port 8123 used by default for HA) and they try to gain access by hacking your username & password. Granted, it wouldn’t be easy to figure out both but I’m sure it’s been done. And I’m also sure that an attacker likely wouldn’t spend much time trying to hack your HA for such a low value target so they can mess with your lights (or open your locks and/or garage doors… ) so it’s fairly low risk.
To summarise the last two posts, that blog was from 3 years ago back when the people who were using homeassistant (and therefore would have been reading that blog) would be the kind of people who understood basic networking, and therefore implicitly know that the ‘no port forwarding’ statement referred to certificate renewal not external access.
I guess that’s the problem - it doesn’t take into account people with more advanced networking knowledge.
The blog post is poorly written.
There are indeed ways to access a network without port forwarding (which, based on the poor wording, is what the blog post can clearly be interpreted as). The most common would be the internal device (e.g HA) connecting to an external server, and then the client connects to the same server. e.g this is how Philips Hue gives you remote control without port forwarding, or can do custom setups with Reverse SSH Tunnelling etc.
I think the conclusion here is: the blog post is poorly written, and HA requires port forwarding just like most other similar services.
I can see why a well written version has not been published, as remote access is the sole income stream for HA - and it’s good that they have an income stream - countless hours and hard work of these people has been put into developing HA.
The conclusion here is that you chose to go back 3 years to find a blog that you didn’t understand and try and use it as a guide for something that it wasn’t even written about.
So it really offers no protection at all.
) so it’s fairly low risk.