RBR850 How to support https on local network (NOT remote) with nat loopback
Hi, As we all know communication should be encrypted at all times to avoid sniffing and hackers getting into your systems. So I want to secure the communication to my home assistant (webserver) on the local network. I don't want to expose my home assistant to the outside world. I can get a domain and lets encrypt cert but ofcourse this would resolve to my public ip, which does not work on the local network unless you allow traffic from the internet to get access to your local home assistant. I don't want this! Unfortunately the RBR850 does not allow me to register and route local traffic for my home assistant url. Nor does the RBR850 allow to set a DNS server of my own (wtf). So last resort appear to be NAT loopback. My knowledge on this is low and I've seen some complaints on this forum about setting up NAT loopback which go way beyond my cap. The poor documentation about this from NETGEAR doesn't help either. So does anyone know how to do this? Or should I return the RBR850's?
Re: RBR850 How to support https on local network (NOT remote) with nat loopback
An interesting project. How is the Home Assistant server connected to the network?
If it is 'wired', then the only way to sniff on that particular link is to have physical access to the network. (and even then placing a sniffer is not trivial. I use a managed switch and enable port mirroring.)
If the communication goes across WiFi, then (a) even a managed switch probably will not see the traffic, and (b) the actual data packets are encrypted. This is one reason sniffing on WiFi is so damn complicated. I can see that a packet goes from device A to device B, but cannot expose what is inside the packet for inspection. (and it's my own network!)
Have you considered a self-signed SSL certificate? This is what Netgear uses on the Orbi https version of the web administration interface. Web browsers throw a fit, "Unsafe! Go Back! Go Back!", but there is always a tiny link somewhere on the page offering "additional information" that has an option to go there anyway. Once done, the web browser no longer complains.
Of course the user can provide a DNS server. That is one of the options on the web setup. As an experiment for how to define local DNS name resolution, I set my Orbi to use a local Pi-hole DNS server. (Pi-hole has a feature for local network name resolution.) Works fine. If Pi-hole cannot resolve the name, I set it to use CloudFlare and GoogleDNS.
I abandoned that because I don't mind just using the LAN !P addresses for things, but it did work.
Is this Home Automation actually a web server? I had thought that most of this was done through smartphone apps and is probably encrypted already.
My knowledge on this is low and I've seen some complaints on this forum about setting up NAT loopback which go way beyond my cap.
The poor documentation about this from NETGEAR doesn't help either. So does anyone know how to do this?
Let's start with this: According to Which NETGEAR routers support NAT loopback? your RBR850 (and many others) are supporting NAT Loopback. The design of a NAT Loopback is that you can operate a server on the LAN, while having it accessible over the LAN -and- the public IP address. The idea is that you have a URL like https://your-magic-home.assistant.me[:port] which does resolve on the LAN to the LAN IP address of your home automation server address, while resoling the same from the wild Internet will point to the public IP address of your Internet connection, assigned to your router WAN/Internet-Port.
So I want to secure the communication to my home assistant (webserver) on the local network. I don't want to expose my home assistant to the outside world. I can get a domain and lets encrypt cert but of course this would resolve to my public ip, which does not work on the local network unless you allow traffic from the internet to get access to your local home assistant. I don't want this!
Operate your home assistant as a https server, for the sake with an Let's Encrypt Cert, but only on the LAN respectively the LAN IP. The certificate is signed for a hostname, and FQDN, not for an IP address. It's irrelevant on which IP address you are operating the server.
Nor does the RBR850 allow to set a DNS server of my own (wtf).
At some point, you might need your own DNS server (, or two): One for your LAN, and one for the Internet side of things. This could be implemented in split tunneling. However: Appears you don't want this at all, so no DNS for the internet side required.
To resolve this URL embedded hostname (FQDN) like your-magic-home.assistant.me for systems on your LAN, a simple local DNS server is sufficient, your-magic-home.assistant.me does only have to point to your LAN IP address, somewhere within a RFC1918 Address Allocation for Private Internets subnet. This could be the whatever LAN IP your router is defaulting to, or you head to some more security by obscurity, and used whatever correct RFC 1918 subnet you want. Keep in mind, these consumer class routers have limited resources, and your subnet can't exceed 256 IP addresses (254 workable), for example in the 192.168.1.0/24 subnet.
Beyond me, why you talk about implementing a NAT loopback ... because you never want any port forwarding, and even less access your fancy home-automation system from abroad. (why ever).
Keep in mind operating your fancy new home automation system as a https server does not make it more secure.
Interesting project, but certainly a longer learning curve involved. Good luck!
Unfortunately the RBR850 does not allow me to register and route local traffic for my home assistant url.
Curious where this idea is coming from. Routing (NAT, whatever, ...) is done based on IP addresses, never based on an URL.
Yes, routing is based on IP rather than URL, but the URL has to be resolved into an IP by a DNS server. The Orbi DNS process does not include a Local URL feature. Thus, the Orbi will not resolve any URL to an IP on the LAN. As I pointed out, the Orbi option to "Use these DNS servers" allows the servers to be on the LAN, which overcomes this problem at the cost and complexity of maintaining local DNS servers. (Imagine the confusion when the local DNS server fails and suddenly "everything stops"!)
I am also pretty confident that NAT loopback requires Port Forwarding. Orbi routers support NAT loopback, which redirects outbound packets addressed to the Orbi public IP to the Orbi WAN port rather than to the internet. However, once they hit the WAN port, they will die unless the router forwards the port to a server on the LAN. As you correctly pointed out, forwarding a port to a local server inherently makes that server available to the internet. Thus, NAT loopback is simply not a viable solution.
The forum would be so dull without discussions like this. Would love to know if this is the Home Assistant and which platform it runs on:
