I have a basic understanding of VLANs, firewall zones and traffic rules and use VLANs in my own home network (basically a simpler version of what darksky showed here) but I lack knowledge when it comes to smart home devices.
Unfortunately a friend of mine recently got bitten by the smart home / home automation bug and got a couple dozen of IOT devices to turn essentially every light switch and power outlet in his home into a “smart” one.
As the general recommendation when it comes to IOT devices seems to be to put them on their own untrusted network without internet access, I set him up with OpenWRT on my old FritzBox 4040 I still had lying around with networks for lan (his trusted devices), guests and IOT. Then I got him Home Assistant OS (HAOS) on a Raspberry Pi 5 and installed the Twingate add on so he could access his network when he’s not at home.
As the lan network is allowed to access the IOT network but not the other way around, I put the HAOS host on the lan network so my friend could potentially access all the devices in his lan (future NAS?) and IOT networks through Twingate.
It was then that I found out that for HAOS to automatically discover all the smart devices it needs mDNS/SSDP broadcasts. As I don’t want him to have to add dozen upon dozen devices manually to HAOS that it a must have feature...
From what I could gather so far, there seem to be 3 options which I need advice on what to pick:
Put the HAOS host in the untrusted IOT network and create a traffic rule to allow only this single host internet access and call it a day. This seems to be the simple solution but would mean to either loose Twingate access to the devices in the trusted lan network or potentially having to add traffic rules for each host on lan that needs to be accessible.
Configure a zeroconf solution in OpenWRT of which there are a multitude of different packages (umdns, avahi, mdns-repeater,…) with each seemingly having their own drawbacks and added complexities of TTL and/or traffic rules. [1]
Use a hacky and officially unsupported way of adding a VLAN interface to the HAOS host to be able to add the host to both the lan and IOT network through VLANs tagging of the router port it’s connected to.
Which option would you recommend to pick for a simple and stable setup?
I’m using #2 and it’s simple, even if not 100% reliable (once in a long while, I need to manually restart the mdns redirector and the firewall, never figured out why it stops working). If I were using it for mission critical things (like home automation instead of streaming), I’d just add a chron job to restart mnds_redirector and the firewall every night at a safe time. In my case, if streaming stops or I can’t see the WiiM device, I simply go into System, Startup and manually restart mdns_redirector and firewall (probably once every 2 months or so, but the frequency is rather random
The only redirector that works for me, is mdns-redirector. umdns, as far as I can tell, only serves mDNS from the router itself, and it’s not a redirector/repeater which is what you want (basically a piece of code that monitors port 5353 and forwards packets between vlans, to oversimplify it
Configuration is dead easy, just list the networks you want to bridge in the file msdn_redirector, add the proper firewall rule for all vlans (below an example, including IPV6)
Avahi never worked for me, as per the thread you linked. It might have been me, or the versions I used
mdns_repeater
config mdns_repeater 'main'
list interface 'br-lan.1'
list interface 'br-viot'
list interface 'br-camera'
firewall
config rule
option name 'Allow-IoT-mDNS'
option family 'ipv4'
list proto 'udp'
option src 'iot'
option src_port '5353'
list dest_ip '224.0.0.251'
option dest_port '5353'
option target 'ACCEPT'
config rule
option name 'Allow-IOT-mDNS6'
option family 'ipv6'
list proto 'udp'
option src 'iot'
option src_port '5353'
list dest_ip 'ff02::fb'
option dest_port '5353'
option target 'ACCEPT'
@pluffmud
This looks like a very comprehensive write up and if I’d set it up for myself I’d probably give it a try. If only for the sake of tinkering and learning something new.
@robca
Sorry to hear that your set up still makes you the occasional trouble. As mentioned previously reliability/stability is a concern of mine as this is for a friend and I don’t want his smart light switches to stop working in the middle of the night or worse his espresso machine not to be preheated when he gets up in the morning.
So you made me think about how Twingate handles the traffic into the remote network where it’s “connector” is deployed and it turns out it just routes it in such a way that the firewall sees it as originating from the host where the connector is installed.
Which means that it takes just
two simple traffic rules
config rule
option name 'Allow HA internet access'
option src 'guest'
option dest 'wan'
option target 'ACCEPT'
list src_ip '192.168.2.126'
config rule
option name 'Allow HA lan access'
option src 'guest'
option dest 'lan'
option target 'ACCEPT'
list proto 'all'
list src_ip '192.168.2.126'
in addition to the
other traffic rules that are already in place
config zone
option name 'guest'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
list network 'guest'
config rule
option name 'Guest Allow DHCP'
list proto 'udp'
option src 'guest'
option dest_port '67-68'
option target 'ACCEPT'
to be able to put the host running Home Assistant OS into the IOT network where Autodiscovery through mDNS/SSDP should work without any problems and for it to have Internet access and facilitate remote access to devices in the lan network.
So unless I’m overlooking something important here I’m planning to go with the KISS principle…
Yes, that should work if no devices in the LAN zone need to be discovered. But technically you'll have to trust the IoT devices not to be malicious, because they could decide to send traffic from the whitelisted IP, 192.168.2.126, and escape the firewall zone.
Hopefully I have convinced my friend to cleanly separate the IOT devices into their own network and there won’t be any devices that need to be discovered by HAOS in the LAN zone.
As for your second point:
the traffic rules in my last post were from testing the PoC in my local network and truth be told I was going to whitelist the HAOS hosts MAC (list src_mac 'XX:…') in my friends network and hoping that none of the IOT devices were doing anything malicious like IP or MAC spoofing.
I know that the IOT devices will send their sensor and usage data to the manufacturers cloud and that they’re not known to put security first and I have even passively heard about Eufy cameras sending their "local” recordings to the cloud. But this is pretty much where my knowledge about IOT ends.
So I’d like to ask whether there are any medium to big IOT brands one should be concerned about their devices acting maliciously in the way you suggested?
I'd categorize MAC spoofing under the same threat model as IP spoofing, but I brought it up more as a theoretical concern. I don't know of any IoT devices that actually do this, but it is an under-researched topic, and I wouldn’t put it past the industry to do this.
This is not relevant for the spoofing threat model, but as an example that the industry goes to quite some lengths to gather data: Amazon already operates its Sidewalk [1] network so that your devices can send back telemetry without you ever connecting them at all, as long as anyone nearby has an Echo/Alexa/Ring device.
hello, i’m trying to get mdns cross vlan just to be able to cast from devices in LAN zone to devices in IOT zone.
I installed mdns-repeater, included both bridges, but i’m stuck on this point.
I created the firewall rule to allow traffic from IOT to router on 5353.
Now i can see in LAN the mdns packages coming from devices in IOT. That’s good.
But when it comes to the other way around, the LAN packages are sent to the IOT zones not using the source device name, but using the router name itself. So nothing works. I can’t understand the different behavior, LAN has full access to IOT