English is currently available.
Home Automation DISCUSSION
My home automation server and a few ESP-based devices work well on the local network. I would like to check sensors and switch things when I am away, but I am uneasy about forwarding ports to the server, and my internet provider seems to give me an address that is not reachable from outside anyway.
What are the usual options for remote access, how do they compare on security, and why might port forwarding not work at all on my connection?
Port forwarding makes a service on your LAN reachable by anyone on the internet, and automated scanners find open ports quickly. Whatever listens there must then withstand constant probing, which means current software, strong authentication and TLS. Device web interfaces and an unauthenticated MQTT broker are not built for that. Related advice: switch off UPnP on the router, since it lets devices open ports for themselves without asking you.
As for forwarding not working: many providers use carrier-grade NAT, where your router's WAN address is itself private and shared among customers. If the WAN address shown in the router is in 100.64.0.0/10 (100.64.x.x to 100.127.x.x) or another private range, or differs from the public address that an external IP check reports, inbound connections cannot reach you.
A VPN into the home network is the standard answer. The phone or laptop runs a VPN client, and once connected it behaves as if it were on the LAN, so nothing else needs to be exposed. WireGuard is a common choice: it uses a single UDP port (51820 by default), authenticates with public keys, and does not reply to packets that are not from a known peer, so a port scan does not even reveal it.
This still needs one forwarded UDP port and a way to find your address, normally a dynamic DNS name. It does not work behind carrier-grade NAT unless the provider gives you IPv6 or a public IPv4 address on request.
Behind carrier-grade NAT, the connection has to start from inside. Two families of tools do that. Overlay or mesh VPN services have each device make an outbound connection to a coordination server, then set up encrypted links between your devices using NAT traversal, falling back to a relay when a direct path is impossible. Tunnel or reverse-proxy services keep an outbound connection from your server to a public endpoint, and that endpoint forwards web requests down the tunnel.
The trade-off is trust and dependency: a third party is involved in connection setup or, for tunnels, carries your traffic. Read how each service handles encryption and keys, and protect the account with two-factor authentication. If you prefer not to depend on anyone, rent a small virtual server and run your own VPN endpoint there.
Whatever method you choose, limit what a compromised or misbehaving device can reach. Put IoT devices on their own network segment or the router's guest network, allow them to talk to the automation server and block them from the rest of the LAN, and keep the server and the router firmware updated. Use unique credentials for the remote path and enable two-factor authentication on the automation server's login.
The ESP devices themselves should never be reachable from outside; let them talk only to your local broker or server, and give only the server a remote access path. If you do decide to expose the server's web interface directly, put it behind a reverse proxy with a valid TLS certificate, expose only that one HTTPS port, and enable blocking of repeated failed logins.
Back to Home Automation community
