Your cast button went grey after the IoT VLAN: fix discovery without tearing down the wall

The moment IoT moves to its own network, something stops working. The TV no longer shows up as a cast target, the speaker disappears from the AirPlay list, and the printer goes missing. Usually it is not the firewall rules. It is discovery: the way your phone finds the TV, the speaker or the printer by shouting on the local network and waiting for an answer. Those shouts do not cross a router.

The trap: one rule that undoes the whole point

The tempting fix is a rule that lets IoT reach everything again. It works, and it throws away the separation you just built. The right fix is to understand what the device is actually doing and pass exactly that.

Why discovery breaks

Most home discovery protocols use multicast, which is local to one network by design:

A router does not forward multicast between subnets. Your phone on TRUSTED asks "is there a TV here?", the TV on IOT never hears it, and the cast button stays grey. Nothing is blocked; the question just never arrives.

It helps to keep the one rule behind every rule in mind: a zone may start connections to zones below it, never to zones above it, and replies are always allowed back because OPNsense is a stateful firewall. Your phone (trusted) casting to the TV (IoT) is downhill, so the trusted rules already allow the connection itself. Only the discovery question is missing.

Fix 1: an mDNS repeater

OPNsense has a plugin for this: os-mdns-repeater.

1. System → Firmware → Plugins: install os-mdns-repeater.
2. Services → mDNS Repeater: enable it and select the two interfaces it should bridge, TRUSTED and IOT.
3. Do not add GUEST or MGMT.

The repeater only carries discovery. Once your phone knows the TV's address, it opens a normal connection to it, which your trusted rules already allow.

What the repeater does not do: it does not open any firewall ports, and it does not let IoT devices start connections into trusted. It copies small discovery packets between two networks. Your rules still decide everything else.

When casting finds the device but won't play

Some devices also need to connect back. Chromecast and AirPlay, for example, can open connections from the device to the phone during a session. If casting finds the device but fails to play:

1. Open Firewall → Log Files → Live View and filter on that device's address.
2. Look for blocked traffic from the device to the phone.
3. Add one narrow pass rule on IOT: that device to TRUSTED net, with the ports you saw.

One device per rule. Not IOT net to everything.

Fix 2: SSDP with a broadcast relay

For SSDP devices, the os-udpbroadcastrelay plugin plays the same role. Configure an instance for:

• UDP port 1900
• multicast address 239.255.255.250
• interfaces TRUSTED and IOT only

Like the mDNS repeater, give it only the interfaces that need it, and expect to add a narrow rule if a device needs to call back.

Fix 3: give Home Assistant a leg on IoT

Home Assistant uses discovery heavily: it finds ESPHome devices, Chromecasts, HomeKit accessories and many others by listening for multicast. You can make all of it work through repeaters, but there is a simpler option for Home Assistant specifically: add a second network card to its VM, tagged VLAN 30, so it sits directly on the IoT network as well as on servers.

That gives Home Assistant first-hand discovery with no repeater and no rule exceptions. The trade-off is real: Home Assistant now bridges two zones, so it has to be the best-patched machine in the house, with its own updates on and its admin accounts on strong passwords and two-factor login.

To choose, start with the question "who needs to discover the device?" Most homes end up with the repeater for phones and casting, and Home Assistant either on a second network card or reached through narrow rules.

Device by device

• ESPHome devices report to Home Assistant over its API, and Home Assistant starts the connection, so ordinary downhill rules already cover it. Only discovery needs the repeater or the second network card.
• MQTT devices (Zigbee2MQTT bridges, Tasmota, Shelly in MQTT mode) start the connection to the broker. If the broker is on servers, add one IOT rule: IOT net to the broker's address on port 1883 (or 8883 with TLS). That is an uphill exception, so keep it to the one host and port.
• Printers need mDNS for discovery and IPP (TCP 631) from trusted, which is downhill and already allowed.
• Cameras that record to a server on your own network: the recorder starts the connection to the camera (downhill), so no exception is needed. If they do not need the cloud, put their addresses in an alias such as IOT_LOCAL_ONLY and block that alias from the internet.

Time and DNS for devices that ignore DHCP

Some devices hardcode a public DNS server or time server and ignore what DHCP tells them. You can quietly redirect them to the firewall with a port forward on the IOT interface, under Firewall → NAT → Port Forward:

Interface:     IOT
Protocol:      UDP
Source:        IOT net
Destination:   ! IOT address   (anything except the firewall)
Port:          123 (NTP)
Redirect to:   127.0.0.1, port 123
Description:   Force IoT time to the firewall

Make sure the firewall's NTP service (Services → Network Time) listens on the IOT interface. The same redirect works for DNS on port 53. It cannot catch encrypted DNS (DNS over HTTPS on 443 or DNS over TLS on 853), which needs blocking separately.

Checklist: IoT that still works

• [ ] mDNS repeater on TRUSTED and IOT only
• [ ] SSDP relay only if a device needs it
• [ ] Narrow pass rules for call-backs you saw in Live View, one device each
• [ ] Home Assistant on a second network card in VLAN 30, or narrow rules instead
• [ ] MQTT exception: IOT net to the broker host and port only
• [ ] NTP (and DNS) redirected to the firewall on IOT
• [ ] Local-only devices listed in IOT_LOCAL_ONLY and blocked from the internet

The wall between IoT and the rest of the house stays up. You just let the right questions through it.

Found this useful? Subscribe on YouTube for the daily video, or follow the RSS feed.