I’m currently running Home Assistant in a container on a Raspberry Pi, which also serves as a Pi-hole (installed locally on the Pi) on my main LAN. My goal is to improve Home Assistant’s access to my IoT devices, which are on a separate (secured) VLAN. I’ve been mulling over the security implications and best setup for this.
My current setup is:
Main LAN on eth0
IoT VLAN on eth0.2 (configured on the Pi)
My IoT VLAN is locked down by firewall, allowing established/related and a few allow rules for mDNS broadcasts for casting.
Home Assistant, by default, bridges to the main LAN of its host. I’m considering tweaking this to connect Home Assistant directly to the IoT VLAN for better device management. My concerns are around the potential security risks of bridging these networks, especially considering the shared host hardware.
I haven’t manually bridged the networks on the Pi. But I’m wondering if the Home Assistant container, through its default setup, might bridge the VLAN to the main LAN, potentially exposing my main network to IoT security vulnerabilities.
One idea I’m exploring is configuring the Docker bridge to connect to the VLAN instead of the main LAN. This would ideally give Home Assistant direct access to IoT devices while maintaining network isolation.
I’m looking for insights or advice on:
The security implications of this approach.
Best practices for configuring Docker and Home Assistant for VLAN access.
Any potential pitfalls or considerations I might be missing.
As an alternative I could leave Home Assistant on my main LAN and allow it firewall access in (only) to the IoT LAN, assuming that mDNS broadcasts will reach it, which they mostly do today.
Place HA on a subnet apart from the one for IoT devices and your main home subnet. HA is considered an internal service host and should be in a subnet with more protection than IoT and Home. For external access, place a proxy on a DMZ.
Allow HA to access everything in the IoT subnet and narrowly whitelist what can access HA from IoT.
From Home whitelist as well. Perhaps allowing only TCP access to HA web port (8123 default).
Thanks. What do you mean “internal service host” in the context of locking it down further? I assume you mean like a web server. And for if/when I need to point WAN at it for accessing outside my home network it needs hardening? I’m probably not going to open it up. I’m more interested in anything that relates to LAN usage and coexistence of the container on the host Pi.
The more I think about it, the host Pi doesn’t need to be on the IoT vlan.
One example is Sony Songpal for my amp. It’s not using mDNS, but a straight REST API for its controls.
I consider complexity (number of configuration steps, level of expertise, number of components to manage, etc.) to be a factor in managing security (or anything else for that matter). A more complex environment can lead to mistakes in configuration, support challenges, and more points of failure. I think simpler is better.
I ran HA and Pi Hole on a RPi4 using docker, Portainer, etc. For me, this became an amazing learning experience but it also became a relatively complex environment. I ultimately decided to run HAOS only on the RPi4 (on the IoT VLAN). Network security management (firewall rules, mDNS bridging, VLAN management, DNSBL, etc.) is on a dedicated router/firewall (pfSense).
I have it running on my IOT VLAN. Mostly for simplicity. I let all IOT devices see each other, but nothing else. I can access them from my main VLAN, but not the other way.
I dont see a benefit of putting it on a separate VLAN. You could make an argument to segment it into a higher security zone, but i dont really consider HA as risky. Maybe if I was doing safety or security based automations, Id isolate it better.
auto eth0
iface eth0 inet dhcp
auto eth0.2
iface eth0.2 inet dhcp
vlan-raw-device eth0
And I docker exec -it homeassistant bash
I can see I have an IP on both subnets (main LAN and VLAN). I assume this is because docker has bridged to both per above.
But when targeting my amplifier via IP in the Songpal Integration it can’t connect to the amp. I can ping the amp from the host Pi and also within the docker container context.
Edit:
My homeassistant docker yaml has network_mode: host which means it DOES inherit access to both subnets (thanks Chat GPT). I can log into home assistant from the vlan IP too.
I was wondering the same thing while designing my new network and stumbled on this thread.
IoT devices are basically things we don’t fully trust (some connect to vendor servers, have bad security etc.), so having HA in the same VLAN basically puts your HA at risk if one of those devices go rogue.
You might not have that many weird things in your IoT network yet or in HA, but once you add cameras and locks to it, well…
I think I’ll go with @odwide on this one and not have it in my IoT net.
That’s correct. It does depend on a lot of factors.
My HA is a standalone server running on a Proxmox host. it runs HA and nothing else. I always keep one snapshot and that’s always before I update HA. The next time I update, I delete and create a new snapshot. I also backup HA configuration periodically.
The purpose of my HA server is to talk to my IOT devices, so I see no reason to complicate that with routing. If I do need HA to talk to something not part of my IOT network, then I need to explicitly grant it permission. To me, this means that if for some reason my HA gets compromised, it can’t really see much.
You do have a good point with Cameras and locks. I haven’t breached that subject yet, but I most likely would have them on a separate VLAN (Cameras should probably be on their own network anyway), and interface with them via some form of proxy. Smart locks aren’t something that interests me too much, but if I did find the need for them, I would likely take a similar approach.
Right now, I mostly buy fairly reputable IOT devices, but I do plan on having a sort of Low-trust VLAN where I put things I buy off of AliExpress, but I’m more likely to go ESPHome for obscure / expensive equipment, it’s probably cheaper than AliExpress anyway.