Blog › Your data stays yours

Remote access to Home Assistant without cloud services: VPN and alternatives

There are many ways to reach Home Assistant remotely, and not all of them suit a heating system. For installers and integrators: the options compared, setting up a WireGuard VPN, and the mistakes to avoid.

June 3, 20266-minute readLeggi in italiano

In the article on remote control without the cloud we explained the principle to owners: the phone enters the system’s network through a private tunnel, without going through a manufacturer’s server. This article is for the people who have to build it: installers and integrators setting up Home Assistant remote access without Nabu Casa or other cloud services.

There are several options, and the choice depends on the building, the available connection and who needs access.

Network diagram with the router and Brick on the building network, an encrypted WireGuard tunnel to a phone, and a red box warning against opening ports to Home Assistant and Node-RED
Remote access through a VPN: Home Assistant, Node-RED and Grafana stay reachable only from the private network, and the phone enters through an encrypted tunnel. Avoid opening router ports to the applications.

The options compared

Home Assistant Cloud. The official paid service, run by Nabu Casa, the company behind Home Assistant’s development. It takes minutes to set up, needs no network configuration, and its subscription funds the project. It is a good choice for a private home whose owner is happy with an external service and a fee. It is not what we propose for Brick systems, because it introduces exactly the dependency on an external service we want to avoid.

Tunnels through third-party services. Some services create a tunnel from the home network to their own server, making Home Assistant reachable at a public address. They are convenient, but traffic passes through third-party infrastructure and the system depends on their service.

VPNs coordinated by an external service. Some modern VPNs create direct links between devices, but use an external service for authentication and to introduce the devices to each other. Traffic doesn’t pass through their server, but access depends on their account.

A self-managed VPN. A VPN, for example with WireGuard, configured on the system’s router or on the controller. No external service, no fee. It takes more configuration work, and it is the option we recommend for Brick systems.

Why WireGuard

WireGuard is a modern, open-source VPN protocol, and a very lean one. Compared with older VPNs it has three practical advantages:

  • configuration is simple: each device has a key pair, and the configuration file is a few lines long;
  • it is fast and light, even on a phone, and reconnects by itself when the network changes;
  • it is supported everywhere: industrial routers, Linux systems, apps for phones and computers.

Where to put the VPN server

The “server” is the device that accepts connections. There are three choices.

  1. On the system’s router. The cleanest option: the router handles the VPN, and behind it Brick and Home Assistant stay invisible. Many industrial routers, including 4G models, support WireGuard.
  2. On the client’s router. It works if the router supports it, but it depends on a device the client or their line provider may change.
  3. On the controller. Home Assistant has an add-on for WireGuard. It is convenient, but it mixes the network function with the control function.

Setting it up, step by step

With the server on the router, the sequence is as follows.

  1. Enable WireGuard on the router and generate the server key pair. Choose a private network for the VPN, different from the building’s, for example 10.10.10.0/24.
  2. Create a “peer” for each person: the owner, each family member or member of staff, the installer. Each peer has its own key pair and its own address on the VPN.
  3. Limit what each peer can reach. The installer can reach the whole system network; staff only the Home Assistant address.
  4. Make the router reachable. WireGuard needs the router to be reachable from the internet on its port, usually 51820 UDP. It is the only port exposed, and it exposes only the VPN, which does not even respond without a valid key.
  5. Install the WireGuard app on the phones and import each peer’s configuration, for example with a QR code.
  6. Test from an outside network, such as the phone’s mobile data, that Home Assistant opens at its internal address.

The 4G connection problem

Many mobile connections have no public IP address: the operator puts several customers behind the same address. In that case the router cannot be reached from the internet, and a traditional VPN receives no connections.

There are two solutions: ask the operator for a SIM with a public IP address, often available on business plans, or have the router connect out to an external VPN server that is reachable, run by the installer or the client. The second route always works, but someone has to maintain that server.

Installer access

Remote support is one of the most concrete benefits of a connected system: many problems are solved without leaving the office. To do it properly:

  • the installer has their own peer, with their own key, separate from the client’s;
  • the client knows it exists and can revoke it;
  • access is logged, as set out in the minimum security rules.

Documenting access

A well-configured VPN is useless if nobody knows how it is set up. At handover, the system document should record: where the VPN server is, the list of peers with the name of the person each belongs to, who has admin access to the router, and how to add and revoke a key. Private keys do not go in the document: they stay on the devices of the people using them.

That way, when staff or installers change, access is updated in ten minutes instead of having to redo everything.

What to avoid

  • Open ports to the applications. Forwarding Home Assistant’s port, 8123, or Node-RED’s, 1880, from the router makes the applications visible to anyone. It is the most common mistake and the most dangerous.
  • A shared key across several people or phones.
  • Node-RED without a password. Even on a private network, the Node-RED editor must be protected: anyone who opens it can change any logic.
  • No test from outside. A VPN that works from the office Wi-Fi may not work from mobile data.

In a Brick system

Brick works without any external service, and remote access is an add-on, not a requirement. The components you can order with the system include an industrial 4G router, which gives the system its own connection and its own VPN, independent of the building’s network. It is the setup that makes it easiest to follow the rules in this article, and the one we find best suited to holiday homes and non-residential buildings.

Need a hand?

If you are setting up remote access to a Brick system and something doesn’t add up, get in touch: we will help you choose the right route for that building.