I wanted to configure my Unifi home network with a good segregation between between the desktop machines which I use to manage my family photos and finances and the IOT devices that aren’t really created by trustworthy vendors, or reliably patched to prevent compromise. I’ve trashed all my Amazon Alexa devices, since Amazon seems to think it’s a good idea to resell my internet connection with a presumptive opt-in. I try to only use trustworthy devices, but still, the home automation vendors do not necessarily have the budgets to develop high-quality code, and their incentives are not to optimize for my privacy.
Configuring Unify to separate devices into separate networks is pretty easy using their default tools, but there are several concerns that make segrating IOT into a firewalled network more difficult.
IOT device Wifi standard compatibility
Most modern network gear can publish an SSID (network name) that supports both 5ghz and 2.4ghz connections. This allows a device to connect to the best frequency for its current location and to hop between radios as situations change. Unfortunately, many IOT devices do not support 5ghz connections, but their software will attempt to connect to the wrong network during “automatic” configuration. If you are setting up a network for home automation gear, restrict it to only us 2.4ghz connections. Home control gear doesn’t need broader bandwidth than provided by 2.4ghz wifi, and will benefit from the greater penetration through building materials.
Most of the Homekit gear I use relies on mDNS (formerly Bonjour) service discovery. Unifi supposedly supports bridging these broadcasts between subnets, but this capability has been broken in their Dream Machine products for years and they have been unresponsive to requests for a fix. Luckily this can be supported by running custom services in a UDMP-hosted Docker container.
Set up the UDMP to allow connections using SSH.
Setting VLAN ID and subnet settings for primary and IOT networks.
Attach a new SSID to each VLAN.
Create Firewall Rules to block IOT->LAN Traffic
In order to prevent network connections from the IOT network to the private home network, you need to set up firewall rules to drop the traffic.
- New Rule
- LAN IN
- Drop Traffic
- Source “IOT” network
- Destination “LAN” network
When I set up these rules as described in Christian Mohr’s post, I later discovered that the steps described still allowed ipv6 traffic. I need to add the same rules under the ipv6 tab, in addition to the ipv4 rules tab.
Configure mDNS Reflector
Having set up the separate networks and restrictions, we need to set up a broadcast reflector to allow devices on the private home network to discover devices hosted on the IOT network. They can then send control commands to the lower network while being protected in case those devices are compromised.
- Disable mDNS service (Advanced Features -> Advanced Gateway Settings -> Multicast DNS)
- Disable IGMP snooping
- Disable WiFi Multicast Enhancement
- Install Custom mDNS reflector
ssh firstname.lastname@example.org curl -L https://github.com/boostchicken/udm-utilities/releases/download/1.0.4/udm-boot_1.0.4_all.deb -o /tmp/udm-boot_1.0.4_all.deb dpkg -i /tmp/udm-boot_1.0.4_all.deb exit
Pull and run multicast-relay docker image with the correct bridge numbers for the configured VLANs
podman run -it -d --restart=always --name="multicast-relay" --network=host -e OPTS="" -e INTERFACES="br51 br5" docker.io/scyto/multicast-relay
Create startup script to restart container after reboots
touch /mnt/data/on_boot.d/01-multicast-relay.sh chmod +x /mnt/data/on_boot.d/01-multicast-relay.sh vim /mnt/data/on_boot.d/01-multicast-relay.sh
#!/bin/sh ### kill all instances of avahi-daemon (UDM spins an instance up even with mDNS services disabled) killall avahi-daemon
Finally, start the multicast-relay container image (if it’s not currently running).
podman start multicast-relay