I’m running Home Assistant locally in my home network and I’ve installed an ESPHome device in a remote location (house from a family member at the other side of town). I would like to control the ESPHome device from my Home Assistant install.
I don’t have the option to setup a VPN to the remote location so I’ve forwarded the ports to access the ESPHome API and do OTA updates. The API is password protected and encrypted (but I have no idea how secure this encryption is) and the OTA component is password protected.
Does this leave attack vectors open to bad actors? Or can this approach be considered relatively secure?
Here is the relevant yaml config for the ESPHome device:
api:
# Forward this TCP port to access API remotely
port: 6053
password: !secret api_password
encryption:
key: !secret api_encyption_key
ota:
password: !secret ota_password
# Forward this TCP port to do OTA updates remotely
port: 8266
# Configure Wi-Fi connection
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_pass
# Public host/IP that this ESPHome device can be reached on
use_address: !secret remote_dyndns_host
If you can then get static IP-addresses.
If not then try to lock the connections down as much as possible, either by MAC-address filtering or host/network filtering.
You know the ISPs used, so it should be possible to get their IP ranges and at least limit access from those only.
There is “a quick and ugly guide” on last comment.
I have not tested this (yet) but I think better option (replacing Oracle Cloud) would be fly.io. They are great company and they have very generous free tier and Wireguard is there by default.
IPs are already static, what I meant is that the firewall in the router doesn’t support ingress rules. So no filtering/blocking IPs per port or device.
Wow, Wireguard on an ESP: that’s really cool! And there’s even a working example to use with ESPHome already. I wonder if this will eventually be integrated into ESPHome natively and for ESP8266 too (which most Sonoff devices are based on).
FRITZ!Box by AVM. It’s possible to create a list of permitted websites but as it is explained this is for egress traffic only, but maybe they also block ingress. Also, it is not clear to me if I can add IP addresses to those lists.
@savikko what free tier allowance over at fly.io are you looking at btw? I only see a shared CPU VM with 256MB RAM which is not enough to run HA. Or are you thinking of running a Wireguard-only server with them?
Actually, you probably don’t have to run anything there. Their free tier allowance is three of those 256M instances and that is limited by organization. Every organization has their own wireguard network.
So actually you could probably create just new organization, create there couple wireguard peers (flyctl wireguard create) and their infrastructure is then the wireguard server. Those peers who have connected to that one organization, can connect other peers within that organization.
So, one peer for ESP and another peer for your own HA instance.
No idea if that use-case is allowed by their free tier and no idea if that ESPHome thingie works as fly.io WG network is ipv6 only.
I don’t know your setup, but if you’re running HA OS or HA Supervised you could just install the Wireguard add-on and add a peer for every ESPHome device. I haven’t tested this myself but I think that would be the easiest way to get connectivity between HA and remote ESPHome devices using Wireguard. This would require forwarding ports for the Wireguard add-on of course. If that’s a problem then using a cloud provider in between to host the Wireguard server seems like a good alternative.
The Github instructions you linked to earlier specifically use a cloud provider (Oracle) to host HA entirely in the cloud instead of locally.